Lean Product Manager - a new endeavour:

The state of Product Management in the UK has long been on of my bugbears. Anyone who has seen my “Requirements: Whose job are they anyway?” will have picked up on some of my concern. Well, I’ve finally decided to do something about it…

Together with Monika Turska I’ve been putting together a two-day course focused on modern product management called “Lean Product Management.” We are going to be running it with Learning Connexions in London at the start of December. For the first run or two you’ll have both of us delivering the course, after that we’ll see what happens.

Whether your title is actually Product Manager or if you are a product manager labouring under the title Product Owner or Business Analyst we think you’ll learn something on this course.

We’ve structured the course around three themes which we see as key to filling the Product Manager role well but poorly understood:

• The Product Manager’s role: understanding the purpose of the role and how product manager interacts with the customers, market and their organisation in order to maximise the value of the product.
• The Product Lifecycle: how to choose the right tools, measure progress, set actionable metrics through the product life cycle from a prototype, MVP, maturity and product decline, and how to identify opportunities for product business pivots.
• The Customer Lifetime Value (LTV): identifying and optimising the value proposition and customer engagement, and how this changes for innovators, early adopters, through maturity and laggard adopters.

There is not “Agile” in the title for two reasons, a) the focus is on “what should be built” and b) Agile is pretty much a given in innovative environments. If you are not actively doing “Agile” your probably doing something better, or else you’ve already gone out of business.

Anyway, let me know what you think, or better still: book a place today.

Feedback & testing wanted - please help!

Can I ask for some help, please?

Some testing? Some feedback? Please

Here is where I need the help: http://mimas-aotb.appspot.com/ - now let me explain…

Agile on the Beach 2017 is in July next year so the whole organization schedule has to move up two months: we’ll be opening the call for papers towards the end of November or start of December.

But I have a problem.

Last year we had close to 250 submissions from over 100 potential speakers. We have six committee members voting in two rounds on the submissions. And I try to give as much feedback to those who submit as I can - this year it took nearly six hours to give feedback to everyone who wanted it.

As a result I have a lot of work in the background.

After 2015 I thought: we need some tool to support us. But when I looked none of the submission review systems I found really fitted our needs. For 2016 I’d left it to late so we had to do the same as 2015 but it got me thinking…

Add to this, we’d like to involve more reviewers to spread the load and get better reviews, the current system would make too much work for me, i.e. its not scalabe.

In the summer I started writing my own system: Mimas - named after on of Saturn’s moon.

Here it is: http://mimas-aotb.appspot.com/

Its on Google App Engine and you’ll need to log in with a Google account.

I’d like to invite you all to play with it and let me know what you think. And especially let me know if find something that doesn’t work.

A Dummy AOTB 2017 conference is set up but you can create your own conferences which you and everyone else can see them too. There are some permission controls in place but any conference with the word “Dummy” in the titles will relax permissions so you can try it with as a speaker or reviewer.

Note: each conference has state, there are some things you can only do in some states, e.g. conferences start closed and then need to be opened for submissions. No reviews can occur until submissions are closed and round 1 starts, and of course, round 2 cannot start until round 1 is complete.

Please send me any feedback, all is very much appreciated: allan@allankelly.net.

One more thing: In writing this I kept telling myself “This is only for AOTB, do what AOTB needs, nothing more.”

Inevitably, now it is nearly finished I do wonder “Umm, could others find this useful?”

If you think you might find this system useful, or just if you have an opinion on whether you or others would find this useful please mail me and let me know. I’m interested to hear anything and everything.

Were I to make this more widely used the first thing to change would be the track listing, they would need to be configurable, I’d also need to revise the voting methods, at the moment it is set up for the Agile On The Beach procedure, and and and, …. please mail me if you think of something.

Software diseconomies of scale - any research?

To say last October’s post “Software has diseconomies of scale - not economies of scale” has been my most popular post ever is something of an understatement! It has been read tens of thousands of times after being picked up by some very popular publications and newsletters.

When I wrote the piece I was writing largely on intuition. That software development experiences diseconomies of scale started as hunch, gradually I could see more evidence but when I published last October I didn’t have anything that would stand up to academic scrutiny - not that I was aiming for a peer reviewed publication.

Since then I’ve become aware of several pieces of research which do show the same phenomenon and do stand up to academic standards, plus I’ve become aware of several people who have made the claim earlier than myself.

So, for those who want to dig into this subject some more let me record the evidence.

“From Aristotle to Ringelmann” (or better an open download of a preprint version): in this paper Ingo Scholtes, Pavlin Mavrodiev and Frank Schweitzer at ETH in Zurich examined open source code bases and team sizes. In their abstract they conclude:

“Our findings confirm the negative relation between team size and productivity previously suggested by empirical software engineering research, thus providing quantitative evidence for the presence of a strong Ringelmann effect.”

The term “Ringelmann effect” is new to me but describes what is seen in software teams - and elsewhere:

“The Ringelmann effect is the tendency for individual members of a group to become increasingly less productive as the size of         their group increases” Wikipedia

Another academic paper is Economies and diseconomies of scale in software development by Comstock, Jiang and Davies. Unfortunately, despite the title this paper focused on constructing a model for effort and value in software development than drawing conclusions about economies and diseconomies. So yes it is about software economics but not a lot about economies and diseconomies, more software accounting. The authors offer no conclusion of their own in that respect.

That said there is some evidence here. The authors note several earlier studies which had mixed results, some showed diseconomies of scale but some also showed economies. They also point out that at least two of the more established forecasting models (from traditional backgrounds), the Putnam and CJD models, assumed diseconomies of scale (I’d never heard of either of these models before!).

It a shame that some of this knowledge has existed in some academic circles for several years, it seems to be another example of how academic papers hidden behind paywalls prevent the spread of useful knowledge. (My initial attempts to get this paper met with paywalls but in the link above I tracked down a downloadable version.)

There is an important observation built into this paper, almost by accident: the optimal team size is not fixed, it will depend on the size of the undertaking and the duration of the effort. I am often asked “What size should a team be?” and several Scrum advocates have stated “the team should be 7 people plus or minus 2.” Clearly the right size for any undertaking will depend on multiple factors.

Away from the academic world there is some more support for diseconomies from other observations.

In a blog post about two and a half years before mine Jesus Gil Hernandez made exactly the same point, “Diseconomies of Scale in Software Development.” Jesus also makes the point that if we want to forecast and plan large software initiatives we need to take such diseconomies into account.

“Diseconomies of Scale and Lines of Code” is blog post from further back, 10 years ago, from Jeff Atwood’s Coding Horrors blog. Jeff also suggests diseconomies of scale but then his blog goes on to focus on lines of code and why its a poor metric (and it is). Jeff also points out that Steve McConnell discussed diseconomies of scale in his 2006 book, Software Estimation.

What is becoming clear is that the possibility of diseconomies of scale in software development have been known about for a long time and my argument has some validity. What we need now is more research to get to the bottom of this…

Unfortunately I don’t have the time or resources to get do such research, I’m happy to collaborate, any academic or PhD student out there fancy picking this up as a research question?