A post in my RSS feed caught my attention recently. It’s by James Shore, author of “The Art of Agile”. His post is in response to this conversation on an Agile mailing list, about whether Agile can help with predictability in software development.
The conversation got me thinking… and here’s my perspective.
There are two scenarios where predictability is asked for.
The first scenario is in the context of a stable Agile team, with an existing backlog. In this context, a question about predictability is generally equivalent to a question about reliability, and it’s relevant to small-scale items. The team will be asked how long it would take them to deliver a story or feature, and they’ll give an answer. The more mature they are (“fluent” as James has it), the more accurate their prediction is likely to be. A good Agile manager / coach can help a team improve this.
If the request comes in the form of a good user story, it’ll be small and estimatable; if the team is stable and mature, it’ll know its cycle time. Put the two together, and reasonably accurate estimations of lead time should be quick and painless.
Here at MAS, we’ve adopted the common practice of backlog refinement meetings (often referred to as “sprint pre-planning sessions”). This is a regular opportunity for new or revised stories to be put before the delivery team, who can then assess the effort required to deliver each one.
The second scenario is in the context of a new team or project, and is generally asked about a product, rather than a feature. Organisations often want to know how much a project or product is going to cost to deliver, or how long it’s going to take. There are always budget and cost concerns (“is this thing worth doing?”). There may also be other reasons to need high-level predictability, for example: the need to align with a marketing promotion that has a long lead time, or the need to meet a contractual deadline, or the need to get the product to market in time for some external event, or just the need to plan when the next big project can be taken on.
This is a difficult question, and is best addressed by breaking it down into two parts. The first part is about how to come up with good initial estimates of project size or product cost. The second part is about how to reduce uncertainty and risk once a team has begun work on a product.
Initial project estimates
Initial estimates are the trickiest part, and the most likely to cause a team or organisation pain, if they’re badly derived or (as is very common) misused. How can we give a good initial estimate of how long something will take, when we know very little about it?
There are a number of techniques to help do this reasonably well, and they mostly come down to a single principle: don’t just do one big estimate once.
Here at MAS, for example, we’re implementing a phased process. Others can give more detail on how we’re doing this, but the relevant points are that we start with Discovery and Alpha phases. At the end of both of these, we may decide to stop a project, or change our thoughts about the product to be built, or revise our estimates of the overall time and effort required to build the product.
At the very beginning, we don’t try to estimate the size of a whole project, we just size the Discovery phase. This is kept short and focused, and is primarily intended to validate the user needs and make a case for how we could address them. At the end of this, we’re in a better position to estimate the time needed for the Alpha and subsequent phases.
In the Alpha phase, we do prototyping and user testing, and answer questions about design and technology. At the end of this, we’re again in a better position to estimate the time needed for subsequent phases. If we think our initial estimates need amending, we do so, and communicate and negotiate with governance and stakeholder representatives.
Risk and uncertainty in projects
Once you have a revised estimate, and you’re into Beta and subsequent phases with a full cross-functional team, being predictable is all about reducing risk and uncertainty. And it’s here that Agile methodology itself gives you everything you need.
Your team has its set of user needs to be met, and its idea of a product that should meet those needs, and it builds its backlog of user stories to work on. As the team works to deliver these stories, it builds a product with features.
While this is going on, the external stakeholders or managers that are concerned with “predictability” still want to know: “Am I going to get this product by the time I need it?”
Breaking down work into small pieces, and making sure each is completed, means that we can always see our rate of progress through the backlog (velocity). Using user stories as units of work means that the developing product has value to users from very early on. Having a Beta release, or MVP, well before the stakeholders’ deadline, ensures that something is done (and hopefully generating real feedback from real users) and safely “in the bag”, removing the risk that there will be nothing to ship. Limiting work in progress via iterations (as in Scrum) or workflow constraints (as in Kanban) keeps the team disciplined about having a regularly-updated, potentially-shippable product, removing the risk of spending time doing work that isn’t delivering value. Keeping progress artefacts (release plans, burnups, and taskboards) updated and publicly visible removes uncertainty.
So your stakeholders know that they’re going to get their product by the time they need it, because they will have seen a working version of it well in advance. And as their deadline approaches, they’ll always have a clear view of how the product is shaping up, as features are added and improved.
Agile does not enable you to predict exactly what a team will have developed, several weeks or months from now. But it does give you the tools to answer the concerns that people really have when they ask for predictability.