In many industries, agile development has become standard practice for creating software applications. The benefits are clear: the methodology produces faster results, and often, superior software. So, what are the drawbacks to agile?
For the project manager, the drawback is risk. Project managers live with the reality that software estimation is messy and uncertain, and that in order to be successful at their jobs, they must find a way to thrive in spite of those challenges. The iterative, highly adaptable model of agile development works very well for developers, but if not managed correctly it can wreak havoc on project managers.
Project managers crave predictability, since they need to manage timelines and budget. We’ve created a simple methodology that creates better estimates and helps project managers better understand risk.
Quantify the Uncertainty in Agile Development
Software estimators rely on “user stories” to create an estimate. These user stories are well understood in agile development, and are framed as a core feature needed by a stakeholder and for what purpose.
The problem is that humans are especially bad at accurately estimating how well they know something, or how easily they can complete a complex task. When software estimators pad time or give a time range to account for this uncertainty they do not help project managers mitigate risk.
However, there is a better approach. Estimators can modulate the range of outcomes for any specific task by assigning a range of uncertainty to each task. The scheme that we find most effective is breaking uncertainty into three groupings-- green, yellow, and red. We call this simple system the Risk Key.
Risk Key Definitions:- Green represents certainty; the estimator knows with high probability that the task can be completed in a specific amount of time.
- Yellow reflects some uncertainty; the estimator knows some of the aspects of the task, but may be uncertain on others.
- Red represents significant uncertainty; either the story is unclear, relevant data points are missing or the estimator does not know how the task could be performed.
The outcome of using the Risk Key system along with Agile is that there is both a number estimate which represents complexity as well as a color which represents uncertainty. A highly complex task that seems like it will take a long time to complete that is red is far easier to understand why it poses a development risk than a task of the same complexity that is green. Now, decisions can be made with these risk factors considered more fully. This helps immensely with prioritization, and allows project managers to work more effectively towards the next step, which is collapsing that risk.
Collapse the Uncertainty to Mitigate Risk
The Risk key is great for understanding the magnitude of uncertainty, but it also helps to categorize the uncertainty by its source. There are two types of uncertainty in most software estimates - implementation uncertainty and scope uncertainty.
- Implementation uncertainty includes questions about how a
development team will approach a task and if they have access to the necessary files and libraries to complete the task.
- Scope uncertainty includes decisions about what a feature is, use cases and navigation detail.
A bit of research into the task can usually collapse the implementation uncertainty, to the great benefit of the project and the project manager’s peace of mind. Scope uncertainty is harder to collapse up-front and some teams will prefer to carry scope uncertainty through the project.
The next step in the process is to remove the red. This can be accomplished by either prioritizing the unknowns, allowing the development team to put the heavy lifting up front, or to remove the features that represent too much risk without being core to the product.
Unlike padding estimates which can result in tasks being removed unnecessarily, In the Risk Key system, a red task might be quickly and easily moved to green with a small amount of research that effectively collapses the uncertainty. The Risk Key allows estimators and project managers to communicate about uncertainty, and investigate opportunities to mitigate risk before decisions about the scope are made.
Constant, Transparent Communication
Sometimes, in application development, steps that we thought were easy become hard, and hard problems are easily solved. The key in all situations is strong communication up and down the project.
This is important within the project team as well as with the client. When communicating, people are prone to subjective words, like “really” or “very”. The Risk Key system helps standardize the entire team on a common vocabulary. Tasks are no longer described as “really hard” but instead in black and white - or more accurately green and red - terminology.
The Risk Key system also provides an easy way for project managers to review and share with executive and key stakeholders. The simplicity of a color-coded system breaks the
agile process down to one any business person can understand.
Conclusion
The reason agile product development programs so frequently run over time or over budget is because humans are quite bad at understanding probability and predicting the future. The Risk Key system safeguards us against our own failures and restricts us from attempting to do exactly what we are bad at - estimating uncertainty.