In the world of Waterfall, all results are predictable - at least in theory. The roadmap is clear and fixed: if we do ‘X’, then the result will be ‘Y’. However, this does not account for the plethora of unforeseen changes that will arise in any project you are undertaking. If you can’t react to changing circumstances, achieving 'Y' will become very difficult and may well end up being way off the mark.
Responding to change in Agile while following a plan
Change is, most of us would agree, inevitable. In contrast to Waterfall approaches, Agile methodologies give teams a way to cope and respond to change more effectively. However, in recent years, agile approaches have come under increasing fire for being unstructured, unaccountable and unreliable - all of which can make senior team members reluctant to give sign off.
Whilst undoubtedly fluid and adaptable by nature, it is entirely possible for an agile project to have a plan, an architecture, a proper R&D phase and a deep understanding of business requirements. In fact, I would go as far to say that every one of those things is actually a strong prerequisite for a properly structured Agile project. No system - no matter how elegant or robust - can be considered well-designed unless it can actually be built.
The need to adapt to change
Much in the same way you would design a product, you must also design the roadmap to build that product. Once you have done this, you will have everything you need to provide a practical and reasonable real-world estimate of its eventual cost (resources), schedule (time), and functionality (results). Armed with this information, you will find yourself well placed to manage the expectations of your senior stakeholders.
However, these quantified components are not set in stone. They will change. And here lies the key difference with Waterfall; Agile permits the changes that are inevitable.
It is crucial to understand that any project is only as valid as the information available at a given time, and it is impossible - even undesirable - to try and predict every outcome from the very beginning. Such efforts are often time-consuming, incomplete, and provide comparatively little return on investment.
Of course, if you were given a cast iron guarantee that the list of requirements is final and complete, you might be in a position to account for all possible outcomes. In all other cases, when requirements inevitably change, particularly in a world of fast-changing user needs or UX underpinned with essential experimentation, you must be prepared - and able - to respond to change in your project/product roadmap to reflect new feedback.
It is important to remember that change is not something to be feared or avoided. Change is the driving force behind added value. Don’t resist change, but do be resilient to it.
Setting sail
Think of it like charting the course of a ship across the Atlantic: constantly monitoring and replotting the trajectory of travel as the surrounding elements jostle and jolt the vessel in all directions. Just because you cannot control the elements, by no means should the elements control you.
The first lesson here is to make small, incremental adjustments to your course or roadmap. This doesn’t mean you have no idea where you are going, so much as a recognition that time, resources and a hundred other variables mean you constantly need to inspect and adapt your route in order to reach it. And if you do discover your destination needs to alter drastically - perhaps because user feedback tells you the product you’re building isn’t the right one - Agile practices will help you discover that earlier, and minimise waste overall.
Similarly, as you would keep the Coastguard frequently updated on your situation and movements, close collaboration with your stakeholders is essential. This requires transparency, openness and honesty - and in doing so you build trust, which is critical for the overall success of any Agile project, and something our QA Manager, Christina Ohanian, goes into in more detail here.
Responding to change in Agile in the real world
Look at a progenitor of Agile and Lean ways of working: the Toyota Production System. From the middle of the 20th century, and within a generation, Toyota went from being a third-rate Japanese car producer to the most successful and efficient manufacturer of automobiles on the planet. By making what we would now recognise as the Agile Principles part of their lifeblood, they didn't just do Agile, they became agile - the key difference here, is that they didn’t just apply a process (noun; Agile), they changed their culture, mindset and approach (verb: agile). At any given point, they knew exactly what their plan of action was, how long it would take, and how much it would cost. The instant a requirement changed, Toyota were perfectly placed to harness that change, replot their course, recalculate their schedule, and redetermine their budget.
The difference was that they could do this 12 months in advance of the original deadline, instead of 12 hours - giving them plenty of time to work out:
(a) whether the change was feasible,
(b) whether it was worth doing, and
(c) how they could make it happen.
With the outbreak of Covid-19, the world has been forced into a need for agility where many were not ready. This ability to adapt in environments that are rapidly changing at a pace we’ve never experienced, has been - and will continue to be - make or break for organisations across all industries. The good news is, many, if not most, organisations have found the transition possible. Easy? Not always. But possible. If this is what can be achieved in a world undre immense stress and ambiguity, imagine what could be achieved with intentional thought, planning and action.
In conclusion, it is important to remember that the Agile Manifesto advocates responding to change over following a plan - not instead of following a plan. And while change is inevitable, all change comes with a cost: be that in time, resources or both. The bigger risk is not being ready or accepting of change.
Technical excellence, good design, and a deep understanding of the business requirements will allow the cost of change to be minimised. However, you must be in a position to accurately quantify the impact of change and respond, as soon as it arises; Agile ways of working, such as Scrum, SAFe, LeanUX or Kanban, provide the iterative, transparent, and adaptable framework to do just that.
And never forget that collaboration and communication with your stakeholders is vital. The only way to properly communicate the progress of a project in the face of inevitable change is through transparency and honesty. By being transparent and educating your stakeholders in the ebbs and flows of a project, you will give them solid reason to trust your judgement. In turn, you progressively earn the freedom to continue on a leaner, increasingly more agile path.