More than a year ago, Dave Thomas, one of the original contributor and signator to the Agile Manifesto stirred an hornets nest when he blogged Agile is Dead, Long Live Agility. It created quite a stir in the "Agile Community" (forgive me Dave for using "Agile" as a noun. There is also a talk on youtube Agile is Dead by Pragmatic Dave Thomas in which he has given reasons for his post.
In essence he says that the problem is that the adjective "agile" has been turned into a noun "Agile" by the industry that has sprung around the Agile Manifesto offering panacea for all the ills that plague the IT industry. He and others who support him state that this industry hijacked the word and converted into a money spinning industry that created fear in the hearts of the IT people. It put a fear saying that projects will fail if you do not follow the "Agile Methodology" and did not follow the "Agile Processes".
He bemoans the fact that people are following "Agile Processes" without attempting to understand the "Principles" behind the Agile Manifesto. He bemoans the fact that while the agilemanifesto stressed on the need to be "agile" and "adapative" when developing software, it failed to stress that "processes" followed need to be "agile" and "adaptive" as well.
He states that "No rule is Universal" and that "Every Rule needs a Context". This premise has been ignored by the "Practitioners of Agile" and what they are doing is nothing short of "Cargo Cult".
He says to succeed do the following:
1. Find out where you are
2. Take a small step towards your goal
3. Adjust your understanding based on what you learned
4. Repeat
He appeals the practitioners to show Courage and not fall prey to the fear mongers. The values of agile manifesto are as valid today as they were when published he requests the practitioners to use them to create practices, learn from the practices and keep refining the practices.
He sums up saying "Agile is not what you do", "Agility is how you do it".
Similar thoughts are echoed by another contributor and signator, Andy Hunt in his article An Experiment - The GROWS Method. in the article he In this he suggests the same thing. He says that while "Agile Manifesto" stressed on being Agile and Adaptive with respect to design and development it did not stress being Agile and Adaptive with respect to the process.
He uses the Dreyfus Model of Skill Acquisition to explain why the agile movement failed. The Dreyfus Model proposes that people can be bucketed into the following groups based on their skill level.
1. Novice - Rules-based, just wants to accomplish the immediate goal
2. Advanced Beginner - Needs small, frequent rewards; big picture is confusing
3. Competent - Can develop conceptual models, can troubleshoot
4. Proficient - Driven to seek larger conceptual model, can self-correct
5. Expert - Intuition-based, always seeking better methods
He further states
"Research suggests that most people, at most individual skills, never get beyond the Advanced Beginner level. At the Advanced Beginner stage, you’re comfortable enough to sort of muddle your way through. And for most folks, that’s enough. It kind of looks good on the outside, and you can list it on your resume. But that’s a hollow victory. In terms of software productivity, you might as well be coding in COBOL with a pencil on a yellow legal pad.
But here's the real catch: the kind of self-reflection and self-correction that an agile approach requires is not possible at the lower skill stages. That is an ability you simply do not have access to until you reach the Proficient stage at a skill, which is an advanced stage that the majority of practitioners will not reach.
Showing folks agile practices and asking them to “reflect and adapt as needed” isn't enough. In order to succeed at software development in the 21st century, we need to take a much more directive and pro-active approach."
Given this background it is not surprising that people fell hook, line and sinker for what the "Agile Industry" had to offer. They needed something that they could follow and expect success to follow.
To rectify the situation he suggests the adoption of GROWS method, encapsulated in http://growsmethod.com/. This suggests that changes should be introduced bit by bit. A wholesale change never works. Second people should be given the opportunity to experiment with the change the observe the impact has for them. He cautions what worked for one may not work for the other for various reasons and that should be OK. One thing that needs to be kept in mind is that the experiments should be time-capped so that it is not a long drawn affair yielding no result.
He says it is important not to just know "how to do", but it is important to know why to do, otherwise like Agile the practices will be aped without the underlying rationale being understood which would defeat the purpose of following the practice. For each practice, you also need to understand:
1. Benefits: what is the motivation behind the practice? What will you hope to get out of it, both long term and short term?
2. Where do you get feedback from? With an empirical approach, feedback is everything. Where is the meaningful feedback, and what is just a distracting (or even dangerous) metric?
3. What does it look like in the real world? What are the warning signs if not done correctly? These are the things an experienced practitioner may know, but are hard to come by otherwise.
4. What can you do to improve your skill at this level? How do you get to the next level?
5. At the higher skill levels, how do you then teach this skill to others?
All in all everybody says that Agile has been exploited by the mercenaries who are in to make a profit on every buzzword and that is what has happened with "Agile" and it is time to rethink.
Although it seems and sounds pragmatic, in another decade we may say GROWS has become stunted and we may have Andy standing up and saying that the verb "grows" has been converted into a noun by the "treasure hunters" in the industry.
P.S. Actually GROWS is already trademarked, I do not know by whom. Maybe by Andy himself?
In essence he says that the problem is that the adjective "agile" has been turned into a noun "Agile" by the industry that has sprung around the Agile Manifesto offering panacea for all the ills that plague the IT industry. He and others who support him state that this industry hijacked the word and converted into a money spinning industry that created fear in the hearts of the IT people. It put a fear saying that projects will fail if you do not follow the "Agile Methodology" and did not follow the "Agile Processes".
He bemoans the fact that people are following "Agile Processes" without attempting to understand the "Principles" behind the Agile Manifesto. He bemoans the fact that while the agilemanifesto stressed on the need to be "agile" and "adapative" when developing software, it failed to stress that "processes" followed need to be "agile" and "adaptive" as well.
He states that "No rule is Universal" and that "Every Rule needs a Context". This premise has been ignored by the "Practitioners of Agile" and what they are doing is nothing short of "Cargo Cult".
He says to succeed do the following:
1. Find out where you are
2. Take a small step towards your goal
3. Adjust your understanding based on what you learned
4. Repeat
He appeals the practitioners to show Courage and not fall prey to the fear mongers. The values of agile manifesto are as valid today as they were when published he requests the practitioners to use them to create practices, learn from the practices and keep refining the practices.
He sums up saying "Agile is not what you do", "Agility is how you do it".
Similar thoughts are echoed by another contributor and signator, Andy Hunt in his article An Experiment - The GROWS Method. in the article he In this he suggests the same thing. He says that while "Agile Manifesto" stressed on being Agile and Adaptive with respect to design and development it did not stress being Agile and Adaptive with respect to the process.
He uses the Dreyfus Model of Skill Acquisition to explain why the agile movement failed. The Dreyfus Model proposes that people can be bucketed into the following groups based on their skill level.
1. Novice - Rules-based, just wants to accomplish the immediate goal
2. Advanced Beginner - Needs small, frequent rewards; big picture is confusing
3. Competent - Can develop conceptual models, can troubleshoot
4. Proficient - Driven to seek larger conceptual model, can self-correct
5. Expert - Intuition-based, always seeking better methods
He further states
"Research suggests that most people, at most individual skills, never get beyond the Advanced Beginner level. At the Advanced Beginner stage, you’re comfortable enough to sort of muddle your way through. And for most folks, that’s enough. It kind of looks good on the outside, and you can list it on your resume. But that’s a hollow victory. In terms of software productivity, you might as well be coding in COBOL with a pencil on a yellow legal pad.
But here's the real catch: the kind of self-reflection and self-correction that an agile approach requires is not possible at the lower skill stages. That is an ability you simply do not have access to until you reach the Proficient stage at a skill, which is an advanced stage that the majority of practitioners will not reach.
Showing folks agile practices and asking them to “reflect and adapt as needed” isn't enough. In order to succeed at software development in the 21st century, we need to take a much more directive and pro-active approach."
Given this background it is not surprising that people fell hook, line and sinker for what the "Agile Industry" had to offer. They needed something that they could follow and expect success to follow.
To rectify the situation he suggests the adoption of GROWS method, encapsulated in http://growsmethod.com/. This suggests that changes should be introduced bit by bit. A wholesale change never works. Second people should be given the opportunity to experiment with the change the observe the impact has for them. He cautions what worked for one may not work for the other for various reasons and that should be OK. One thing that needs to be kept in mind is that the experiments should be time-capped so that it is not a long drawn affair yielding no result.
He says it is important not to just know "how to do", but it is important to know why to do, otherwise like Agile the practices will be aped without the underlying rationale being understood which would defeat the purpose of following the practice. For each practice, you also need to understand:
1. Benefits: what is the motivation behind the practice? What will you hope to get out of it, both long term and short term?
2. Where do you get feedback from? With an empirical approach, feedback is everything. Where is the meaningful feedback, and what is just a distracting (or even dangerous) metric?
3. What does it look like in the real world? What are the warning signs if not done correctly? These are the things an experienced practitioner may know, but are hard to come by otherwise.
4. What can you do to improve your skill at this level? How do you get to the next level?
5. At the higher skill levels, how do you then teach this skill to others?
All in all everybody says that Agile has been exploited by the mercenaries who are in to make a profit on every buzzword and that is what has happened with "Agile" and it is time to rethink.
Although it seems and sounds pragmatic, in another decade we may say GROWS has become stunted and we may have Andy standing up and saying that the verb "grows" has been converted into a noun by the "treasure hunters" in the industry.
P.S. Actually GROWS is already trademarked, I do not know by whom. Maybe by Andy himself?
No comments:
Post a Comment