Lowering Risk Using Agile and Lean Methodologies

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

We asked Jacque Harper, User Experience Architect of Pathfinder to write a post with his perspective on the space:

Several common types of risks in software development can be mitigated by using Agile, Lean and a user-centered development process. In this post, we will look at three types of risk:

• Risk of Poor Design, or the Wrong Features
• Risk in the Marketplace
• Risk of Unknown Factors

Risk of Poor Design, or the Wrong Features

This is the risk of building a feature or function that customers will not pay for, or will not use – or the risk of designing a feature (whether it’s in visual design, interactivity, or even the architectural design of the application) that frustrates users or complicates the operation of the system to the point where it will not be used. Building the wrong features or building the right features in a way that makes them unusable wastes money and time, and ultimately saps morale.

While marketing research is valuable and useful, even the best market research is still an experimental thesis in comparison to the fact-based, empirical knowledge that comes from actually getting a product in the hands of users. There is no better way to know if your customers like your product than to actually have them use it and provide feedback.

Similarly, putting your architecture to the test in a production environment is the best way to be sure it is production-ready, even for a small percentage of the expected number of active users.

Lean and Agile processes emphasize creating value (most commonly through releasing a product to paying customers, although that is not the only workable definition of value) and getting feedback early and often. The individual elements that make up your product should be distinct, ordered and/or prioritized so that you can make a simple test product available to users and receive feedback on it. If the feedback is negative, you can improve the feature or decide that the feature is not the right feature and start over with a different approach – or move on to something else.

If the feedback you get is marginally positive, you can choose to improve or enhance the feature. And if you get rave reviews for that first feature, you can move on to a new/next feature, beginning a virtuous cycle of product improvement and value enhancement. This process can apply to the design and/or implementation of a feature or a function.

What’s critical to this approach is the concept of completing functionality – in small pieces – before starting other functions, and committing to making functionality available to actual users as soon as possible. These critical steps give your development focus (one thing at a time, done to completion) and provide real data for decision-making, rather than theories.

You can reduce the risk that comes from either poor design or having the wrong features by releasing on short cycles, and test with actual users as early and as often as possible.

Risk in the Marketplace

Markets are ever-changing, and for a number of reasons. Competitor innovation, new distribution channels, shifts in technology platform adoption and changes in customer needs and preferences can all make a brilliant idea obsolete in a hurry. This risk can be minimized by building complete functions, and being able to reprioritize them quickly as needed via an Agile methodology.

Agile processes emphasize delivering value as early as possible. This means focusing on completing a single or distinct function, rather than starting and finishing many different functions at the same time. For a product owner, this means that when a functional element is done, it is DONE. No stubs of incomplete functionality remain. There is no “waiting for the back end to be developed.” Nothing is “about 90% done” for weeks at a time. This way, the team can really give their full attention to the next feature.

And because you haven’t spent too much of your energy in “distant-future thinking,” you’re not emotionally committed to something that “seemed like a good idea at the time.” You can freely shift your energy in a new direction.

This is the greatest power of Agile development – being able to react to change quickly. When the marketplace changes, when a competitor introduces a new killer feature, or when customers’ tastes change, you can change direction with minimum waste.

Risk of Unknown Factors

• Risks due to unknown factors come in many flavors, of course.
• The development team may not completely understand the request…
• The technology that’s going to be used may be new…
• The data may be less well organized than expected…
• Technological capabilities (speed, scalability, reliability) may be different from what you assumed…

and more.

The best way to deal with potential unknowns is to make them known. An Agile process with an emphasis on whole-team participation and communication can be leveraged to explore and expose unknowns.

First, a well-maintained backlog can help the team see into the future and anticipate risks inherent in or implied in the stories they tell. Those who know about the risks can advocate for working on those issues earlier in the development cycle to expose the risks, confront and eliminate them before other work is initiated.

How is a backlog different from a complete requirements document?

An Agile backlog, which is available to all team members for discussion and exploration, represents a simple list of desired features. In a “waterfall” process, the requirements document is passed sequentially from specialty to specialty within the development organization. Groups focus on their own areas, assuming that other groups are capable of doing and will do the work required of them. The areas “in between” specialties tend to become the places where problems develop. Typically, Agile teams involve people from all specialties – and they’re the people who will be doing the work, so they know their own capabilities. These people will work together to understand, then actually build the working code. They don’t just debate approaches or define APIs.

In order for the risk of unknown factors to be successfully eliminated, the backlog must be well-groomed, and discussions of actual depth must take place. But they cannot be so deep as to constitute doing the work – just deep enough to sense the presence of risk and be able to prioritize it against other features or needs. The development team and product owner must be able to discuss the presence of risks and the values of features (versus other features) frankly and honestly in order to arrive at a consent-based agreement on how best to address the risks.

What happens when the team feels it has discovered something “risky,” and that item has been prioritized to the top of the to-do list?

This question assumes that:

1) The product owner has agreed that there is risk, and at some level understands it.

2) Resolving this risk is important enough to delay development of other features. If that is not the case, then maybe the question needs to be asked again: Is this risk important enough to confront?

The team can confront this risk early in the project or product lifecycle, and try various solutions to mitigate or eliminate it. If no solution is found, and something has to give, other features of the product can be adjusted. In short, more options are available to the whole team when risk is confronted early.

Conclusion

Testing features and functionality in the real world, reacting quickly to a shifting market landscape, and surfacing unknowns through examination of a backlog by a multi-disciplinary team are all important ways that Agile and Lean development processes can reduce risk on development projects.