[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.
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:
Arie van Bennekum
|Robert C. Martin
Â© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.
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.
Nader K. Rad
Project Management Author, Speaker, and Adviser
Relavant links Scrum Framework
- 9789401802796 – hardcopy
- 9789401802789 – eBook
- Author: Nader K.Rad & Frank Turley