Poor Man’s Agile Adoption: How low can you go?

A picture of a man opening his wallet and only a fly is in there, clearly showing that he's a candidate to learn more about a poor man's agile adoption strategies

Times are lean and if you're going to do Agile adoption right on a budget, you need to get a good mental model of how it's all going to work

Somebody asked me last week about a strategy for Agile adoption at their small IT shop. I thrashed around with some ideas and finally spit-balled a number.

“That’s too high,” he said.

So I asked him how much he had (which I probably should have done at first) and the answer wasn’t very much. This made the problem much more interesting!

So, assuming you have an IT shop of under 100 people and you want to start moving to Agile, how can you do it without spending hardly any money? How low can you go?

There are three areas you need to concentrate on in order to start. They build on each other, so I’d focus on them in order. And they’re not what you’d expect.

Successful Agile Adoption Means Creating Awareness

People need to understand that folks just like them are doing things differently and in a way they enjoy, and that management wants that for them as well. Without awareness that it’s possible to change, people are always going to say “But that’s them. We’re not like that.”

Action Pros Cons
Send somebody in management to some kind of non-vendor-associated seminar or conference Being around other people in a similar circumstance is a great motivator for people to understand the benefits of change. It allows them to see people farther along in the journey, as well as people at their same level, giving a sense of context and purpose. Can be expensive
Could be very difficult to get them to go
Get as many as possible to take a road trip to visit Agile celebrity speaking somewhere close-by Gives everybody a chance to voice their objections about Agile adoption
Gives people a chance to meet others in the community
Can be a hassle to find the time
Find some free online videos with teams talking about their experiences and spend a month watching them during lunch Gives people a chance to see what others are doing It’s a pretty lame idea. You aren’t changing the context of the work environment, so it’s likely people will brush it off. Might work, though. And it’s free. Couldn’t hurt to try.

Successful Agile Adoption Means Creating Desire

People need to believe that the Agile journey — adopting best practices in iterative and incremental development — ends up in a place where many of their frustrations are solved. That means understanding that it’s a journey. You are never complete, and there are always new best practices and ideas to try. It also means understanding that you’ll try it “by the book” for a while, then adapt to your own situation. No book or class is going to change your shop completely and fix everything that’s wrong, but they’ll give you some good places to start. An ongoing desire for change is absolutely required, and it can take a while to cultivate.

Action Pros Cons
Before you start, brainstorm with your developers the top five problems they are having with the way things are being done. Be sure to get 2-3 examples of each kind of problem. Then create a series of brown-bags where you show how other teams conquered these problems using Agile techniques (assuming they are Agile problems, of course!) Comparing problems to solutions is a great way to increase desire This can be easily considered as propaganda, or to say this more diplomatically, people can think that because you are a cheerleader for change you are cherry-picking your examples and over-promising
Invite 3 or 4 developers or team leads from far away — another division or another local company — to come in and talk about how they had these same problems and how much they like making the switch Nothing works like seeing somebody else with your same job title talk about how changes made them happier It can be difficult to break the ice
Do the exercises above, only with management instead of everybody else Management has special concerns like being able to predict cost and delivery, and they have different ideas of how things “should” work. It’s good to get these on the table and sometimes isolating managers helps do this. You really don’t want to go down two different tracks in your Agile adoption efforts. At some point you need to bring everybody together

Successful Agile Adoption Means Imparting Applied Knowledge

Action Pros Cons
Pick up Scrum It’s a wonderful Agile management methodology
It’s pre-canned and very simple
It’s a good place to start
Your Agile adoption is going to end up there anyway
Even though they say it’s not a magic bullet, people keep thinking and acting like it’s a magic bullet
Everybody has to know it and it can be expensive if you want to formally train the entire team
Find a trusted outsider — any outsider — to play coach and referee as you make the change Outsiders that aren’t wrapped up in delivery, but know some Agile, can help you see things you can’t because you’er too close to things Many teams are not used to having outsiders around. It disturbs the dynamic, which is kind of the point
Do a group book-reading Group reads are great ways to get people thinking the same things at the same time. Agile adoption really isn’t in a book. Books can help with learning the key phrases and concepts, but there is a limit to how much you can get from them
Different books can give different pieces of advice
Pick up a couple of our by-the-numbers Agile books, ScrumMaster and Backlogs, as places to get started. Having detailed direct instruction can many times be the best way to start Initial success could lead to no adapting later on, which defeats the entire concept of Agile adoption

It’s very possible to start down the road to Agile adoption without spending much at all, but you have to realize that you are not trying to transfer facts into the heads of people. You are beginning a process of practice, reflection, and adaptation. It’s also much more important to make sure the “stage is set” than it is to pick up particular practices, because practices are meaningless unless you’re doing them for a purpose that everybody wants.

Look at it this way. You’re creating a jazz band out of some average musicians. Everybody knows the basics of their jobs, and most of them could do a little “pick-up” work with some of the others from time-to-time. But the trick is getting them all to play all together in a structured yet completely freeform environment. That’s too much to go directly after — and if you try it’s not going to work. Instead you work “around the edges” getting a rhythm to learning a bit (book learning is not going to be really important), playing all together at some simple short songs that are more structured, improvising a tiny bit at a time, and having some kind of practice-perform-mentor loop set up for everybody.

Yes, you can do Agile adoption on a budget, but you need to make sure you have a good mental model of how the process works if you’re going to pull it off.

Agile Adoption Follow-up

If you’d like to join the conversation about Agile Adoption, visit our landing page for the upcoming Agile adoption e-book and get on the mailing list. While waiting for the Agile adoption book to come out, you might want to check out our book on being a ScrumMaster.


Want to learn more about Agile?
Take our no-frills weekly Agile Tune-Up course


Follow the author on Twitter

March 6, 2012

2 responses to Poor Man’s Agile Adoption: How low can you go?

  1. PM Hut said:

    Most of the companies I know who have already adopted Agile consist of less than 100 employees (in fact, many of them consist of less than 20 employees).

  2. Pingback: R&D | Agile Adoption and Transformation – Linkapaloza

Leave a Reply

Your email address will not be published. Required fields are marked *

* Copy this password:

* Type or paste password here:

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>