What Will I Get & When Will You Be Done?
If you are thinking about designing an organization to deal with agility at scale, ask yourself this question… how will you know what the organization can deliver, and how will you know when they are going to be done?
If you can’t answer those questions… you’ll never be able to convince anyone to adopt agile.
If your answer involves gigantic release plans to sequence dependent teams months in advance… that’s kind of defeats the purpose. If your answer involves a big interdepartmental Gantt chart… I think you could make the case you’re not actually doing agile at all. If your answer has the words “trust me” anywhere in the answer… I don’t believe that’s a basis for a meaningful conversation.
So… think about what you are planning to do to drive agile adoption in your organization.
Ask yourself how are you’re going to tell the business what they are going to get and when are they going to get it. The challenge with driving agile in a real enterprise, with real business drivers, is answering these questions while preserving the business agility that the organization ultimately cares about.
Do you have an answer?
Comments (5)
Andre Dhondt
Hi Mike,
In current and previous positions as Product Owner, I’ve had to field many questions about ‘when will it be done’. What I commit to is an epic–but the scope, the detailed feature set, shrinks to what’s achievable in the time available. I call it fan-out release planning–see more here: http://dhondtsayitsagile.blogspot.com/2010/04/fan-out-release-planning.html
Hi Andre… thanks for your comment. I read your post, what you refer to as fan-out planning, Jeff Patton calls story mapping. I use a similar process based around story mapping and the idea of a minimally marketable feature. I focus on risk and value early and try to drive uncertainty out of my projects early. I also use a high level estimate, that in effect becomes a budget, early in the planning process.
That said… how do you KNOW you’ll be able to deliver the business value behind the Epic? It sounds like you guys expect to have a TON of uncertainty going into the sprint. Those stories that can’t be estimated would bug me. How do you handle them?
Tim
t-shirt sizes are almost by definition not accurate. Monte Carlo style risk management in release planning amounts to adding an educated buffer to delivery. Estimates are estimates. There are diminishing returns in trying to spend too much time estimating. Yet I have worked with product owners that try to get an estimate for an initiative so they can allocate budget for it and then complain if the estimate is not precise enough.
I have seen product owners go to a steering committee to request a block of money each quarter of the year. That approach allowed product owners the freedom to allocate budget to their priorities in priority order and go back to the steering committee to show them what they achieved. But by your metrics this ends up falling into the “trust me” bucket. In truth, if there is a best practice out there somewhere for forecasting and budgeting for agile projects I have yet to see it. The “trust but verify” approach worked best on projects I have been associated with. Product is allocated a quarter worth of funding without specific roadmaps or agenda’s, and then they show what they achieved each quarter to a steering committee and ask for the next quarter of funding.
I am hopeful there will be a more canonical solution offered by someone…
Tim… thanks for the comment. I like the incremental investment model. I like to use a variant of that based on risk, but I am going to hold off with my answer until some more people weigh in… I have a few more posts I want to noodle through… so maybe I’ll share my thoughts in a day or two ;-)