Recently we were asked to help make some traditional waterfall projects ‘more agile’. On investigation it wasn’t clear if the work would be better off with a switch to agile, and if that part of the organisation was ready to support an agile way of working. To provide more clarity we created this guide to help consider if agile was the ‘right’ approach, and if so – what conditions needed to be present.
First, consider if agile is an appropriate approach for the work to be done. One model that can be useful is the Cynefin framework to help make sense of the type of problem being solved:
Erwin van der Koogh in his article Understanding Complexity: How to survive in an increasingly complex world does a wonderful job of explaining the framework, and is worth the read. In summary, the four domains can be described as:
- Obvious is simple problems with known and often best practice solutions. We simply need to sense the type of problem, categorise it and then respond with the appropriate best practice. Think ‘tic tac toe’ – simple rules, where the relationship between cause and effect is known and outcomes highly predictable
- Complicated is where with the right expertise and detailed analysis we can determine what might happen. After making sense of the problem, applying the right level of analysis we could select one of a number of good practices that will get the job done. Think of a game of chess – whilst the number of pieces and moves possible are complex, with detailed thought you can plan out strategies and a number of moves ahead
- Complex is where the relationship between cause and effect is not discernible upfront – only in retrospect, regardless of the amount of analysis upfront the path to ‘done’ is not clear – we know things will change. Here we need to take action, make sense of what happens and then adapt our response, Software development (being a creative activity) often falls into this category where achieving outcomes requires continuous adjustment based on feedback. Think a game of poker – beyond the rules, bluffing and human behaviour adds a large element of uncertainty to the game.
- Chaotic is where there is no relationship between cause and effect, nothing can be predicted, events are chaotic and we simply need to take action, make sense of it and then respond, hopefully in so doing we move things back to one of the other domains. Think child’s play: leave a bunch of kids in a room and see what happens. The are no rules, things are highly dynamic, changing frequently in ways unknown to observers. Chaos can also be a place for significant opportunity, innovation and changing the status quo – you only need to think what is happening in the world right now with COVID-19, within the chaos what worldwide shifts are also occurring?
In general, an Agile approach is most suitable for work in the Complex domain. A Waterfall approach works well for problems in the Obvious domain. Either Agile or Waterfall might be appropriate for work in the Complicated domain.
For our client, once they had determined agile ways of working was appropriate, we developed the following criteria to help them assess their readiness for the change:
Organisation Readiness – Checklist
- There is a genuine desire to create and support the environment for an agile way of working
- The vendor is onboard, and contracts are supportive for an agile way of working, such as:
- The ability for team members to operate outside of strict roles
- Not all requirements will be defined up front, change is welcome, and scope will vary
- We value meeting the outcomes over following a strict plan
- Behaviours and technical practices that support agility e.g. collaboration, openness, pair programming, continuous integration
- Stakeholders support agile events and ready to consume information in a new way
Team Readiness – Checklist
- We have identified a stable team who are predominately allocated to do the work, and they have the core skills to complete the majority of the work
- There is a desire from the team to want to work in an agile manner
- The team are willing to embrace Scrum (the preferred method for this organisation):
- There is a Scrum Master on the team who wishes to develop an agile mindset, learn and teach agile values and practices in service of the team
- The Development Team has a single Product Owner who is empowered to make product decisions that will serve the business and customer needs
- The Development Team are willing to learn and experiment working collaboratively together in an agile manner
- The Scrum Team embrace transparency, inspection and adaption
If the above criteria is not true, and unlikely to change, consider that Agile isn’t all or nothing. There are still benefits you can get from leveraging some agile practices or adopting Kanban which allows you to start with what you do now. For example:
- visualise the teams work
- having daily stand ups to coordinate your work
- hold retrospectives on a cadence to support continuous improvement
- breaking up the work and prioritise based on value
- doing less by defining a minimum viable product
Hopefully this guide will help create choice in what delivery approach to take. Not everything needs to be agile or waterfall. It is better to ask “what’s the right tool for the job in front of you?” If it is agile, the organisation and team have choice, they could start small or ensure they get the foundations in place when going all in.
