It wasn’t too long ago that a manager asked me “surely, you don’t use agile for everything”?
What should you use agile for? Are there instances where it doesn’t make sense?
Simple processes
When the work problems are simple, processes and standard operating procedures dictate the actions people should follow. People have found over time that certain events require specific actions and, if followed, there’s a clear outcome that is repeatable. Simply, people know when they follow the process you always get the desired outcome 100% of the time.
These work environments require:
- Little communication: Just follow the process.
- Command-and-control: Take the delegated tasks and solution the manager handed down and execute it.
- Defined processes: Optimise these.
- Reporting: Report to the manager on the progress of the process and the tasks handed out. Reporting provides clarity about how far along you are and how long it will take to get to the end of the process.
Using Waterfall makes sense to use in a simple environment. Creating a plan and executing it will guarantee the outcome is achieved as planned and designed.
Waterfall or Agile?
An organisation I was working with needed to replace some IT hardware. There were numerous standard operating procedures in IT regarding how to choose the right hardware device, processes and regulations from Finance about procurement, and instructions from manufacturers on installation.
The solution was obvious to the team. So, they followed the procedure.
The team could have used Waterfall to deliver the work. They didn’t. This was already a Scrum team, so they put the items into their Product Backlog and delivered the parts in Sprints until they were all integrated. Then, they turned on the solution. This approach gave them flexibility in what order to deliver each part.
Complicated work: the domain of experts
Some work can only be delivered with more than just one process. Experts are often needed to help define the problem, generate insights, and identify solution options, particularly when there is more predictability than unpredictability about the work.
These work environments require:
- Using experts to gain insights on how to proceed.
- Use metrics to gain control.
- Collecting requirements, analysing the requirements, responding with a solution decision, and a plan.
- Command and control: Directing people to execute the plan.
The “Double Diamond” of Design Thinking is often applied in these circumstances.
Overall, the framework assess the facts, analyses them, and asks experts to then apply an appropriate, good design pattern or practice, to then test. According to Stewart (Management 2.0, 2002) “here it is possible to work rationally toward a decision, but doing so requires refined judgment and expertise’.
When used in a linear way, design thinking is executed as Waterfall with stage gates applied to each of its steps: discover, define and then definition of the requirements.
After collecting the information, experts:
- Sift through all of the data.
- Identifies several issues and insights.
- Suggests opportunities for improvement, innovation, pain points, etc.
- Completes the architecture and design.
This process takes time — a lot of time in some cases. Sometimes it’s taken so much time the organisation’s environment has changed, and so has stakeholders’ needs.
Waterfall or Agile?
I’ve personally participated in Double Diamond/Design Thinking cycles that took over a year to complete due to the highly complex nature of the subject area, the number of teams contributing, and dependency areas. The ideas were robust, the solutions were logical, but working in this way had handovers between the UX/design work and the software development vendor. What was designed was an hypothesis at best. We had no true idea whether solutions would be possible. While integrating more extensive communications with the vendor was useful, solution designs had to be changed in development to ensure it was functional. Sometimes, solutions had to go back to the drawing board.
When I look back at the 18 months of brainstorming, idea generation, testing, and re-design, the solution could have been delivered much earlier had we instead:
- Designed and delivered a small amount of the solution – something that actually worked.
- Obtained feedback.
- Iterated through the next part.
Working in this way would have required:
- A single, cross-functional team – UX, BA, software developers and architects all working toward a single goal as one team.
- Shorter work cycles (“Sprints”).
- Learning lessons from integrating and iterating the solution to improve future solutions.
This is a project that could have benefited greatly from using Scrum over Waterfall.
Complex Work: How do you know the solution will come together?
Complex work is defined as having more unknowns than knowns. Managers of Business Analysts and Architects would recognise it easily:
- Requirements seem never ending – as you uncover one set of requirements another is exposed.
- Many competing ideas – there’s no one solution that could be explored.
- Emergent answers – the idea is that the design of the solution will emerge little by little as we build up and integrate the solution in small increments.
The tendency for proponents of Waterfall in these environments is to assume that comprehensive planning and design will provide the solution and de-risk the outcome. A leader’s role, instead, is to:
- Create and support an environment where interaction and communication supports ideas to be generated.
- Create guardrails for action – timeboxes and essential roles.
- Promote experimentation of iterated and incremental solutions.
- Collective learning about the evolving solution.
Waterfall or Agile?
Waterfall is a predictive methodology. Through planning and design it attempts to ascertain a future state and, therefore, understand the effort and cost needed to create that outcome based on that plan. If the solution can only evolve, using Waterfall in a complex environment is fatally flawed. If no plan survives contact with the enemy, a plan generated for a complex environment through Waterfall will fail as soon as a manager starts to execute it, regardless of how many stage gates it progresses through.
"No plan of operations extends with certainty beyond the first encounter with the enemy's main strength"
An adaptive agile framework like Scrum, is designed for complex environments. Based on the Deming Cycle and events that support empiricism, even the humble “Daily Scrum” operates to inspect daily progress toward a Sprint Goal that is no more than 30 days away.
Conclusions
A 20th century management mindset identifies the work, selects people, and then moves people to the work. This is also how projects are resourced.
A 21st century agile leadership mindset creates teams and brings the work to teams. It applies agile ways of working to the team over choosing different types of processes that are solely defined by the work itself. The power of a team-based approach to work means the team utilises agile to then determine what practices or patterns to then apply to its work sprint-to-sprint.
Should you use agile for every type of work? No. Use agile as a set of guardrails to help a team self-organise. A leader’s job is to support self-organisation. The team will then determine how it will attack the work.
