With all the recent talk about the Decline and Fall of Agile, I've seen a number of comments about how we should focus on the Values and Principles of the Agile Manifesto and not on the practices of any one approach. I agree with this to a point. Once a team has matured within a particular process then absolutely they can really begin to tailor it to suit their local circumstances using the Values and Principles as their guide.
However, a team needs to learn to walk before it can run, and the Japanese martial arts learning concept of Shu Ha Ri is an excellent model to use in this case.
In the first stage, Shu, a team is given fundamental practices that they watch and perform. Everyone performs these practices in the same way, regardless of their own personal traits.
When the team reaches the Ha stage, they have integrated the practices into their own way of thinking and are good enough at them to begin to expand beyond simply mimicking what their master (or coach) has shown them. The literal translation of Ha is "to break free" or "to frustrate", a dual meaning that explains very well what happens at this stage. The team is learning how to tailor the initial practices to their own environment and personalities, and the coach does indeed have some frustration with respect to the team departing from using the practices as taught.
The final stage, Ri, is when the team has fully integrated not only the "what" of the practices, but the "why". The translation of Ri is "to break free", which reflects how the team no longer needs the coach to guide them with respect to the practices. The team has improved to the point that they know what works for them and what doesn't, and can work within themselves to self-improve.
Going back to the Agile Manifesto for a moment, you can equate the Shu Ha Ri model to integrating Practices, Principles, and the Values. The problem is, the Manifesto only speaks to the latter two, with no mention at all of practices. So, how can a team reach the Ri stage with an Agile process without having a Shu stage to start?
Well, there have been a number of discussions recently about the use of XP practices with Scrum. In a software development context, Scrum avoids prescribing any technical practices, preferring instead to let the team self-organize to complete their work. This lack of guidance contributes to both Scrum's higher adoption rate, and to the challenges encoutered by teams using Scrum that continued to use their existing practices that had led them to seek out a better development process in the first place!
So, teams are using Test-Driven Development. They Refactor their code, and this is something that Ken Schwaber has recognized is required. They're using Continuous Integration. Pair Programming is being used, or some other form of near real-time code oversight.
In short, teams are realizing that the Practices do indeed matter. Without them, a team will improve somewhat, but it will likely be a case of We Suck Less.
To be able to achieve all of the potential improvement, a team needs to take the Practices and do them by the book until they are good enough to decide whether they work for that team. At that point, and only at that point will a team be capable of making the decision to drop or modify Practices.
Shu = Learn the Practices as is until you're good at them.
Ra = Ask "why" about the Practices, and experiment with changes.
Ri = Forget the damned Practices and just build some software!
The last point is only partially tongue in cheek - when a team reaches that stage, they are able to use the Values from the Manifesto to frame what they do on a daily basis. They know what works for them to enable the sustained delivery of high quality software and what doesn't. Furthermore, they know how to (and do) seek continuous improvement.
A team cannot reach this last stage without starting at the first - the Practices matter.
However, a team needs to learn to walk before it can run, and the Japanese martial arts learning concept of Shu Ha Ri is an excellent model to use in this case.
In the first stage, Shu, a team is given fundamental practices that they watch and perform. Everyone performs these practices in the same way, regardless of their own personal traits.
When the team reaches the Ha stage, they have integrated the practices into their own way of thinking and are good enough at them to begin to expand beyond simply mimicking what their master (or coach) has shown them. The literal translation of Ha is "to break free" or "to frustrate", a dual meaning that explains very well what happens at this stage. The team is learning how to tailor the initial practices to their own environment and personalities, and the coach does indeed have some frustration with respect to the team departing from using the practices as taught.
The final stage, Ri, is when the team has fully integrated not only the "what" of the practices, but the "why". The translation of Ri is "to break free", which reflects how the team no longer needs the coach to guide them with respect to the practices. The team has improved to the point that they know what works for them and what doesn't, and can work within themselves to self-improve.
Going back to the Agile Manifesto for a moment, you can equate the Shu Ha Ri model to integrating Practices, Principles, and the Values. The problem is, the Manifesto only speaks to the latter two, with no mention at all of practices. So, how can a team reach the Ri stage with an Agile process without having a Shu stage to start?
Well, there have been a number of discussions recently about the use of XP practices with Scrum. In a software development context, Scrum avoids prescribing any technical practices, preferring instead to let the team self-organize to complete their work. This lack of guidance contributes to both Scrum's higher adoption rate, and to the challenges encoutered by teams using Scrum that continued to use their existing practices that had led them to seek out a better development process in the first place!
So, teams are using Test-Driven Development. They Refactor their code, and this is something that Ken Schwaber has recognized is required. They're using Continuous Integration. Pair Programming is being used, or some other form of near real-time code oversight.
In short, teams are realizing that the Practices do indeed matter. Without them, a team will improve somewhat, but it will likely be a case of We Suck Less.
To be able to achieve all of the potential improvement, a team needs to take the Practices and do them by the book until they are good enough to decide whether they work for that team. At that point, and only at that point will a team be capable of making the decision to drop or modify Practices.
Shu = Learn the Practices as is until you're good at them.
Ra = Ask "why" about the Practices, and experiment with changes.
Ri = Forget the damned Practices and just build some software!
The last point is only partially tongue in cheek - when a team reaches that stage, they are able to use the Values from the Manifesto to frame what they do on a daily basis. They know what works for them to enable the sustained delivery of high quality software and what doesn't. Furthermore, they know how to (and do) seek continuous improvement.
A team cannot reach this last stage without starting at the first - the Practices matter.
Comments
It is so often the case that when approaches in any discipline/industry become formalised in 'methodologies' that we can loose the purpose and value of the practises/techniques that were behind the approach in the first place.
In the 'Agile' world of development much of the recent debate has been to this end; We can get lost in debating the relative merits (and descriptions) of methodologies rather than ensuring that the development disciplines and practises that are valuable to our business (or our client) aswell as valuable to our technical teams.
To this end I have found books like Peter Schuh's an insightful approach to focus on the agile practises an processes in isolation of specific methodologies and provide direction on how development teams could introduce them and incrementally adopt and implement 'Agile' without worrying what to call it.