Hybrid Agile Manifesto And Spider-Man

Paul Dandurand

What does Spider-Man have to do with agile projects? You may have landed here out of curiosity. Keep reading and you’ll find out.

In this article, I’ll talk about the problems with the Agile Manifesto, agile principles, and how smart agile and focused waterfall go hand-in-hand as a hybrid approach for the purpose of improving end results. As a precursor, see my previous post on waterfall with agile.

I’ll share with you my concerns about the agile culture and why a better approach would be to foster diversity with a hybrid model.

In an article for another PMI conference paper called Blending agile and waterfall, Alex Rodov and Jordi Teixidó wrote, “…we tend to compare agile projects to bad waterfall approaches and continue with this misconception.”

Alex and Jordi hit it on the head, which leads me to the Agile Manifesto and what it has fostered.

The problem with the Agile Manifesto

The Agile Manifesto has been around for 18 years. If you haven’t seen it, check it out. It’s really short and simple as listed here:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

The manifesto’s authors state that they value what’s on the left more than what’s on the right.

But here are two questions:

  1. Why does the left side of the statement need to be more valuable than the right?
  2. Why can’t they be equally valuable without one taking away from the other?

To Alex’s and Jordi’s point, I believe the Agile Manifesto was written with a counter-punch to badly managed waterfall projects. Likewise, there are also a ton of badly managed agile projects, as noted by Gloria J. Miller in her article, Agile problems, challenges, and failures.

Let’s look at the manifesto’s first statement: “Individuals and interactions over processes and tools.” It’s like saying improving a car’s interactive mechanics is better than ensuring that we have a great set of directions to get to the lake before sunset. We need both.

I can go down the list saying why it’s absurd to think that working on one will diminish the value of the other. But I’m guessing the reason for their value statement was that many businesses were ignoring important things like individuals and interactions, working software, collaboration, and responding to change. A manifesto like this might have the purpose to bump people into saying, “Hey, look over here!” However, the way it’s written has caused many to downplay the value of the items on the right of each statement.

There’s one item in the 12 Principles page that points out the real difference between agile and traditional waterfall approaches. This is the focus on continuous product deployment in small chunks rather than the Big Bang approach seen in waterfall-only projects.

(What about Spider-Man? Coming up soon…)

The one unique value of agile is…

Everything in the Agile Manifesto and Principles page, with the exception of one unique difference, should all be done on agile and non-agile waterfall projects.

I believe the true unique value of agile is the ability to deliver the product in small chunks frequently over time.

To do this, you need to be flexible with change for two reasons: One is to deliver in small bites when the future requirements are not really fully fleshed out. The second is that making ongoing deployments to the customer will stir up new ideas and identify design issues much earlier with the help of customer feedback. Therefore, being flexible while always delivering is really cool and not traditionally on the menu of waterfall projects.

Spider-Man with agile and process

Ok, let’s talk about Spider-Man. The reason I bring him up, other than for a catchy title and image, is to use his approach as an example of mixing agile with process. You may hear agile purists say processes get in the way. As a note, the Agile Manifesto line #1 downplays “processes,” but the 12-principles page mentions “agile processes” a couple of times. Hmm…

To give credit to their principles page, implementing agile does indeed include a number of processes, such as the steps on organizing and running scrum meetings, and the discipline of time-boxing work into sprints followed by reviews and feedback processes.

Although there are many forums and articles about the real physics of swinging through Manhattan, my focus is that agility and processes go hand-in-hand (or skyscraper-to-skyscraper), and one doesn’t need to take value away from the other.

Whether you are Spider-Man or a product manager of the next killer digital game, you can easily mix agile with process for driving even better project end results.

In my last blog, I wrote about why most agile projects are really agile with waterfall. If you have read it, recall that projects that have beginnings require solid planning and known processes, with sequential action steps mostly depending on their previous step. Once in a while, Spider-Man may go swinging for fun, but that’s really not a project since there’s no end game (and I suspect the webbing material is super expensive). Most of the time, he plans out his path to get to the other side of the town in time to save, say, a dangling bus about to fall off a bridge. With the except of certain moments of pure instinctive reaction while fighting the water monster, many of his flights are hybrid agile/waterfall processes with a set of best-practice steps, along with the agility to manage unknown structures when swinging along the way.

A hybrid agile/waterfall manifesto?

It’s not fair to criticize something without offering an improvement. I’m going to take my shot at defining a short manifesto for the new age of hybrid agile with waterfall. The following is just an idea, and I would love your feedback. Think of using this mix during a single project:

  • Waterfall for known dependent steps with agile for unknowns and iterations
  • Plan with repeatable best practices while responding to change with agility
  • Frequent ongoing delivery of product or project solutions
  • Everyone engaged to share, solve, and innovate continuously – and customers, sponsors, stakeholders are also part of “everyone”
  • People, processes, and tools working together form a winning recipe

Diversity and inclusiveness rather than exclusiveness make our projects stronger. People with different approaches and experience, whether agile-focused or waterfall-focused, are all needed to bring unique views.

Look for agile waterfall hybrid tools

A word about tools: The problem with most project management tools today is that they are really made for waterfall projects, such as Microsoft Project; or for agile sprints, such as Atlassian Jira. What you end up with is part of the team using one tool and the other part using a different tool. Although this might work, you do miss out on complete oversight and transparency across the full project.

Look for a tool that provides the ability to utilize sequential process-driven steps that can be repeated from project templates, or what we call “recipes,” and also provides a board feature that is good for your agile sprints. They are hard to find, but I’ll give you an example of our own Pie hybrid project tool with the following video.

Watch how Waterfall and Agile can work together as a Hybrid within the same project:

Think of hybrid agile/waterfall as the diversity that mixes the best from all of us. As for process – well, they can all be processes if they contain a set of actions to achieve desired results. Finally, bake in repeatability and we can reuse recipes for scalability.

This article originally appeared on the Pie blog and is republished by permission.

Do you want to learn how your organization can benefit from SAP’s Experience Management Solutions? Then join our webinar series to find out more on this topic!


Paul Dandurand

About Paul Dandurand

Paul Dandurand is the founder and CEO of PieMatrix, a visual project management application company. Paul has a background in starting and growing companies. Prior to PieMatrix, he was co-founder of FocusFrame, where he wore multiple hats, including those of co-president and director. He helped position FocusFrame as the market leader with process methodology differentiation. FocusFrame was sold to Hexaware in 2006. Previously, he was a management consulting manager at Ernst & Young (now Capgemini) in San Francisco and Siebel Systems in Amsterdam. Paul enjoys photography, skiing, and watching independent films. He earned a B.A. degree in Economics from the University of California at Berkeley.