Waterfall Transformation Payday Accelerators

The first and foremost digital transformation payday accelerator and the single most important reason that the waterfall concept was originally introduced is still valid: In large‐scale sequential big‐bang settings with a clear target, you can hope for better ability to plan and manage budget control, lower external and internal communication cost, and more manageable reskilling requirements.

Waterfall Transformation Payday Decelerators

Obviously, all these benefits come at a price. Waterfall requires you to control a large‐scale project with hundreds or thousands of team members up‐front by doing a proper analysis, planning, and execution. What is missing from this equation are the uncertainties, the changes that occur over time (driven by internal and external factors), and the unmanageable complexity of such projects. No matter what, waterfall approaches will progress slowly until any impacts of what you do become measurable. Even worse, you may end up investing in a target state that is no longer differentiating from competition once you reach it or you will have to invest twice to make that happen, once in your legacy and once in the new technology implemented. Also, in reality, the hope of being able to plan often turns out to be a naive dream. The results are many failed commitments, unrealistic timelines, and false expectations based on planning with very little knowledge.

Agile Transformation Payday Accelerators

The advertised, digital transformation payday accelerating benefits of agile are clear. I am sure they have been presented to you in flashy presentations many times. If done the right way, you can expect reduced cost, reduced development times, higher quality, and faster time to market, and you will enjoy a more manageable risk portfolio because of more intermediate checkpoints and simpler decision processes, but most importantly, you leverage the opportunity for a much better value‐based prioritization with quicker reactions to market‐driven scope changes. This is especially true when agile acts as an amplifier together with the previously described reactant/scope choices. Obviously agile is easier to implement at the edges of your business, that is, in frontier or adjacent business models (e.g., a new product) or functionally (e.g., in front‐end website design).

Agile Transformation Payday Decelerators

While all this might sound like a no‐regret decision to implement all over the place in your digital transformation, problems typically materialize when agile is taken from such a generic concept to a real‐life program at scale and beyond the edges of your organization. Sadly, if not set up correctly from the beginning, most agile transformations will be doomed to fail before they even start.

First and foremost, you cannot start your agile transformation on the go. People often think they can transform the organization and their staff just by doing the program in an agile way. The concepts initially seem to be so simple that this must be possible. But it is not—it requires a paradigm change that has to be managed on its own, and, more importantly, it has to be seen as a real change effort. You must invest heavily in your customized end‐to‐end agile target operating model up‐front or you can be sure of value‐destroying breakwater barriers popping up whenever agile methods and traditional management and governance principles still in place coincide. This can be a beautifully designed DevOps concept in IT being hindered by traditional business‐requirement thinking on the business side or the other way round—an agile product design process in business hitting the wall of traditional legacy release trains in IT. And all that at substantial governance cost to steer around such inefficiencies. At the same time, if your agile team is not set up properly, you can expect to face dramatic productivity declines.

If you do not set the scene in advance of establishing new funding models beyond classical business‐case thinking (as already explained in the catalyst section of this book, Chapters 4 and 5), classical return‐on‐investment (ROI) discussion will make agile development speeds much less fertile. Stakeholders on all levels must be educated to let go of some up‐front certainty and agree on investments as an iterative test‐and‐learn approach, in which proof‐of‐concept, prototype, minimum viable product (MVP), and regular iterations are standard.

Agile also requires a far more professional, timely, and customized risk management compared to a waterfall environment. In a waterfall transformation, monthly risk meetings and the typical risk‐impact matrices, combined with a mitigation list and log are typically enough. In agile, the risks need to be addressed much faster—in days or hours—if you do not want their implications to be felt in real‐life production immediately thereafter.

It is critical to ensure that everyone in your program and in your firm is adequately skilled in the language, methods, and implications of agile. This will definitely require sizable investments in building up and freeing resources with sufficient dedication to be staffed on your transformation. Factoring in a potential major disruption in your business‐as‐usual becomes inevitable. This needs to be mitigated early with investments in backfilling of resources. You must build new staffing mechanisms that assign and properly onboard cross‐functional experts to agile sprints. It also needs to ensure continuity from one sprint to the next and from one project to the other for stability and regular velocity. This often also requires inflexible role boundaries to be removed. If you still structure roles into very strict categories, then you will never have an agile team who can problem solve by itself.

To make these siloed agile teams perform, you will need to continuously invest in agile coaches and training, change management, and—assuming a limited agile expertise in your workforce—recruitment of agile specialists on all levels. No matter what you believe today, you will likely end up paying sizable sums for onboarding external agile skills over the course of your transformation. The same is true for new tooling and automated solutions now available—for example, automated build and deployment tools or better work organization software.

All in all, there are fun elements of agile such as constant prioritization of requirements and quick adaptations. These usually get implemented very fast. But there are also hard things like the commitment of teams (no overruling … no pressure!), a more democratic organization (yes, you need to talk to each other), and open communication and transparency (something to learn from). The last one, in particular, will help you avoid the dark side of agile methods, which can encourage errors or weaknesses to be hidden for as long as possible, potentially compromising the entire undertaking. The more difficult aspects of agile are not implemented and this omission occurs with a relaxing of traditional methods of planning and execution. The result is chaos. The more difficult elements of agile often are the corrective elements with respect to planning and progress.

Obviously, as a downside of the discussed flexibility, outcomes are also much less predictable and never reach any long‐term stability, even though you could argue that the predictability of waterfall processes often turns out to be a myth. Even if you see this statement of clear predictability in a presentation, this luring sense of security of outcomes is not necessarily tangible. Predictability is often merely perceived, whereas agile clearly states and communicates that things can change. This is hard to accept in traditional management, in which we need clear goals, a working plan, and people who make other people stick to this plan—but it is not real. In every “waterfall” project, the plan gets adapted once people can no longer avoid it. But then, months later than it was clear to everyone—you plan countermeasures and backtrack on measures, things that could have been done months before. This means higher communication and change management cost to explain and achieve new ways of working at scale.

All this does not even consider one specific reality of many agile transformations: They do not happen in isolation. They involve a wide range of vendors and partners working together in the same team. This will definitely create an agile tower of babel between suppliers, in which substantial investments must be planned to align everyone on the same language and install new agile vendor‐management principles, as classical steering methods will no longer work. You might be chained into fixed‐price or fixed‐outcome contracts, or your partners might not yet be adequately trained in agile delivery models. Working with vendors who are unwilling to or incapable of joining your agile transformation can be a serious risk. You will need to ask for new contracts or even switch your suppliers.

Hybrid Transformation Payday Accelerators

Compared to fully “agile” approaches, “hybrid” transformation would admittedly slow you down, but it gives you some more control than pure agile. It also works at much better speeds than waterfall and includes all the benefits of easier communication and somewhat better ability to plan. This is because when you can provide at least a high‐level roadmap with some lighthouse milestones over a multiyear digital transformation program, you give everyone—not only your teams but also your external stakeholders—a fixture they can relate to in an often seemingly chaotic agile transformation development with many small successes and failures.

Hybrid Transformation Payday Decelerators

Any hybrid approach makes your agile transformation elements ultimately less clean, and thus adds complexity cost in terms of interfaces and so on, which is the number‐one reason for slower speed compared to pure textbook agile transformations. Agile is hard to implement effectively, and often a hybrid approach is more acceptable for managers to try it. And actually, the issues can be overcome. The real hybrid nature of agile is implicit in the process. There is no need for everything to be agile around an agile project. There are proven ways to interconnect an agile method with a traditional waterfall environment, and because agile is flexible, it can quickly adapt to any shortcomings of waterfall projects used to deliver the agile project. It's as simple as shifting the milestone. Unfortunately, hybrid does not mean that you save on any of the decelerators (training, change, and communication cost, just to name a few) explained in the agile and waterfall sections. Quite the opposite, the additional layer of complexity will amplify many of these negative effects and add additional breakwaters at interfaces whenever the two methods are playing together.