Does Agile Manifesto Need Changes? The 10 Years Experience!
by
·
Join the DZone community and get the full member experience.
Join For FreeI delivered a presentation on the above topic earlier this year at an Agile Conference in NCR, India.
I have summed up my thoughts below.
On a cold winter morning of 13 Feb 2001, at a ski resort in Utah, the Agile Manifesto was born.
The newborn had 17 fathers (ahem ahem), all stalwarts of the software industry, trying to be Agile in their own way, ahead of their times.
Though some leading software practitioners were following some form of Agile (without calling it that), the real precipitation of thoughts happened in February 2001.
And thus emerged the Agile methodology of software development as we have come to know it.
In 2011, while the whole Agile community was united in celebration of 10 years of Agile, there were a lot of Agile practitioners who felt the need for a change – maybe a change from Agile to another methodology (like Agile was to Waterfall), or changes in the basic foundation of Agile (the Agile Manifesto and its 12 core principles).
This whole dissonance stemmed from not achieving the kind of success we had hoped for.
Their concerns did resonate with me but when I dug a little deeper, I realised that difference between our results and expectations arose from the way Agile was implemented, the way it was morphed into something else, a commonly known phenomena as “Agile-but”. (You might have hears people saying, “we do Agile but….instead of X we do Y”).
It is completely okay to let Agile fit your organisation as it is not a set of commandments one ought to follow. But there is a “spirit” that is embodied in the Manifesto and the principles which should never be compromised.
I agree that it is really tough to explain that spirit in words but you would get a sense of it once you start “living” Agile, not just following it, or doing it, or practicing it.
(God! I am sounding like Yoda instructing Luke Skywalker: “You must feel the Force around you. Here, between you, me, the tree, the rock… everywhere!”)
While I was preparing for this presentation, I came across a wonderful tongue-in-cheek take on Agile
We have heard about new ways of developing software bypaying consultants and reading Gartner reports. Through
this we have been told to value:
Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those
individuals (we prefer the term ‘resources’) interact
Working software over comprehensive documentation
as long as that software is comprehensively documented
Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control
Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely
That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.
The above conveys my sentiments on the current state of “Agile” well.
And let me not stop there.
I have come across enough real-life examples to illustrate this.
These examples are from companies / projects based on Agile methodology.
I have mentioned them under the statement that they seem to violate
Individuals And Interactions Over Processes And Tools
1. “This part was not implemented because it was not written in the user story. So what if it was discussed.”
2. “Please create a ticket/story for whatever you want to be done”
3. QA/Tester: “Wait. Don’t fix the issue now. Let me first create a ticket on it”
Working Software Over Comprehensive Documentation
1. “We are Agile. We don’t document”
2. “User stories need to include even the last bit of detail”
3. After a sequence of changes over time with a functionality, “Make sure you reflect the changes in the stories”
Customer Collaboration Over Contract Negotiation
1. “Lets write detailed user stories about the features that would go into the project so that the customer/developer is bound by them”…(later)…“Hey, that was not in the scope”
Responding To Change Over Following A Plan
1. “We are Agile. We don’t plan”…(LOL)
2. “We never discussed this feature”
3. “I don’t care if your system crashed, I want this functionality delivered by weekend”
I would like to share a quote that, I believe, truly represents that spirit of being Agile
Float like a butterfly,
sting like a bee
- Boxing legend Muhammad Ali.
Wrapping this up, saying that Agile needs change when we were not able to implement it properly is akin to saying that one has wrong feet when he is wearing shoes wrongly.
I have summed up my thoughts below.
On a cold winter morning of 13 Feb 2001, at a ski resort in Utah, the Agile Manifesto was born.
The newborn had 17 fathers (ahem ahem), all stalwarts of the software industry, trying to be Agile in their own way, ahead of their times.
Though some leading software practitioners were following some form of Agile (without calling it that), the real precipitation of thoughts happened in February 2001.
And thus emerged the Agile methodology of software development as we have come to know it.
In 2011, while the whole Agile community was united in celebration of 10 years of Agile, there were a lot of Agile practitioners who felt the need for a change – maybe a change from Agile to another methodology (like Agile was to Waterfall), or changes in the basic foundation of Agile (the Agile Manifesto and its 12 core principles).
This whole dissonance stemmed from not achieving the kind of success we had hoped for.
Their concerns did resonate with me but when I dug a little deeper, I realised that difference between our results and expectations arose from the way Agile was implemented, the way it was morphed into something else, a commonly known phenomena as “Agile-but”. (You might have hears people saying, “we do Agile but….instead of X we do Y”).
It is completely okay to let Agile fit your organisation as it is not a set of commandments one ought to follow. But there is a “spirit” that is embodied in the Manifesto and the principles which should never be compromised.
I agree that it is really tough to explain that spirit in words but you would get a sense of it once you start “living” Agile, not just following it, or doing it, or practicing it.
(God! I am sounding like Yoda instructing Luke Skywalker: “You must feel the Force around you. Here, between you, me, the tree, the rock… everywhere!”)
While I was preparing for this presentation, I came across a wonderful tongue-in-cheek take on Agile
We have heard about new ways of developing software bypaying consultants and reading Gartner reports. Through
this we have been told to value:
Individuals and interactions over processes and tools
and we have mandatory processes and tools to control how those
individuals (we prefer the term ‘resources’) interact
Working software over comprehensive documentation
as long as that software is comprehensively documented
Customer collaboration over contract negotiation
within the boundaries of strict contracts, of course, and subject to rigorous change control
Responding to change over following a plan
provided a detailed plan is in place to respond to the change, and it is followed precisely
That is, while the items on the left sound nice
in theory, we’re an enterprise company, and there’s
no way we’re letting go of the items on the right.
The above conveys my sentiments on the current state of “Agile” well.
And let me not stop there.
I have come across enough real-life examples to illustrate this.
These examples are from companies / projects based on Agile methodology.
I have mentioned them under the statement that they seem to violate
Individuals And Interactions Over Processes And Tools
1. “This part was not implemented because it was not written in the user story. So what if it was discussed.”
2. “Please create a ticket/story for whatever you want to be done”
3. QA/Tester: “Wait. Don’t fix the issue now. Let me first create a ticket on it”
Working Software Over Comprehensive Documentation
1. “We are Agile. We don’t document”
2. “User stories need to include even the last bit of detail”
3. After a sequence of changes over time with a functionality, “Make sure you reflect the changes in the stories”
Customer Collaboration Over Contract Negotiation
1. “Lets write detailed user stories about the features that would go into the project so that the customer/developer is bound by them”…(later)…“Hey, that was not in the scope”
Responding To Change Over Following A Plan
1. “We are Agile. We don’t plan”…(LOL)
2. “We never discussed this feature”
3. “I don’t care if your system crashed, I want this functionality delivered by weekend”
I would like to share a quote that, I believe, truly represents that spirit of being Agile
Float like a butterfly,
sting like a bee
- Boxing legend Muhammad Ali.
Wrapping this up, saying that Agile needs change when we were not able to implement it properly is akin to saying that one has wrong feet when he is wearing shoes wrongly.
agile
Opinions expressed by DZone contributors are their own.
Comments