Lots of ‘done’ stories doesn’t mean the software is ready for delivery.
Risk is a small word with a massive impact on software development teams. Does your company culture encourage or discourage risk-taking? Are your software teams authorized to take risks? What happens to people who take authorized risks and fail?
Here’s the problem. A company hears about agile software development. It sounds good. Rapid release cycles, frequent deliverables, many checkpoints…what’s not to like?
The risks are different.
In a traditional command-and-control approach (like waterfall), there are some common risk factors. Here are a few:
- The business situation may change before the project is complete.
- The underlying technology infrastructure may change.
- Requirements may be incomplete or wrong.
- User needs and acceptance criteria may be poorly defined.
- Work estimates may be optimistic.
There are many more potential risks but you get the idea.
In an agile development approach (like Scrum, XP or Kanban), some of the risks are different. One, two and three above are non-issues because agile approaches expect change. Number four is a non-issue because user needs evolve during the course of the project. Number five remains as an agile risk.
Here’s a brief overview of some new or increased risks faced by agile projects:
- System architecture and design may be inadequate at the outset requiring major changes later.
- Inadequate business involvement may cause delays and missed information.
- Early sprints (iterations) will deliver unfinished results that may not be favorably received.
- A development plan that lacks details and evolves with the project may frustrate management.
- Open communication, self-organization and frequent retrospectives may imply that the team is a constant work-in-progress.
Many waterfall risks are founded on “change management”. Every time something changes there is a cascade effect that impacts documentation, code, cost and schedule.
Agile approaches reduce those risks by creating an environment that expects changes to happen and actively encourages them. In so doing, agile approaches create a new set of risks founded on “completion management”.
The core problem is that during an agile project nothing is complete or final until the end. Requirements (stories), specifications, user interface, source code, test plans, acceptance tests, etc. are all in an unfinished state until the end of the project. Those accustomed to command-and-control may find it extremely difficult to accept this.
Here’s a simple analogy.
Imagine you are remodeling your home. You don’t hire anyone. This is a do-it-yourself project. Instead of starting and finishing one room before going to the next to minimize disruption, you decide to tear apart the whole house at once. It may be the fastest and most economical approach but it creates a lot of anxiety. Nothing is complete until it’s all complete. Image how your family would feel as you iterate over the entire house scraping, sanding, cleaning, replacing, upgrading, painting, etc.
Agile approaches are similar. They create anxiety because there is no complete plan (i.e. a gantt chart) and nothing is complete until the project is over.
I recognize that stories have a definition of done but stories are bits and pieces of the solution. They are not complete until they are all complete (for this release, at least).
People and expectation management are keys.
Managing down, sideways and up is critical to successful agile adoption. Expectations must be micro-managed so everyone knows what they are getting at the end of each sprint and why.
Interim sprint deliverables are for soliciting feedback and encouraging change requests. While the software may be ‘shippable’ at the end of any sprint, it is not necessarily suitable for daily use in business operations until a solid base has been created.
Enterprise agile is more difficult than it looks. Can you handle the risks?