Which Agile Method? Some Considerations
Hi,
We are not here to do agile, we are here to deliver technology solutions to help our businesses realise opportunities, strengthen weaknesses and fend off threats.
We use agile tools to achieve this.
If you and your team are unable to deliver, then it doesn’t matter how good your "agile" capability is, you’re failing to meet your primary objective.
A few years ago, I was working on a project with a number of issues and lots of noise and luckily for me, Ken Schwaber was working with us at Conchango at the time. When I talked to him about some of these project issues he gave me some priceless advice...
“...just get the software out of the door!”
This is the essential part... if you keep delivering stuff, you’re helping the business and adding value. Too many so called “agile” developers focus on how “well” agile is being done rather than how much value is being created for the business.
Recently, our programme adopted Kanban for a period of time to solve a particular phase of the project and it was deemed extremely successful, now we have reverted back to Scrum for a different phase.
A critical blog that helped the entire team understand the logic and goals behind Kanban.
http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf
If you are considering using Kanban, you should definitely read the above article first. It's a great piece of work to describe the differences and relationship between the methodogies.
The following diagram created by Henrik Kniberg shows methodologies along a range that includes the number of their artifacts and their relative position with regard to adaptive and prescriptive approaches.
So how do you decide which method to use?
It's all about discipline and trust!
Software development is a complex, non-predictive process, and just because you might adopt an adaptive or non-prescriptive methodology, it doesn't mean you reject all the other activities and artifacts! It means you pick and choose the ones your team thinks it needs in order to produce the software.
So, implicitly, the adoption of adaptive methods means that you trust your team to make those decisions, that you trust your team to be disciplined in approach, and that you trust the teams to take responsibility for their actions.
I would suggest that anyone attempting to adopt agile methods consider this very carefully. Is the team adopting the methodology proficient? Are they responsible individuals, are they disciplined in their work? If not, don't do it.
There are too many teams out there seeing agile methods as a way to cut corners... there's no shortcut. If you have fewer artifacts within the methodology, then you have to think more for yourself, you have to be more disciplined in your individual activity, you have to communicate better than you ever have before.
Personally, I would never adopt Scrum without XP development practices.
The question comes down to "how good are your people?" Where agile techniques have been successful, teams have shown value to the business in creating better software quicker through removing "prescriptive" activities and increasing their own discipline and responsibilities.
Software development is a complex process, and removing the prescriptive activities does not lead to immediate success. These prescriptive activities need to be replaced by strong development practices (XP).
Are your teams using strong development practices?
Are they all working to a clear definition of done?
Are they disciplined in approach?
Do they coach and mentor each other so the team and product is always improving?
If the answer is no, you are increasing the risk to your business.
Do not adopt increasingly adaptive methods without considering these points.
Oh... and Good luck!
We are not here to do agile, we are here to deliver technology solutions to help our businesses realise opportunities, strengthen weaknesses and fend off threats.
We use agile tools to achieve this.
If you and your team are unable to deliver, then it doesn’t matter how good your "agile" capability is, you’re failing to meet your primary objective.
A few years ago, I was working on a project with a number of issues and lots of noise and luckily for me, Ken Schwaber was working with us at Conchango at the time. When I talked to him about some of these project issues he gave me some priceless advice...
“...just get the software out of the door!”
This is the essential part... if you keep delivering stuff, you’re helping the business and adding value. Too many so called “agile” developers focus on how “well” agile is being done rather than how much value is being created for the business.
Recently, our programme adopted Kanban for a period of time to solve a particular phase of the project and it was deemed extremely successful, now we have reverted back to Scrum for a different phase.
A critical blog that helped the entire team understand the logic and goals behind Kanban.
http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf
If you are considering using Kanban, you should definitely read the above article first. It's a great piece of work to describe the differences and relationship between the methodogies.
The following diagram created by Henrik Kniberg shows methodologies along a range that includes the number of their artifacts and their relative position with regard to adaptive and prescriptive approaches.
So how do you decide which method to use?It's all about discipline and trust!
Software development is a complex, non-predictive process, and just because you might adopt an adaptive or non-prescriptive methodology, it doesn't mean you reject all the other activities and artifacts! It means you pick and choose the ones your team thinks it needs in order to produce the software.
So, implicitly, the adoption of adaptive methods means that you trust your team to make those decisions, that you trust your team to be disciplined in approach, and that you trust the teams to take responsibility for their actions.
I would suggest that anyone attempting to adopt agile methods consider this very carefully. Is the team adopting the methodology proficient? Are they responsible individuals, are they disciplined in their work? If not, don't do it.
There are too many teams out there seeing agile methods as a way to cut corners... there's no shortcut. If you have fewer artifacts within the methodology, then you have to think more for yourself, you have to be more disciplined in your individual activity, you have to communicate better than you ever have before.
Personally, I would never adopt Scrum without XP development practices.
The question comes down to "how good are your people?" Where agile techniques have been successful, teams have shown value to the business in creating better software quicker through removing "prescriptive" activities and increasing their own discipline and responsibilities.
Software development is a complex process, and removing the prescriptive activities does not lead to immediate success. These prescriptive activities need to be replaced by strong development practices (XP).
Are your teams using strong development practices?
Are they all working to a clear definition of done?
Are they disciplined in approach?
Do they coach and mentor each other so the team and product is always improving?
If the answer is no, you are increasing the risk to your business.
Do not adopt increasingly adaptive methods without considering these points.
Oh... and Good luck!
Comments