Some people and some organisations like meetings. If you drop Agile with its Agile Heartbeat into the mix then you might find that meeting madness strikes.
I’m a Kiwi living in the UK and I’ve noticed the British will form a queue if given the barest of excuses. Similarly, in some organisations, the people will call a meeting at the drop of a hat. People in coordination roles (e.g. project manager, discipline lead) seem particularly prone to this.
Don’t.
Continue reading
The Iterative Incremental approach inherent in Agile applies to delivered functionality but also to the requirements elicitation part of the process.
I like to refine requirements over time. Start high level, just enough to remind us to have a conversation, then fill in the detail just as we need it. What starts as a simple name of an Epic Feature will turn into multiple User Stories each with several Scenarios. But you don’t need all of that at the start.
The iterative nature of requirements definition is suggestive of a spiral process – what my daughter would call a “snail”:
Agile Requirements Snail
One of the ironies of the discussion on no-estimates is that the no-estimate proponents do in fact estimate. In a small way.
Continue reading
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.
Continue reading
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.
Continue reading
Today I bumped into an article Bryan Zarnett wrote for the Scrum Alliance. I read the article mainly because the title caught my eye in Google – Running the Scrum of Scrums: Agile Program Management.
This leapt out at me because of the claim that the Scrum of Scrums is the same as Agile Programme Management. It isn’t.
Continue reading
You’ve got a product backlog as long as your arm but the system is live and operational demands keep landing on the developers doorstep. What to do?
Many development teams have to cope with operational commitments in addition to their new work. This is inconvenient but reality. Basically you need a mechanism to get operational work through the process despite high priority new development. There are a few mechanisms to enable this.
Continue reading
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.
Continue reading
Managing Successful Programmes (MSP) is about programmes but it does have something to say about how to run the subordinate projects. And projects in MSP are not meant to be agile in any way. Although agility is encouraged for MSP programmes agility in the projects is viewed as a “disaster”. Given the people who use MSP are most likely to be using PRINCE2 this belief is perhaps not surprising. But it is not a belief I hold to.
Continue reading
Gojko Adzic has recently published a great book on a technique he calls “Impact Mapping”. Gojko’s Impact Maps are a visualisation of the business drivers and the associated project scope. This means the people doing the work (developers, UX, testers, etc) know what to build but also why they are building the functionality, how the functionality fulfils the business outcome and and who the functionality is for. Love it.
As it happens Programme Managers already have a very similar tool for a similar purpose. Benefits Maps, like Impact Maps, are used to visualise business drivers and associated scope, in this case programme scope. They answer two key questions:
The dual function – showing why and how – make Benefits Map high value documents. It also means a Benefits Map can easily morph into the initial Programme Blueprint. For a simple programme the Benefits Map may be the only Blueprint. And the diagram format means it fits on one page. Even in a world where we value “Working software over comprehensive documentation” that one page is worth having.
Continue reading