Leading Agile Transformation: watch out for Avery!
Life is Simple and this is a big problem.
I learned about Christopher Avery’s responsibility process during a training inside our company. So simple and easy to figure out! Sometimes I wonder why can’t I figure out simple and obvious things and make myself a whole lot of money.
While working with several teams as an Agile coach, I noticed this is both an individual but also collective (team) process. It applies to teams trying to be more agile and become self organized.
It all starts with these mad coaches explaining the Agile principles: always try to choose the people, working software, customer collaboration and ability to change from your daily equation.
Then we, mad coaches, talk about these techniques or processes or events that can make their lives easier – promises of disciple and simplicity- of course they won’t make your life easier, they will show you all your mistakes, failures weaknesses and then THEY WILL DEMAND YOU TO CHANGE!
And so misery starts among teams – discipline that looks like anarchy and a complex simplicity. We are asking you to be basic. We are asking you to focus on your technical skills… what a mess!!
Here comes Avery – Teams start denying:
– We don’t need this – we were working fine
– This will never work for us because WE ARE DIFFERENT
– As if that would ever work in such a complex product
– Our culture… it will never work because of cultural issues
– We have different teams in different sites, and with different languages! (although English is our company official language)
– That won’t do because we don’t need more meetings and feature lists
– Oh no! Our organization is way too big to do such simple things… that is too basic for us we need more meetings and lists and … oh look we need this charts and reports! No way I’ll sleep in peace without my 1 zillion metrics no one uses.
– … bla bla bla … that will never work because I have a dog and he likes donuts.
After long hours trying to explain the advantages of being simple, doing simple, keeping it simple and convinced them at least to try some events and their first baby-step, we get in Blaming phase :
1st stage: Blaming the existence of Agile
– We couldn’t deliver this because we now have to do this daily meetings that costs us time (yeah right! 15 minutes costs you a lot.. you take more time to park your car)
– We will never deliver anything in this “sprint”… it’s not enough time for us to deliver anything… we need more time! (yeah! And doughnuts too)
– We can’t and we don’t know how to estimate this. (this = their own work)
– I can’t work in this mess… I’m not used to having tasks in whiteboards.. It was much better when we used that tool to insert features and that one to show features, the other to approve them, and that one to send the feature to analysis…..
– We can’t do analysis and testing, we are developers. (I can’t swim, I’m not a fish)
– This won’t do with teams in different sites.
2nd stage: Blaming the Absence of Agile
– We cannot start working before PO has all Release User Stories in Product backlog
– The PBacklog is not estimated, we can’t work. (you know YOU have to estimate it right?)
– We won’t work nor try anything until our brains are fully satisfied with Agile and XP trainings.
– No one can talk to us or ask us anything during Sprint. (not even doughnuts)
– This will never work because our Managers don’t like Agile and they don’t give us the biggest office, raises, top-of-class laptops, SPA full access card…
– Agile says <something they interpret their way> … – and we don’t do it this way.
– We can’t work with teams in different sites.
– Our PO is not a real customer.
Seriously? Come on… we work for a company, we have a business to run… we are changing… That scares a lot of people. Maybe, just maybe we could try giving something back first. Try to make things better, deliver something and on time and then, just then, explain how a SPA full access card could improve our mood and results
After blaming, comes Justifying:
– We tried but the estimates were not accurate because we forgot to add something
– We lost half a day in a training
– We are not self-organized we are still learning, learning takes time
– This product has lots of dependencies…(which hasn’t)
– Teams are so faraway and so focused on their problems we couldn’t talk
All true, as all phases before were. It all depends on your perspective and were you wan’t to be and go.
Shame comes next:
– we should have done better
– this time is our fault
– we should have done estimations more accurate
(I don’t have much more examples because it is hard to find teams (already!) in this phase- although I must say I believe some of them jump this stage and some others directly to responsibility)
After Shame we have Obligation:
– We must do this feature even if it does not fit our sprint. We must it is very important. (it is indeed, but I bet they will fail it anyway)
– We must not request help from others, we should do everything.
– (that is also what my dog says about my doughnuts.. and I wish he asked me for help once in a while)
Finally… the winner is: RESPONSIBILITY!
Bring on our self-organized teams. We are one. We are THE one. Even if we have to work with wood-sticks rather than state-of-the-art PCs …
– Yes we can.
– Yes we will try it
– Yes we will deal with it and try to bridge our teams
– We can help you with that, together it will become a better product.
– Of course we can, we all work for the same purpose.
– Let us discuss this together
– No wait, don’t call.. let us go over there and talk face to face. Oh! The colleague is in other site, ok let’s use videoconferencing then. we don’t fear that our souls are captured by video streaming.
– What you are saying makes as much sense as what I am saying, how do you thing we could deal with it together?
– Obviously that we love and need our Scrum Master. (This was the joke)
– You need to provide us the priorities else we will be working on something that is not valuable for us all.
I don’t need to give more examples do I? Of course not, after all… It is common sense!