Monday, 21 November 2011
There is a lot more to agile than a bunch of practices that people claim they have been doing for eternity and someone has just put a name to. There is a lot more to agile than doing a Scrum course over a week and getting a certificate. There is a lot more to agile than reading a few blogs, buying a bunch of books and going to a conference.
I don't believe in big A agile. There is no one methodology for software construction. There is no one method for anything in life. There are however a whole lot of practices that when used in combination with others and in the presence of a certain level of awareness of the required patterns and undesired anti-patterns, you can run a successful agile project that results in emergent quality and software that business wants.
The one thing that I am seeing over and over recently is people coming to me and saying that they are doing agile but it isn't working. They have people on the team who have done agile before. They have people on the team who are trained Scrum Masters. They have people on the team who have bought in and want to do agile. All of these good things and yet, they are failing.
I freely use the word failing without it feeling like that is a bad thing. It isn't. Failing is a way of learning and people who can step back and say that they tried something and it didn't work, are the kind of people who learn and improve.
To actually achieve a cohesive agile environment and a team that can find their peak and attain that, you need the glue that is an agile coach or iteration manager. Some people call it the scrum master but that term is so easily obtained these days that I do not think it holds much credibility.
No matter what you call that glue, they are the person who keeps the the team moving and finds the sweet spot that is the practices and level of rigour that will work for that team in the specific environment they are in.
The famous cry of "I've been doing agile forever and they just gave it a name" is so so wrong.
You can not just grab a bunch of practices and call that agile. The famous cry of "I've been doing agile forever and they just gave it a name" is so so wrong. Agile is not just a bunch of practices and terms and things to do. It is the whole process of constant reassessment, learning, rigour, retrospective analysis and self-organisation. It is something that you must experience and learn before you try it yourself and then help others.
I always refer back to the method that surgeons use to train other surgeons to do an operation.
The method is that you "see one, do one, teach one".
Participate in an agile team as a team member. Seniority does not matter. You can be an expert at anything or nothing and that doesn't change the fact that you take part in the team and learn how practices work together and how to see patterns and anti-patterns that let you choose what shapes the team.
This time, you organise the agile team and help propel it. Remove blockers; Suggest practices and tools for the context and team; Measure the quantifiable parts and communicate them; and be the glue. This can be done with the support and supervision of a person who knows how to teach or coach. They can back you up.
Be the teacher and coach others to be members of an agile team. Let them learn about their environment and adapt to a changing environment. Your job is to enable and act as lubricant for others who are learning.
If you understand that this is the process that must happen before people are fully enabled to work in an agile way then you will understand why teams without this but with the best intentions still fail.
It also explains why having an agile expert on the team can be a peaceful process that makes the whole thing feel easy. When they leave, it sometimes feels a little unstable. They shouldn't hold all the information back or be in control. A coach should enable you and let you find your way, with a safety net.
I had a project manager say to me recently "Damana, the reason why what you do looks easy, is because it is". I smiled kindly and sadly watched him eat his words later when he took over and ran the project on to rocks.
The reason an agile coach makes it look easy is because they saw one and then did one and taught one, several times.