I’ve done a few agile introductions in my time, in fact I’ve started to feel I could almost write a book entitled “agile by numbers”. So yesterday when this question appeared on some LinkedIn group I thought I’d give it a quick go:
“I am working with an organization which wants to explore agile adoption. What are the some of the best ways for start the process. Is it to start with agile training and then help set up with an agile agile coach to take it forward ? Or first do an assessment to understand why they want to adopt agile and than suggest the best approach : if it’s scrum, Kanban or XP.”
My answer went something like this:
First, don’t get distracted by researchershing options, don’t worry about Scrum v. Kanban v. XP v. What-Ever. Just get on and do it. (Of course I should have plugged my own book and said “Do Xanpan!”)
- Find someone you can trust who knows about this stuff (perhaps I should have said someone like me!)
- Get them to give an 1 or 2 hour (max) talk to interest people
- Ask the team leads if they would like to volunteer their team or upcoming work, then talk to the people who would be involved, choose/make a small self contained team (i.e. coders, testers, product person) (Note: if you only have one team then you can skip steps 2 and 3 because you are doing to work with this team.)
- When you have found your guinea pigs give them a day or two of rehearsal (i.e. a training session where they get to practice what they do)
- Start doing weekly iterations immediately: no waiting for “the right time”, start while things are fresh
- Arrange for the person who gives the training session to come back each week, then throttle back to less often when the time is right
- Engage a technical coach/trainer and after several iterations run some technical training (TDD or BDD, take your pick). Have this person come back for some one-on-one coaching (i.e. pair programming), allow one day per coder plus time with testers if you have them
- See what happens, review, keep going, expand
I did notice that a few of the other replies recommended teams start with coaching rather than training. I’ve done it that way, in fact thats how all the early teams did it. I’ll also say that in my experience – and yes, I’m biased, I sell training – giving people some training up front works best. Perhaps thats because the way I do training is to give people a chance to experience working in an Agile setting in the classroom, so perhaps what I’m saying is: all training is not equal.
This little recipe takes you so far. I’ve stopped with the technical stuff. The process side will get you so far but if you don’t do the technical stuff – lots of automated testing! – then you will only go so far.
The other thing I haven’t said here at all is: this recipe is only for the supply side, once the supply side starts to shape up the focus needs to shift to the demand side, those people you call Product Owner, Business Analyst, Product Manager or something like that. Thats where it gets difficult, not because these people are themselves more difficult but because you are now wrestling with the wider organization and changing a bigger mindset.
Another problem that sets in here is that companies can loose the will to change. I’ve worked with a few companies who apply this prescription but they get so much improvement the immediate pain goes away and they loose the motivation to change further.
This prescription can very quickly makes things get better. But if you want the full benefit you need to keep taking the technical medicine and supplement it with demand side medicine too. Those changes take longer to make a improvement, they are a slow burn.
| Reference: | Agile adoption by numbers – and some problems from our JCG partner Allan Kelly at the Agile, Lean, Patterns blog. |
