Coach: “I order you to keep your Standups to 15 Minutes.”
Team: “What we object to is that you automatically treat us as inferior”
Coach: “Well I am your Coach”
Team: “Order eh ‘Coach’, who do you think you are, we didn’t vote for you”
Coach: “You don’t vote for Coaches, I am Scrum Certified and blessed by leadership, signifying that I Dave am ordained to direct your Agile behaviours”
Team: “Supreme Agile coaching powers derive from a deep and wide exposure to successful Agile projects, not some farcical accreditation”
Coach: “be quiet”
Team: “If we went round saying we were coaches because we had done a three day course, they would put us away!”
Coach: “I order you to be quiet!!!”
Inspired by Monty Python and the Holy Grail.
I was recently told by a customer that they had banned the internal Agile Coaching staff from their floor, and had engaged an external to help mature the practices. This person has long been a strong advocate of Agile. Ironically, the internal coaches had lost their agility…
It’s not really that difficult to understand how this can happen. In many cases Agile is driven by the need to drive small ‘a’ agility across the organisation. Leadership is looking for a transformational change. Agile becomes the ‘new salvation’. Coaches are charged by leadership to lead the change with the enormous challenge of driving what is a significant change management exercise. They are often made to feel blessed.
If you combine that mandate (often resulting in a messianic complex) with green coaches or coaches with a very narrow experience set, who pile in with a particular flavour of Agile dogma “don’t worry, we are here to sort you out” you end up with at best, poor effectiveness, at worst open rebellion.
Alternate problems can arise if you live in a well established (entrenched) coaching community , the problems can derive from long term group think. “We do Agile better than anybody else, so we have nothing to learn”. All teams need to regularly disrupt themselves if they are to be resilient and relevant ongoing. This is particularly true of Agile coaching teams, who, if you think about it, should be continuously challenging their own dogma more effectively than anyone in the rest of the business.
If you are in a coaching community and you are struggling to get teams to do what you want them to, it might be them, but there is also a very good chance it’s you.
I’ve never come across a team, in any line of business, that cannot get value from the Agile way of working applied to some aspect of their business.
So here’s where I start with new business teams looking to adopt Agile practices:
– Here is Agile.
– Here are the fundamental tenants of Agile (see indictors for effective Agile listed in this article https://www.shibusa.com.au/thats-not-agile/ ).
– It can help solve these sorts of problems.
– What sort of problems do you have?
– Do you want to try applying some of these practices to
There is no pre-conceived notion of specifically how I will apply the practices. I listen, and then I design the application of the practices to suit. And then I collaborate with the team, adjusting the practices as we go until we are ALL happy. All whilst working to carefully preserve the intent of the practices.
Agile in software engineering is a little different, at the end of the day software applications of Agile are about elimination of waste, better product and ultimately more predictability. But that doesn’t mean that you can’t adjust the initial application of the practices to be relevant to the teams current context and maturity.
The first rule coaching self assessment needs to be that if you are a couple of iterations in: something important got better, everyone can see its better, and as a result everyone wants to continue the journey to make more things better.
And it really doesn’t matter if the standups took 26 minutes, and some folk sat down ….
And if you can’t tick the improvement box pretty quickly, expect to be rightfully kicked out, if not today……