As our coaches engage teams and waterfall processes are the norm; the challenge can be the collective mindset. One particular client described it thus ' Individually we get it and want to be agile, but when we come together we are dis-empowered'.
What is Waterfall Mindset?
This blog is not long enough to answer the question posed. But here is a current example we are encountering. Building modern systems is difficult. New cloud and hybrid architectures are complex and need experimentation as an approach to evaluate viability. Whats needed is a fail fast mindset but Waterfall is an avoid risk and never fail mindset.
But what does this mean when you include the word collective? It means that old ways of working persist even if individuals can see the attraction in new ways of working. How we relate to peers, leaders and sub-ordinates is ingrained in how we communicate and interpret communications. Ever find yourself in a meeting thinking – ‘I know he/she said that but what he/she means is’. Agile values don’t make room for this type of second guessing. But you cannot tell people to ‘adopt agile values’ and expect change.
Waterfall originated in aerospace and defence domains (Prince 2) where people died if things went wrong.
Back in the early days of computing, when things went wrong it equated to death in the eyes of the CFO as large sums of money were written off. I.T. was often moved under the direct control of Finance as risk management and mitigation become the ‘way we do things around here’. Today this is the prevailing culture for companies with older systems and process.
Waterfall is a command and control system. It says that teams can plan up front when they will deliver working software and what features are included. (Lets leave budget and quality to one side for now).
To do this requires significant effort to foresee what could go wrong, and first hand experience of having done many similar projects. The rate at which technology changes means that many projects are in fact different. There is rightly a focus on risk identification and an assumption that a majority of risks can be identified if not upfront, than at least in flight. Waterfall mindset says ‘IT is in control’.
But we know from Cynefin that unknown unknowns (thanks Mr Rumsfeld) can occur and we can only accommodate this after the event when cause and effect have been deduced. Waterfall says ‘that’s ok sh*&^t happens’ – lets recalculate a later delivery date and/or a reduced scope.
As more unknowns are revealed the cycle of recalculation recurs. Credibility is lost, the team is demoralised and the business accepts less than it wanted to staunch the haemorrhaging and rescue what they can from the project. It’s a stressful death march for everyone.
Waterfall mindset remains intact however, because the process worked. Prince 2 or PMP couldn’t foresee unknowns and accommodated them in the prescribed fashion and ‘retained control’ of the project throughout. Yet these projects are failures. Frequently IT will bear the brunt of it, and since business funds IT their perception quickly becomes reality.
Why do we as smart IT Professionals feel obliged to convince the business we are in control especially if historical evidence is to the contrary? The most recent Standish Group’s Chaos Report reveals only 29% of IT project implementations are successful, and 19% are considered utter failures.
But what if we told the business the truth – we don’t know what we don’t know. Business people are used to making decisions and taking risks with incomplete data sets. They frequently have to execute to some extent their business plan before they can gather enough data to make a fully informed decision. They have all read the books about Black Swan events.
What if we plan to deliver enough working software based on prioritised value to the business? When we hit an unknown we advise the business accordingly. And because we have warned them upfront that this might occur we have not undermined ourselves.
In fact we are more in control because we have not committed beyond our first ship date for initial features in agreement with the business’s priorities.
Better Business IT Collaboration
When we now call out a risk that features will be delayed, the business can determine whether to continue with the development or not. If the delivery proceeds in this fashion we start to develop a better understanding of that particular system, and we learn more about the velocity of the delivery team, thereby increasing short term predictability.
We are not saying we are better equipped to foresee unknowns. We are saying that by being more open and collaborative with the business we increase the probability that we deliver more value sooner, all the while building the business’s confidence in the DevOps team.
To achieve this we must unlearn the waterfall mindset and accept we are not in control beyond a boxed time period. We need to work more closely with the business to prioritise delivery around customer value. Business and IT need a shared understanding of risk on software projects. These steps pave the way for new teams formations with business and IT subject matter experts.
It’s important that we don’t try to explain software technicalities to the business but money is a good common language. You could try sharing this article to get the ball rolling! Or try to understand how the business manages risk in non IT settings.
If you want to unlearn waterfall and explore new ways of working, our coaching and mentoring offers may be of interest.