Skip to main content
Home » Learning Zone » Business Alchemists Blog » The World Of Change Is In Shades Of Grey
The World Of Change Is In Shades Of Grey

Few things in life are as simple as they first appear, and this seems particularly true in the world of business analysis. Many a project has been underestimated as being a “quick, simple change” when in reality it’s a hugely complex undertaking. So often there are different perspectives on a situation, which inevitably means that things really aren’t black and white but are complex shades of grey. There can be situations where a particular change would be better for one group of stakeholders but fundamentally worse for another. When this occurs, it is usually the case that there isn’t a single ‘right’ answer; the art is to find the one that gains the most positive outcome overall. 

The same is true for the methods and practices that are used during change initiatives. There has long been a passionate turf war between agile and waterfall practices. This is often presented as an ‘either/or’ choice, or even worse as an all-or-nothing methodology battle. Comments such as “Oh, if you’re not agile then you must be waterfall!” are made, as if these are the only two options. This statement implies that it’s possible to initiate change in a strict linear, predictive, waterfall way or a more evolutionary, adaptive, agile way but that no other options exist at all. 

This statement might grab attention but as a thought experiment it is useful to reverse it. Imagine hearing somebody say “If you’re not waterfall then you must be agile”. This statement just doesn’t hold true as there are clearly other types of approaches. From iterative to exploratory to incremental right through to systemic inquiry, there are clearly multiple ways of planning for, and delivering, organisational change. This highlights the logical fallacy of assuming there is a binary either/or option. After all, the world of change isn’t black and white, it is a wide variety of shades of grey. Embracing the grey helps to ensure that the approach adopted is right for the context. 

Where The Rubber Meets The Road There’s Little Room For “Purism” 

In reality, very few people practice truly linear waterfall approaches. Even the most linear of waterfall projects does iterate, even if this isn’t originally planned by the project team. There will inevitably be environmental changes and differing opinions along the way that lead to change requests. In fact Royce himself, who is credited with creating the waterfall approach back in 1970, wrote a section in his original paper advocating “doing it twice” where he highlighted that “the first result provides an early simulation of the final product”. So arguably the original intent of waterfall was to iterate, albeit in a limited and controlled way. At the other end of the spectrum, there are few people truly practising agile methods in an unaltered way either, it’s far more usual to adapt practices to suit the situation. This pragmatism should be encouraged. 

What this highlights is that, away from the purists and methodological evangelists, there are vast swathes of practitioners embracing these grey areas and avoiding the methodology wars. These practitioners are delivering business change by accepting that the world isn’t black or white and that there is no ‘one size fits all’ solution. They avoid straw man arguments which seek to completely discredit particular approaches, and instead look to blend together the best from multiple approaches. They take a ‘toolbox’ approach, finding the most appropriate blend for the situation. 

It is perhaps worth remembering how little this argument really matters to the customers and beneficiaries of the products and services that we define and design. A shopper using a self-service check out probably has no idea whether new features are delivered in an incremental/phased way, or whether they’re delivered every day via continuous integration. Nor should they need to care—they just want to pay for their shopping and they want it to work. In fact, delivering new features too frequently might actually be a bad thing as it can be disorienting.  In other situations, it might be entirely appropriate to release a minimum viable product, get feedback and then release features more often. As ever, context is crucial!

Contact Us

Need help?

Please call us on

01844 211665