"Grow Your Own"

Over the course of my career I have worked at several organisations and have always tried to improve the internal processes using agile techniques and principles. Despite being a valued employee (I hope) at each of the companies I have worked at, the amount of success I achieved in agile adoption always reached some internal limits. It was only when I joined emergn that I was able to rationalise this.

It is inevitable that as an employee of a company you will have something to do as part of your day job. This will always be your primary concern and there will inevitably be certain processes you must follow in order to perform your function. Changing this process from the inside will usually involve challenging the process (rocking the boat) using rational arguments and demonstrable alternatives. This is certainly achievable, but does take rather a long time to introduce even simple improvements. Organistations, particularly large organisations are not content with local optimisation and nearly always want to ensure that any benefits from a single improvement become the standard for the organisation as a whole. This usually means that the number of interested parties is artificially (and politically) quite significant and therefore the amount of resistance to change is high.

As an external coach the mandate is entirely different.

First and foremost, your primary function is to instigate change.

This will mean the amount of resistance is significantly less.

Secondly, you will not be tied to existing processes.

This means you can implement changes and improvements much faster.

Thirdly, as an outsider you are automatically assumed to be an expert.

This will mean that you will not need to engage in the same level of rational argument or discussion as an internal employee.

Lastly, as an outsider you bring some diversity and objectivity to the environment.

You will not be unconciously constrained by any existing processes or internal preconceptions about the art of the possible.

As an external coach now, I am actually extremely surprised with just how much compromise I had been willing to unconciously accept as an employee. Every small improvement I would have liked to make became a battle and unfortunately I lost many of these battles not through a lack of rational argument but through a lack of energy or time to continue to fight. When push came to shove I had to get on with my day job and ensure I lived to fight another day. Reflecting now, I'm not surprised that the more successful some of the improvements were the bigger the political entourage became and the more difficult it became to make the next improvement. Battles had to be chosen carefully not necessarily for the potential benefit but often based on the people who had expressed an interest.

I'm aware (and quite proud) of the changes I've made in each of the organisations that I've worked at but am left reflecting whether the effort was worth it. I think the barriers to continual improvement are probably a major factor when I decided whether I wished to remain at a given company and I can now see that effecting change from the inside is simply not effective. It will take at least twice as long to be at most half as effective as an external coach.

          

http://anarchycreek.com/2009/05/26/how-tdd-and-pairing-increase-production/

          

http://www.markhneedham.com/blog/2009/05/26/pair-programming-refactoring/

I would concur that refactoring is much more effective while pairing and it is often while refactoring that patterns emerge which makes up for the lack of upfront design, so having more than one brain looking for patterns will ultimately lead to better code...

          

Of course, when pair programming is done well, with a group of experienced developers the benefits are enormous, and if you're wondering what pair programming really means, then the following article from Rod Hilton sums it up extremely well...

http://www.nomachetejuggling.com/2009/02/21/i-love-pair-programming/

This not only provides an insight into the life of someone doing pair programming, but also hints to the true benefits of pair programming, which is always a tough sell...