Fluid Planning and Execution Creates Agility

Thought leaders in the US military are challenging traditional approaches to command and control. These military innovators are proposing a more fluid approach that allows simultaneous planning and execution. It is good to see they are catching up but as an Agile practitioner I already do fluid planning and execution.
Continue reading

When Buckets Go Bad

I use the term Bucket Planning for Release Planning. The metaphor works because buckets overflow if overfilled. There are risks associated with Release buckets corresponding to Minimum Viable Products (MVP). A large MVP bucket has gone bad and a MVP Bucket that continues to grow is a Bucket gone really bad.
Continue reading

User Story Dependencies are more Apparent than Real

What do I do when a User Story is dependent on another? Well, the most important thing is, to quote the Hitch Hiker’s guide to the Galaxy, “Don’t Panic!”.

I believe dependencies between User Stories are often over played. Sure there are dependencies but often these don’t require any particular management. But even more common are invented dependencies, i.e. dependencies that are more apparent than real. This means dependencies for me are a bit a of requirements smell, i.e. something to be worried about.
Continue reading

Reporting Percentage Complete on an Agile Project

What do you do when management asks for a percentage complete on an Agile project? The flippant answer is “tell them the percentage complete”. Agilists reject percentage complete when reporting on low level stuff. But for the project as a whole you can get quite an interesting metric, one that is based on real data, so why not calculate and share it.

Continue reading

Daily Plan: Stand up to Plan the Day

“Stand up please”. Old habits die hard and because I started Agile with Extreme Programming I “Stand up”, I don’t “Scrum”. Otherwise the two types of meeting are pretty similar. “What have you done since we last met? What will you do before we meet again? Any impediments?”

Great meeting. Wrong questions.

As Mike Cohn explained back in 2006, and Matt Wynne reminded me last year, the daily meeting is a Planning session. It is part of Mike’s planning onion because the aim of the “Stand up” is to develop the plan for the day.
Continue reading

How to Juggle New Product Development with Operational Demands

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

Benefits Map: Impact Mapping for Programme Managers

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:

  • Why are we doing the programme?
  • How will we realise the benefits?

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

Revisiting the Iterative Incremental Mona Lisa

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 projects 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.
Continue reading