Why Agile is Leadership & Waterfall is Management

larry apke, agile doctor, agile, waterfall

As an agile coach who has had the wonderful opportunity to work with many diverse companies in many different fields, I can attest that one of the benefits of having a coach is having a wealth of experiences from which to draw upon and over time we are able to notice patterns even among disparate companies. Some are rather obvious, like the inability for organizations to understand the difference between project and product management or that agile is an organizational change, not just an IT change.

Nevertheless, there are some patterns which are sometimes less obvious (or at least I have been more oblivious to) or that seem to take longer to identify.

Recently I had an, “Aha!” moment when looking back on my prior experience which has led me to coin a brand new axiom – agile is about leadership, waterfall is about management.

Like all things obvious after the fact, when this finally dawned on me I felt silly that I had not noticed the distinction before – duh, of course you say! However, the distinction is subtle so, in my defense, please don’t judge me too harshly.

The realization has been fermenting for some time, but it struck home recently when I was discussing issues around organizations transitioning from waterfall to agile with a colleague of mine. The trend I was referring to was the fact that nearly every agile transformation that he and I have worked have been initiatives from the project management office.

While a transition from the PMO can be successful, the very fact that the PMO is more about management (in most organizations), that even having the word “management” right there in the middle presents organizations with inherent challenges. The PMO is about top down, command and control. Should a scrum team actually have self organization, usually in spite of the top down PMO, and find something that works well for their team, the PMO usually pounces on this innovation, desperately solidifying it as a “best practice” for every team in their command.

I remember one innovative coach who used trophies to recognize agile excellence for their team. It was appropriate to that team and worked well for that team. This is an excellent example of leadership (and a self-organizing team). Unfortunately management happened to attend one of these trophy presentation ceremonies.

What was management’s response? “Wow this is great! Let’s buy a bunch of trophies and make every single team do this going forward!”

Unfortunately, this type of top down management is what PMOs are used to and comfortable with. This is one example of why PMO-led agile transformations are so challenged. The urge to manage (waterfall is about management), as opposed to allowing teams to self-manage (agile is about leadership), is in the DNA of most PMOs (and most organizations).

This mentality is easy to find. All you need to do is to gauge the amount of fear in the organization. The more fear, the less leadership. Is CYA the order of the day? Don’t expect your agile transformation to go smoothly, but CYA is the hallmark of management.

Avoidance of failure is not the same thing as success. Avoidance of failure and the concomitant avoidance of blame is the realm of management. Pursuit of excellence and success is the realm of leaders. Is your agile transformation not going well or you are not receiving the benefits you expected?

Stop trying to manage and lead. Stop using managers and start using leaders. Move the transformation from management silo into the realm of organizational leadership. Perhaps you should appoint a Chief Agile Officer.

Remember at all times – agile is about leadership, waterfall is about management.

Larry Apke

One Reply to “Why Agile is Leadership & Waterfall is Management”

  1. I’ve previously written about the difference between scrum and kanban (and the “tweener” called scrumban). I’d offer a different contrast: scrum is management, whereas scrumban or kanban are leadership.

    Why? Too often, scrum degrades to a project management exercise of projecting exactly how many tasks/hours are required to deliver specific functionality, burning team focus and time on prediction rather than burning them on progress towards a vision.

    I wrote about scrumban on my blog.

Leave a Reply to John Peltier Cancel reply