Can You Take An Iterative Approach To Implementing Agile?
Just like a tale of two cities, Agile implementations can be the best of times or the worst of times. Too many of us have seen the worst approach. Leadership decides Agile is the shiny new must have and direct a team to make it happen. The leadership team doesn’t understand Agile concepts, the implementation team doesn’t have needed backing, and isn’t long before everyone goes back to their old bad habits. Time is wasted on training and change management only to end up with the same wonderful disfunctions we always had with new names and a little more frustration.
Brad Wilson defines this approach of halfheartedly implementing Agile as:
Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.
However, Scrummerfall isn’t the only path that an Agile implementation can take. While Agile purists often use the term to refer to anything less than their definition of the best process, Agile suggests taking an iterative implementation approach. That means starting small, slowly rolling out concepts, and testing as you go. By nature, taking an iterative approach means you’re combining Scrum and Waterfall as you transition from one to the other.
Another problem of defining any mix of Agile and Traditional approaches as a disaster is that many core Agile practices are just good project management concepts. For example, if you sit down with an experienced PM to explain Scrum, key points could include:
- You rearrange the work into pieces that can be quickly finished to be able to show the client what the end product will look like, test the process from start to finish early on, and be able to quickly release changes into the company to get value.
- You meet with your team regularly to better understand what you’re doing and work together to find the right solutions.
- You regularly look at the work ahead and plan the details of what is needed in the short term.
- You meet with customers often to show what’s been completed so far and get input on the direction.
- You take time to stop and ask the team what you could do differently to improve.
I don’t know many project managers who would argue with any of the tenants, including the first one which could also be referred to as a pilot.
Which takes us back to the key question of this article, can teams take an iterative approach to Agile, implementing individual concepts and then building on them? If taking an incremental approach is the right answer, why the disasters with Scrummerfall?
In this article, we’ll look at different approaches to implementing Agile, key traps that can derail success, and low hanging fruit teams can use to fuel the implementation going forward. An important part of the journey will be understanding the strengths and weaknesses of both Traditional and Agile approaches, where they are similar, where they are different, and how to use both.
We’ll start that process in our next post – Understanding the Traditional Approach