Assuming something means taking it for granted. In other words you’ve got a more or less conscious theory (or, less charitably, a guess) that something is going to happen. The trouble is that the assumption might not be true.
To go with my typical programme organisation I thought I’d describe the roles and responsibilities I expect on an Agile programme. Remember I’m interested in software delivery so I’m talking about programmes that have software development at the core. Non-software programmes would have a different mix of roles.
Some roles in an programme correspond to the roles in an project. The scale of responsibility is larger and emphasis on coordination greater but the nature of the roles is broadly similar. The Agile Programme Manager, Programme Product Owner and Technical Architect roles fit this mould, corresponding to Agile Project Manager, Product Owner and Technical Lead.
In addition a programme needs some roles that don’t appear at all in a project, in particular Programme Director and Business Change Manager. Again these roles are a result of the wider remit and increased communication necessary in a programme but also because of the focus on organisational transformation.
The product owner defines what the development team is meant to build and the order in which it is built. What should you do when the Product Owner responsibilities lie with more than one person?
The short answer, that works in simple situations, is get the business to pick one. However things are not always so simple and there are situations where you will need more than product owner. I’ll outline a few scenarios, both good and bad, which for the purposes of this post I’ll characterise as Many Kings, Pretender to the Throne, and finally Chief and Indians.
Some people think estimating is “crystal ball gazing” (@agilemanager, 2 Nov 2012) leading to “bad decisions” (@WoodyZuill, 2 Dec 2012). I’m not one of them.
I don’t always estimate. Nor do I necessarily estimate everything. But I find estimating helpful when considering investment proposals. This is true whether picking the next user story or commissioning an entire project.
Admittedly estimating is not an exact science so I think George Dinwiddie (@gdinwiddie, 27 Feb 2013) summed it up nicely when he tweeted that “estimates turn the unknown into the unsure, based on someone else’s expertise”.
I believe that even estimates with caveats help the business make better investment decisions.
During the last year I have spent a lot of energy on recruiting project managers. I was looking for something specific and although I spoke to a lot of project managers, some of whom came highly recommended, it took a long time before I found what I was looking for.
Having spent a fair bit of energy on this, I thought I’d write up what I believe makes a great project manager.
The most liberating day of my career was when I realised that, despite being responsible for the project I was running at the time, I actually controlled very little of what happened. That was the day I freed myself from the “fallacy of control”.
I can’t really control who does what. I can’t really control whether an individual does the work to an acceptable quality. I can’t control whether or not the product owner is going to change their mind about priorities. I can’t control whether the proposed technical solution turns out to be much harder than anticipated or just a dead end.
All I can really do is influence what happens in my programme/project. Spot issues quickly and react appropriately. Lean-Agile gives me the tools to do that.
As I’ve said before the most common problem I’ve seen with software development teams is over commitment. If worse comes to worst you get to the end of the spring before realising the problem. But you don’t have to wait until the end of a sprint to take corrective action.
This post was prompted by a comment, by Chris, on the post where I described what to do when tasks in the Sprint Plan are not finished. My assumption in that post was the team only realises they are overcommitted at the end of the sprint. And for first time teams that is often exactly what happens.
What I didn’t mention is that more mature teams are likely to spot what is going on earlier.
In his brilliant post Don’t know what I want, but I know how to get it Jeff Patton used a sketch of Mona Lisa to illustrate the difference between Iterative and Incremental development.
Jeff points out that many Agile people use the word “Incremental” when they mean “Iterative”. I believe this is because, in reality, most Agile project combine both approaches and become Iterative Incremental. In fact I can’t imagine delivering software in any other way.
To illustrate what Iterative Incremental means I’ve taken Jeff’s Mona Lisa illustrations and added a third showing a combined Iterative Incremental approach.
Lean-Agile offers two productivity measures: Velocity and Throughput. It is possible to improve both over time but there is little point in management demanding that a development team improve either because both metrics are very simple to fudge.
There is also little point in using either of these productivity measures in product development. The focus is discovery not churning stuff out.
Where a productivity measure is useful is in a project or programme. Where somebody is wanting to know when the team will be finished. Or, conversely, how much functionality will be delivered before the time and/or money has run out.
In response to my request for questions along the lines of what do I do when … ? Jo asked:
What do I do when the product backlog is not complete and we still want to deliver our product on the agreed date? It is hard for the Product Owner to prepare a complete feature backlog and for developers to estimate the required time in order to get a realistic burndown chart during the sprints. The product backlog is kind of dynamic.
In response I’m going to look at three states for the product backlog and strategies for managing backogs when in each of those states:
- Normally vague/dynamic
- Completely vague
- Massively dynamic
The first of these states is, well, normal. You never know everything about the scope. You just have to manage what you do know.
The other two states suggest something is going wrong in the product management space. And that is very much a product owner issue. The agile project manager / scrum master role is to help the product owner and/or organisation realise their problem.