Is Agile New? Agile Manifesto allocated – out of the Agile Scrum Handbook

By July 13, 2018

[vc_row][vc_column][vc_column_text]Agile is usually advertised as the new thing. The use of the term Agile to refer to Adaptive lifecycles is certainly new, but what about the lifecycle itself?

I don’t know about you, but I have a hard time imagining a long history of human beings with many projects and programs that have been done without any form of adaptive lifecycles. Can you think of an example?

I can give you one. Think of a very popular initiative (project or program) in the old days: going to war. Can you manage a war with a Predictive approach? They plan and design everything in the beginning? Certainly not. You may have a high-level plan that is more like a strategy than a plan, and manage the war one battle (i.e. iteration) at a time (or a few in parallel), and based on the outcome of each battle, adapt for the rest of the initiative.

Not a pleasant example, but a clear one that shows Adaptive lifecycles can’t be new.

So, what is it that is new?

In a certain time, the so-called scientific management approach and Taylorism became the norm, so much so that every other approach was perceived inferior and even wrong. Taylorism was entirely and strongly based on Predictive systems; therefore, Predictive systems dominated the whole world, so to speak.

Then we reached the time that more and more IT development projects were initiated, and Predictive lifecycles were not really the best way to manage those projects. People tried to tolerate it, while the pressure was increasing, until demonstrations and eventually revolution happened! Like any other revolution, it devours its children, but that’s a topic for another time.

The Agile Manifesto

Some people started using Adaptive systems for IT development and gradually structured them into repeatable management processes. A group of these pioneers got together in 2001 to make it official by giving it a name and creating a Agile manifesto.

Let’s start with the name. As legend has it, the two final options were Agile and Adaptive. Unfortunately, their decision was Agile. Adaptive would be much better because it describes the nature of the approach and prevents many misunderstandings.

So, the Agile Manifesto, which is available in the highly advanced and modern website at AgileManifesto.org, is this:

Kent Beck

Mike Beedle

Arie van Bennekum

Alistair Cockburn

Ward Cunningham

Martin Fowler

James Grenning

Jim Highsmith

Andrew Hunt

Ron Jeffries

Jon Kern

Brian Marick

Robert C. Martin

Steve Mellor

Ken Schwaber

Jeff Sutherland

Dave Thomas

Unfortunately, this Agile manifesto itself has never been subject to adaptation during its life.

A usually overlooked part of the Agile manifesto is the last sentence. I’d like to invite you to read the Agile manifesto again with the last sentence in mind.

So, let’s review these four statements.

Value 1: Individuals and interactions over processes and tools

Overlooking the importance of individuals and interactions is a very fast way to fail. After all, it’s the people who do the project. Some managers think they can overcome problems in this area by using a more sophisticated “system”, but that rarely, if ever, works.

Many of us have been disappointed by the naive optimism that implementing a sophisticated tool will solve problems caused by overlooking human aspects, or even methods, for that matter. Still, managers spend huge sums of money implementing and maintaining tools, hoping for them to do magic. The fact is that tools can only facilitate a system; they don’t replace the need for a system. On the upside, these tools are sophisticated pieces of software that need years of development and maintenance and create many projects and jobs, which make it possible for us to invest in thinking about better ways to do IT development projects!

The part about processes in this statement is a little tricky. It’s actually about a certain type of process, not processes in general. It’s about processes that are designed to replace the need for human interactions and complexities. I personally know managers who believe that if they have a better process, they

won’t have to hire highly expert professionals. In the meantime, one great aspect about Agile systems is that they have ALL embedded human aspects in their processes, instead of just bolting them in or even just talking about the importance of human aspects, which is, unfortunately, the case with established project management systems.

So, in summary, processes that try to ignore or replace human aspects are bad, and processes that address those aspects and make them part of the system are good.

Value 2: Working software over comprehensive documentation

In contrast to the previous statement, which is correct for all types of projects, this one is specific to Adaptive systems. It refers to the fact that, instead of using upfront documentation to predict what needs to happen in a project, we just go on, create pieces of working software (increments), and use them to adapt.

Value 3: Customer collaboration over contract negotiation

Any project would be more successful with higher levels of customer collaboration. In Adaptive systems, it’s more than important; it’s necessary. The customer has to collaborate with you all the time when you’re constantly specifying new requirements and asking them to check the increments and give you feedback. If they don’t do it, you won’t be able to adapt.

And contract negotiation is something we all love 😉 An ideal Agile project with a time and material contract and a customer that doesn’t think suppliers are criminals doesn’t need much contract negotiation. The two parties work together towards creating a valuable product. However, the ideal is just the ideal, and customers are still looking for fixed-scope, fixed-price contracts, which have a fundamental contradiction with Adaptive methods, which is a source of never-ending contract negotiations similar to those in Predictive projects.

Value 4: Responding to change over following a plan

This statement, similar to the second statement, is specific to Adaptive systems. Instead of having a Predictive, upfront plan that can show us the way, we are dependent on adaptation. The latter is usually referred to as “change” in Agile, probably because it makes customers happy to know they are free to change everything, but in fact, it’s not a change unless it doesn’t match the initial baselined plan, which we don’t have in Adaptive systems. Technically, what we have is a continuous stream of new ideas. However, let’s keep calling them changes, just for the sake of all customers out there.

Want to know more, get the Agile Scrum Handbook or read more in one of the other Agile Scrum Hanbook blogs.