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.

Alex Rodov and Jordi Teixidó wrote an article for another PMI conference paper called Blending agile and waterfall. They 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 authors state 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 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 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 may 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.

Both sides of each statement is equally valuable.

There’s one item in their 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 their 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.

In order to do this, you have to be flexible with change for two reasons. One is to deliver in small bites when the future requirements are not really fully flushed out. The second is ongoing deployments to the customer/client is going to 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 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 their 12-principles page mentions “agile processes” a couple 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.

The video below is curtesy of gfycat and as shown on the Polygon site, which has detailed approaches on how a gamer can use their controls on the PS4 Spider Man game to strategically swing through the city. For example, how to swing with more velocity, when to let go of your web, how to launch and traverse, etc.

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 post I spoke about why most all agile projects are really agile with waterfall. If you have read it, recall projects that have beginnings require solid planning 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 a dangling bus about to fall off the bridge. With the except of certain moments of pure instinct 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 fare 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 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 together form a winning recipe

Diversity and inclusive rather than exclusive makes 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 made 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 make 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 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.

Thanks for reading. Please send your thoughts.

Paul

Written by Paul Dandurand, PieMatrix Founder