I spend as much of my time reading and investigating the coaching side of my business, as I do in keeping up-to-date with Agile. I also spend a considerable amount of time learning about psychology, anthropologies and general management theory..and all of the above play an integral role in shaping how I chose to interact with teams or individuals I coach.
Smell: how to get boys on board and explain key concepts to them..I often find trying to explain collective ownership, courage, respect and communication can get a few funny looks from the fellas – I can tell they think I’m a hippy!
So how do I convince folks Agile is not simply a love-in but a dyed-in-the-wool way of working better? I use an analogy of an airforce mission..this exercise takes a short time and has a good impact on how team members work with each other:)
Airforce missions are typically small units of highly trained individuals who all do what they can to ensure success
The team are fighter pilots…pilots deal with life and death..our teams typically deal in software (not always..that is for a later post) Read More
I’m here again, coaching – and trying my best to ensure I meet my commitment of making the transition ‘fun’. I got to thinking about some of my fellow coaches and Agilist’s and the use of games-like events and realised that often the efforts in setting up and playing such games doesn’t result in any kind of value for the business. (XP Game excluded of course- this is an essential for delivery teams)
Games are fun and may provide some feeling of Agility however I’m coming to the realisation that my preferred way to coach is by example in a delivery type situation. I find (as do my clients) excessive games puerile and usually have identified more valuable work I could be doing for my clients where I can make some actual difference to their business vision.
In the past I’ve coached under the guise of Delivery Manager to Lead BA and found that setting examples, doing the job and growing the folks around you is more effective and cost efficient than having a coach sit around, giving advice, sometimes being ignored and in general not really contributing to the production of working software. Perhaps this is because clients often don’t know how to leverage coaching skills and experience, not setting the role or expectations properly within the organisation we are trying to coach?
Also standalone Agile coaching often detracts from delivery – we forget that coaching is not an end unto itself, indeed most clients these days simply want to ‘be Agile’ without fully understanding why, or indeed what it means in terms of commitment to change.
In the future I’m sticking with a real job title and getting rid of ‘Agile Coach’ which has become synonymous with ‘Cheerleader/trainer’ – Pigs Unite!