The road to Agile: dealing with blockers on the way
By The App Business under Agile 16 December 2015
For a long time Waterfall was the only game in town in the world of software development. It was the first organised attempt to create some sort of order from chaos, and (at the time) it worked as well as could be expected. But times have changed and the flaws of Waterfall are becoming more apparent every day: in an increasingly fluid business ecosystem, Waterfall is a high uncertainty and (therefore) high risk methodology.
Agile can be seen as the natural alternative to Waterfall, but as we regularly discuss on our blog and see in our work, the transition from one methodology to the other is often fraught with difficulty for most organisations we work with.
There is no doubt that the change can be difficult, but that does not mean it should be avoided. In fact, the benefits of becoming Agile - we believe - far outweigh the disadvantages. You can read up on my own thoughts as to why that is the case in our Intro to Agile series - starting with part one, here.
So what holds companies back from successfully transitioning to Agile? In this post we will take a look at two of the broadest and most common impediments: governance and culture
A central component of Waterfall is to define requirements early, and it presupposes that these requirements are fixed and will not change over time. Senior stakeholders see a comprehensive and detailed plan, with reassuringly fixed costs, and are confidently assured what happens on paper will happen in real life.
What actually happens is disappointment. Things change. Costs creep. The plan begins to crumble, and frustration sets in. The final output no longer seems fit for purpose - which is not really surprising, since you probably defined it 12-18 months ago. Suddenly, the certainty you had at the outset becomes visible for what it is - a false sense of security.
And all because your requirements were always guaranteed to change - but you were unable to foresee or accommodate that effectively using Waterfall.
Now, some governance is obviously unavoidable - and rightly so when it comes to things like safety and security - but we hear time and again how difficult it is to persuade senior stakeholders of the benefits of Agile when they still equate fixed requirements and fixed costs to efficient project management with lower levels of risk.
By making the argument that a given activity or process is not providing enough value, you strengthen the case to change it - but only as long as you can provide a workable alternative. This means that when your team is given the mandate to use Agile methodologies for the first time, the key driver is to deliver demonstrable value, rapidly. This approach reflects how you align yourself with existing company processes: where the Waterfall approach to governance is reactive, you need to ensure that the Agile approach is, and is seen as, proactive.
One of the smartest moves you can make at the outset is to get yourself an Agile Coach fast - they will provide the expert guidance and mentorship that you will almost certainly need to help educate you and your team through the difficult first few iterations.
Working iteratively in short sprints means at the end of every two weeks, for example, you have the opportunity to demonstrate working software to your stakeholders. In our experience, that is one of the most powerful statements of Agile’s value in contrast to Waterfall - while non-Agile teams are still writing up lengthy requirements documents, your team is not only building, it’s delivering.
Likewise, when a quality gateway is a predictable hurdle (like security sign-off), my advice is to identify this potential blocker early on and engage as soon as possible. Governance (in its simplest form) is just another activity, so assign time and resource in order to deal with it.
That means working with ‘gatekeepers' early to figure out how to do it right in the first place, rather than waiting for them to stamp it as 'failed' a week before the deadline. The chances are that this will be a new challenge for them too - the first time they will have been asked to provide creative value instead of limiting risk. Remember you’re playing the long game - initial engagement will likely be messy and onerous, but the upfront investment will pay off in over time. By the time you have finished, you will have the makings of crib sheets, cheat sheets, and standard answer templates already in the pipeline, ready to reuse and share.
The shift from Waterfall to Agile is not just an administrative change, and more often than not the battle is as much for hearts and minds as it is for altering processes. Changing attitudes is a lot more difficult than changing processes. In legacy organisations, fear of the unknown breeds resistance to change and there will inevitably be the question: ‘Why are we doing this? Can we not just go back to the way things were?’
Even in the best-case scenarios, when people are motivated to embrace Agile, they often find it hard to shake off old patterns and routines. This is normal and to be expected: humans are creatures of overly-cautious habit.
Good, solid preparation and training can pay huge dividends here. An experienced Scrum Master or Agile Coach can set aside a “Sprint 0” to walk teams through Agile techniques at their disposal and identify preferences before development begins in earnest. This can also help identify problems that may occur in the future, iron out more efficient development processes, and prepare the team for the inevitable feeling of having to take a step backwards in order to move forwards.
Similarly, your project will eventually have dependencies on other teams that are still working Waterfall. The key to effectively dealing with this is to be proactive. When your project finds itself dependent on such a team, having clear and well-understood definitions of ‘ready’ and ‘done’ will help remove doubt or confusion as to what is required. If such a dependency is laid out in your project plan, it may pay to monitor the other team's progress to ensure your schedules are appropriately aligned. An experienced Scrum Master can also engage with the other team's Project Manager to help re-prioritise, or even assist in organising, their project backlog.
Finally - cut yourself some slack. Remember that Rome wasn’t built in a day and neither will an organisation transform itself overnight. Transitioning to Agile is a journey because it’s not about throwing up Scrum boards here or there, nor is it about writing user stories. At its core, the transition to Agile is about changing people’s habits and attitudes - something which takes sustained, consistent effort.
To win the good fight, you need to visibly demonstrate its value as an alternative to the usual ‘way we do things’: be open, be proactive, collaborate early and - crucially - get support from an Agile Coach along the way.