risk_bwsb_bwnews_bwbbw_bwmsn_bwmo_bwlbj_bwinvestors_bwHRV_bwDN_bwb2c_bwentreprenuer_bw   

W: Waterfall vs Agile/Sprints/Scrum – Pivoting to the future of Agile-Teamwork

W:  Waterfall vs Agile/Sprints/Scrum – Pivoting to the future of Agile-Teamwork

“The future is already here, it’s just not evenly distributed” (William Gibson).  The future of agile-teamwork is already here it’s just not evenly distributed – many leaders, teams and organizations are still stuck in waterfall-teamwork.  “Waterfall” vs “Agile” contrasts two fundamentally different modes of teamwork.  The problem is that we have to unzip our mindset from the waterfall schooling we have had.

The future of “Agile” teamwork is already here, perhaps best embodied in the field of “Agile Software Development”, which is already huge.  This was born out of a 2001 meeting of software gurus resulting in the 4 core values of the Agile Manifesto:

We have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

We follow these principles:
Our highest priority is to satisfy the customer  through early and continuous delivery  of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.  The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity–the art of maximizing the amount of work not done–is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

“Waterfall” is the colloquial name for the old approach to the teamwork of software development on the right-hand-side of each of these core-value statements above.

Jeff Sutherland was there at that meeting and in his book, “Scrum:  The Art of Getting Twice as Much Done in Half the Time”, he further explains “Waterfall”:

I first created Scrum, with Ken Schwaber, twenty years ago, as a faster, more reliable, more effective way to create software in the tech industry. Up to that point—and even as late as 2005—most software development projects were created using the “Waterfall” method, where a project was completed in distinct stages and moved step by step toward ultimate release to consumers or software users. The process was slow, unpredictable, and often never resulted in a product that people wanted or would pay to buy. Delays of months or even years were endemic to the process. The early step-by-step plans, laid out in comforting detail in Gantt charts, reassured management that we were in control of the development process—but almost without fail, we would fall quickly behind schedule and disastrously over budget.

Scrum is at the heart of “agile” and Jeff Sutherland goes on to say:

To overcome those faults, in 1993 I invented a new way of doing things: Scrum. It is a radical change from the prescriptive, top-down project management methodologies of the past. Scrum, instead, is akin to evolutionary, adaptive, and self-correcting systems. Since its inception, the Scrum framework has become the way the tech industry creates new software and products. But while Scrum has become famously successful in managing software and hardware projects in Silicon Valley, it remains relatively unknown in general business practice.

In an increasingly VUCA world, waterfall software development doesn’t work!  Nor do waterfall business practices!  We too must move from waterfall mindsets to agile mindsets.  Here’s my summary for some of the major contrasts between Waterfall and Agile mindsets:

Waterfall vs AgileAgile mindsets are set free by a willingness to get comfortable being uncomfortable, with the discomfort of being wrong, of failure and of not-knowing.   As a result, it becomes an increasingly high velocity process of learning by doing, Most crucially, it’s highly iterative with daily scrum meetings (for the team to take stock and adjust every day) and short sprint-cycles (often only 1 or 2 or 4 or 6 weeks) at the end of which the team demo’s real product to real people for real feedback.

Waterfall mindsets are held hostage by a need for knowing and control, for the comfort of failure avoidance.  But it’s an exercise in futility, laced with fiction (we make up a critical path based upon assumptions that are un-knowable and un-controllable) and fallacy (we project rates of progress that we think we can achieve before we have done anything).  Most crucially, we create an industrial strength project plan and Gantt Chart perhaps out over a 24 month timeframe, which is front-end loaded with paperwork, paperwork and more paperwork!

One of my favorite and most illuminating contrasts between Waterfall and Agile is that between the “task is fixed, time is variable” mindset of Waterfall and “time is fixed, task is variable” mindset of Agile.  I was once running an enterprise scale software company and we had just lost a strategic bid because the customer told us that our graphic-user-interface (GUI) was perceived as out-of-date.   We were in trouble because I had just acquired the company into my division and this was a major setback.  I got my team in a room and said, “You have 3 days to be back in this room telling us where you think you can be 3 weeks from now with a new demo GUI.  In 3 weeks you will be back in this room showing us the demo and telling us where you can think you can be in 3 months with the real thing”.  I told them where the hurdles were (time is fixed) but not how high to jump (task is variable), which they self-determined.  3 months later they wowed us with the new GUI they had released and we were back in business.  Imagine what answers I would probably have got if I had said, “We need a wow new GUI, how long will that take?”  I didn’t know it at the time but I had intuitively used an agile mindset not a waterfall mindset.

In his book, “Scrum:  The Art of Getting Twice as Much Done in Half the Time”, Jeff Sutherland puts the contrast this way:

Traditionally, management wants two things on any project: control and predictability. This leads to vast numbers of documents and graphs and charts.  Months of effort go into planning every detail, so there will be no mistakes, no cost overruns, and things will be delivered on schedule. The problem is that the rosy scenario never actually unfolds. All that effort poured into planning, trying to restrict change, trying to know the unknowable is wasted. Every project involves discovery of problems and bursts of inspiration. Trying to restrict a human endeavor of any scope to color-coded charts and graphs is foolish and doomed to failure. It’s not how people work, and it’s not how projects progress. It’s not how ideas reach fruition or how great things are made. Instead, it leads to frustrated people not getting what they want. Projects are delayed, come in over budget, and, in too many cases, end in abject failure. This is especially true for teams involved in the creative work of crafting something new. Most of the time, management won’t learn of the glide path toward failure until millions of dollars and thousands of hours have been invested for naught.

“Sound familiar?  By contrast, Jeff Sutherland goes on to explain Scrum, which is at the heart of Agile:

Scrum embraces uncertainty and creativity”. It places a structure around the learning process, enabling teams to assess both what they’ve created and, just as important, how they created it. The Scrum framework harnesses how teams actually work and gives them the tools to self-organize and rapidly improve both speed and quality of work.  At its root, Scrum is based on a simple idea: whenever you start a project, why not regularly check in, see if what you’re doing is heading in the right direction, and if it’s actually what people want? And question whether there are any ways to improve how you’re doing what you’re doing, any ways of doing it better and faster, and what might be keeping you from doing that.  Companies that still cling to tried-but-not-true ideas of command and control and that attempt to impose rigid predictability are simply doomed to fail if their competitors use Scrum. The difference is too great.

Take two head to head competitors, in any field of business.  One takes a waterfall approach to strategy and execution and the other takes an agile approach to strategy and execution.  Which one will you bet on will come out ahead?  I would bet on the agile one for sure.  Even Marshmallows reveal the secrets of agile teamwork vs waterfall teamwork!  Read more:  Marshmallows Reveal Secrets of Agile Teamwork vs Waterfall Teamwork

The problem is that we still encounter the waterfall-thinking way too much in business.  Here are some examples:

  • Waterfall Strategic Planning (vs Agile Strategy Process) – a 3 year, 5 year or 10 year strategic plan?  Really?
  • Waterfall Budgeting (vs Agile Budgeting) – an annual Fiscal Year budget, tracking year-to-date this Fiscal Year vs year-to-date last Fiscal Year?  Really?
  • Waterfall Goal-Setting (vs Agile Goal-Setting) – an annual goal-setting cascade and annual appraisal?  Really?
  • And More:
    • Waterfall Innovation (vs Agile Innovation)
    • Waterfall Product Strategy/Management/Development (vs Agile Product Strategy)
    • Waterfall Change Management (vs Agile Change Management)
    • Waterfall Leadership (vs Agile Leadership)
    • Waterfall Meetings (vs Agile Meetings) Agile Meetings … are at the heart of your Enterprise Agility!
    • Waterfall Thinking (vs Agile Thinking)
    • And so on …

In an increasingly VUCA world, waterfall anything doesn’t work!  We help teams understand the mindsets, thinking and leadership of agile everything, to develop an enterprise agility advantage.

Read more at my blog:  Is Agile Just Another Management Fad?

More and more leaders are realizing that waterfall-teamwork doesn’t work in an increasingly VUCA world and are transitioning to the flow of agile-teamwork. Here are a two:

  • Alan Mulally: the recently retired ex CEO of Ford, who turned the company around when it was in worse shape than General Motors & Chrysler (both of whom took the government bailout and went bankrupt) – as part of his “Working-Together” approach ( “Working-Together” Meets Agility) he immediately instigated a weekly BPR (Business Plan Review) meeting of his global team, every Thursday morning. Agile 3 - resizedA little while later he realized that weekly wasn’t frequently enough and he moved to a daily SAR (Special Attention Review) meeting of as much of his global team he could muster within a reasonable time-zone. Prior to Ford, he had used exactly the same approach in turning around the commercial airplane division of Boeing post 9/11, which was on its knees.   As reported in the book, “American Icon – Alan Mulally and the Fight to save Ford Motor Company” (Bryce Hoffman, 2012), weekly and daily meetings were the central algorithm of his whole turnaround approach. Agile Meetings … are at the heart of your Enterprise Agility!  He created the real-time communication, coordination and collaboration to win, moving from waterfall-teamwork to agile-teamwork.
  • General Stanley McChrystal: appointed commander of special-forces in the early 2000s war against AQI (Al-Qaeda in Iraq) which we were losing, he realized that our world-class maneuver-warfare machine was losing to an enemy that had moved on to a new paradigm, of network warfare. To win, we would have to beat the enemy at their own game of network warfare. But that required a shift of information-sharing paradigm from the need-to-know secrecy of maneuver warfare to everybody-knows-everything-all-the-time for network warfare. He instigated a Daily O&I (Operations & Intelligence) Meeting, initially in his command center and then increasingly technology enabled for a wider and wider network of operatives and intelligence parties to wire into, from Washington DC to the field. In his book, “Team of Teams: New Rules of Engagement for a Complex World” (General Stanley McChrystal) he tells the story of how the meeting grew to more than 7000 people participating on a daily basis. It was the central cog in the wheel, tipping the balance to winning the warAgile Meetings … are at the heart of your Enterprise Agility!  It created the real-time communication, coordination and collaboration to win, moving from waterfall-teamwork to agile-teamwork.

Alan Mulally and General Stanley McChrystal understood the central role of meetings for the real-time communication, coordination and collaboration as an agile-team. An essential flow of conversation to be:

  • Anticipating Change
  • Generating Confidence
  • Initiating Action
  • Liberating Thinking
  • Evaluating Results

If you want to win, that is what is required. Agile-meetings are at the heart of your enterprise-agility to move from waterfall-teamwork to agile-teamwork, whether you are in war-fighting business or the automotive business. So much so, we call it “The C2C of AGILE Teamwork (from Conversation-Flow 2 Cash-Flow)”

Read more about “Waterfall” vs Agile:

About Mike Richardson

Agility-Facilitator/Mentor/Coach; Agility-Author/Speaker; Agility-Board-Member/Chairman. All-round Agility Activist in everything I do, every day, everywhere, in every way. Provocative, Profound, Practical. At Eye-Level. With Love/Hate!

Leave a Reply

Your email address will not be published. Required fields are marked *

*