Oh The Humanity....

The Agile manifesto is a very simple statement, and a small one at that. In many ways, it is almost haiku-like in its simplicity and  profound insights. The interpretation of this manifesto has led to people learning to make software in more efficient ways, and to saturate the entire industry with a new way of thinking. But for a long while now, I have been a little bothered that each of these ways of doing software (Kanban, Scrum, Lean) and the people coaching/guiding others tend to stray from the original manifesto – to the detriment of the teams they are trying to help. I wondered how this was possible, and recently I think I see a pattern emerging. But the big take away from me is that in order for a coach to be effective, one must focus and study the manifesto and it’s principles to help teams “uncover better ways of developing software by doing and helping others do it”

I may have touched upon some of this in an earlier posting, but for me the manifesto itself focuses on people and software. It is intended for people who make software, so this makes a lot of sense. But each of us as a human develops “blinders” that are reinforced with our specialization in our life. The joke about the engineers in a car clearly shows how people in the same field can see and diagnose a problem! So given the audience and the intent of the manifesto, and the interpretation from that audience, I believe we have developed some blinders to the manifesto as a whole – and it may be leading to the coaching changes that I see on the field.

Many coaches focus on the process they are preaching in order to generate results. In America, this is not uncommon. It is like a child making sugar cookies – no matter what the dough started like, or the process it went through – the cookies will look like the cookie cutters you use on the finished dough. Many coaches take their version of Agile to organizations and unleash the dough making process and cookie cutter approach with little attention to what you are starting out within the organization. In some cases, this may be the best approach to allow people to think differently. But in some cases, it simply can lead to more pain and a resentment of all agile processes. The people I regularly see using this approach ride into town with a wagon full of tools to help implement their brand. They have a set of cookie cutters with them when they start! And they usually lean heavily on the tools to “drive” expected agile behavior. You need a great backlog? ”Why tool XYZ will force the organization to structure the backlog perfectly! You need burndown charts and status reports? Why Module QXP will work with the XYZ core product to give you all the metrics you need. And it will support automated build and drive automated testing! It will MAKE you Agile and automate ALL the THINGS! Once we are done, with this tool you will be the most agile organization ever!!” It’s comically like the Dr. Seuss story, with the star bellied snitches. This is so common, sometimes when you see a client with a tool trying to make sense of what went wrong it makes you think – how did they let it get to this point.

Because there is only one small problem with this. And it can be found on the very first line of the manifesto… If you only read it…

I have no issue with any tool, like I have no issue with most professions (except politicians, of course). But I am aware that each of these will come with built in blinders that will affect how they see things and interpret information. Tools will take you down some pre-defined paths because of how they are structured, certain things will become more difficult, and others too easy. If you as a coach don’t know what is critical for the individual client, you will fall into the trap of the tool’s built in blinders. Likewise, if you are not aware of the organizational or even individual blinders of the people you are wanting to work with, you will not see the best potential for helping out. Either way, as a COACH it is contingent on your skillset to overcome and help the teams or organizations you are working with to the best of your abilities. Because as a coach, you simply have to be aware of the blinders that are there.

Coaching is a challenging task, because you have to help others see where improvement is necessary and put plans in place to trigger that change. In includes a lot of pain and a lot of challenges. A toolset can be extremely helpful to achieve the overall goal, but a blind approach or an approach that does not take analysis into account can simply be too painful to have any success. An approach that is too soft may yield initial results, but will not change organizations or teams for any long term gains. A coach has to take all these factors into account, as well as being as aware of their own blinders as possible. One piece of advice I give to team members I help is that they should try as best as possible to NOT become so specialized they lose their skill to their toolset. I think that as a human being (an Individual) you need to develop a skill and be able to perform it with separate kinds of tools. This helps you grow as an individual, and adds value to your team. As a coach, I find this to be essential, especially in the Agile space. But it is too easy for all of us as IT professionals to rely so heavily on our tools that we inadvertently corner ourselves into obsolescence.