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.
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
So, 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, 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.
So it is crucial to understand that any project is only as valid as the information available at the 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, you must be prepared - and able - to change your project roadmap to reflect new circumstances.
It is important to remember that change is not something to be feared or avoided. Change is the driving force behind added value. So do not resist change, but do be resilient to it.
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, so close collaboration with your stakeholders is essential. This requires transparency, openness and honesty - but in so doing 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.
Agile in the real world
Look at the progenitor of Agile: 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. 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.
So 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, money or both.
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 give us the iterative 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.