I am Guilty of Agile Training
I am Guilty of Agile Training
There's a right and a wrong way to train somebody. But just because a training style is different, does not necessarily make it wrong. Take a look.
Join the DZone community and get the full member experience.Join For Free
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
Over Christmas I was thinking, reflecting, drinking…
Once upon a time I was asked by a manager to teach his team Agile so the team could become Agile. It went downhill from there.
I turned up at the client's offices to find a room of about 10 people. The manager wasn’t there – shame, he should be in the room to have the conversations with the team. In fact, half the developers were missing. This company didn’t allow contractors to attend training sessions.
For Agile introduction courses I always try and have a whole team, complete with decision makers, in the room. If you are addressing a specialist topic (say user stories or Cucumber) then its OK to have only the people the topic effects in the room. But if I am talking about teams and processes, I want everyone there!
We did a round of introductions and I learned that the manager, and other managers from the company, had been on a Scrum Master course and instructed the team to be Agile. Actually, the company had decided to be Agile and sent all the managers on Scrum Master courses.
So the omens were bad and then one of the developers said something to the effect of:
“I don’t think Agile can help us. We have lots of work to do, we don’t have enough time, we are already struggling, there is masses of technical debt, and we can’t cut quality any further. We need more time to do our work, not less.”
What scum am I? I pretend to be all nice but underneath I allow myself to be used as a tool to inflict Agile pain on others. No wonder devs hate Agile.
My name is Allan and I provide Agile training and consulting services.
I am guilty of training teams in how to do Agile software development.
I am guilty of offering advice to individuals and teams in a directive format.
I have been employed by managers who want to make their teams Agile against the will of the team members.
I have absented myself from teams for weeks, even months, and failed to provide deep day-in-day-out coaching.
In my defense, I plead mitigating circumstances.
One size does not fit all. The Agile Industrial Complex* has come up with one approach (training, certification and enforcement) and the Agile Hippies another (no-pressure, non-directive, content free, coaching).
I don’t fit into either group. Doing things differently can be lonely. Still, I’ve had my successes.
I happen to believe that training team members in “Agile” can be effective. I believe training can help by:
- Providing time for individuals to learn
- Sharing the wisdom of one with others
- Providing the opportunity for teams to learn together and create a shared understanding
- Providing rehearsal space for teams to practice what the are doing, or hope to do
- Providing a starting-point – a kick-off or a Kaikaku event – for a reset or change
Yes, when I deliver training I’m teaching people to do something, but that is the least important thing. When I stand up at the start of a training session I image myself as a market stall holder. On my market stall are a set of tools and techniques which those in the room might like to buy: stand-up meetings, planning meeting, stories, velocity, and so on. My job is to both explain these tools and inspire my audience to try. I have a few hours to do that.
As much as I hate to say it, part of my job at this point is sales. I have to sell Agile. In part I do that by painting a picture of how great the world might be with Agile. I like to think I also give the audience some tools for moving towards that world.
At the end of the time individuals get to decide which, if any, of the tools I’ve set out they want to use. Sometimes these are individual decisions, and sometimes individuals may not pick up any tools for months or years.
On other occasions – when I have time – I let the audience decide what they want to do. Mentally I see myself handing the floor over to the audience to decide what they want to do. In reality this is a team based exercise where the teams decide which tools they want to adopt.
If a team wants to say “No, thank you,” then so be it.
In my experience teams adopting Agile benefit greatly from having ongoing advice on how they are working. Managers benefit from understanding the team, understanding how their own role changes, and understanding how the organization needs to change over time.
Plus, you cannot cram everything a team needs to know into a few hours training and it would be wrong to do so. You don’t want to overload people at the start. There are many things that are better talked about when people have had some experience.
Actually, I tend to believe that there are some parts of Agile which people can only learn first hand. They are almost incomprehensible or unbelievable until one has experience. That is one of the reasons I think managers have trouble gasping Agile in full: they are too far removed from the work to experience it first hand.
You see, I believe everyone engages in their own sense making, everyone learns to make sense and meaning in the world themselves. In so much as I have a named educational style it is constructivist. But my philosophy isn’t completely joined up and has some holes; I’m still learning myself.
When I do training I want to give people experiences help them learn. And that continues into the work place after the training.
So I also offer coaching, consulting, advice, call it what you will.
But I don’t like being with the team too much. I prefer to drop in. I believe that people and teams need space to create their own understanding. If I was there they wouldn’t get that space, they wouldn’t have those experiences, and possibly they wouldn’t take responsibility for their own changes.
One of my fears about having a “Scrum Master” type figure attached to a team is that that person becomes the embodiment of the change. Do people really take responsibility and ownership if there is someone else there to do it?
I prefer to drop in occasionally. Talk to individuals and teams about how things are going. Talk about their experiences. Further their sense making process. Do some additional exercises if it helps. Run a retrospective.
And then I disappear. Leave things with them. Let them own it.
Whether technical skills are concerned – principally TDD – it is a little different. Because that is a skill that needs to be learned by practice. I don’t tend to do that so I usually involve one of my associates and they are sometimes embedded with a team for a longer period.
Similarly, I do sometimes become embedded in an organization. I can be there for several days, a week, or for many weeks on end. That usually occurs when the organization is larger, or when the problems are bigger. Even then I want to leave as much control with the teams as I can.
On the one hand I’m a very bad person: I accept unwilling participants on my training courses and then don’t provide the day-to-day coaching that many advocate.
On the other hand: what I do works, I’ve seen it work. Sometimes one can benefit from being challenged, sometimes one needs to open one's mind to new ideas.
If I’m guilty of anything, I’m guilty of having a recipe which works differently.
And that team I spoke of to start with?
One day, two some people did not return: that was a win. They had worked out that it was not for them and they had taken control. That to me is a success.
Most people did return and at the end, the one who had told me Agile could do nothing for them saw that Agile offered hope. That hope was principally an approach to quality which was diametrically opposite to what he initially thought it was going to be and was probably, although I can’t be sure, the opposite of what his manager thought Agile meant.
It is entirely possible that had his manager been in the room to hear my quality message I’d have been thrown out there and then. And it's just possible I might have given him food for thought.
But I will never know. I never heard from them again. Which was a shame, I’d love to know how the story ended. But that is something else: I don’t want to force anyone to work with me, I don’t lock people in. That causes me commercial headaches and sometimes I see people who stop taking the medicine before they are fully recovered, but that's what happens when you allow people to exercise free will.
*Tongue in cheek, before you flame me, I’ve exaggerated and pandered to stereotypes to effect and humour.
Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.
Published at DZone with permission of Allan Kelly , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.