Stack OverflowEffective Ways to Introduce Agile into the Workplace?
[+33] [13] Troy DeMonbreun
[2008-09-10 02:12:15]
[ agile scrum methodology culture continuous-improvement ]

In your experience (anecdotal or otherwise), what are some effective ways to introduce Agile into a non-Agile organization or company?

UPDATED: Can anyone speak to cases where you tried to introduce Agile but you were "shot down"? Also, do you now have a retrospective understanding why you were "shot down"?

[+25] [2008-09-10 03:39:32] Gishu [ACCEPTED]

IT'S HARD BUT NOT IMPOSSIBLE. Unless you live in paradise. For specific steps you could take I wholeheartedly recommend picking up a copy of Fearless Change [1]

  • First get management backing. If you don't nothing else will make up for this one.. If the upper level is all 'The deadline is yesterday..', 'Working weekends for the next 3 months', 'Why are you writing tests when you should be coding?.. we can test later.' The dodo simply won't fly.
  • See if the culture of your organization is suitable for agile. This was something I missed.. To borrow a line from the book.. The process will be easier-faster if the culture supports and nurtures new ideas, allows time for people to learn and do new things, is patient enough to support innovations with long term benefits and does not consider failure to be a death sentence
  • The People: Identify the innovators : early adopters : early majority : late majority : laggards ratio. The first 3 are your target audience initially.. should be around 30-40%.. that gives you the critical mass to get rolling. The trouble is Agile turns the spotlight on the elephants in the room.. deficiencies and issues become easily visible.. if you live in a place which has had a "Bozo Explosion" (to quote Guy Kawasaki's term), the change would be really slow and painful.. if at all. We have a tendency to assume that if an idea is good, it'll be accepted. Not true. Lots of sociological reasons raise their heads.
  • Next don't try too many things at once. Take it slow.. take it easy. The trick is to use a refactoring-legacy-code-like approach. Find little wounds here and there and patch them with an agile bandage. Make sure that the people understand the practice and benefits and they should adopt them over time. Not everything will stick but soon it becomes better on the whole. How soon depends on a number of variables some of which are out of your control.
  • Its a huge personal investment to make this happen. Re-examine if you are willing to make this committment and go through the ups-and-downs it brings. Also you may have to hand over the baton to someone else or a higher up.. Be prepared to relinquish change ownership for the greater good. Don't fall into the 'Its my baby' syndrome.
  • Agile is different for each team, each organization.. Not everything you read/propose will work.. let acceptance guide you towards the things that will work for your scenario. Find other ways that compensate for the practices that didn't take root.

Hope that made sense.. as you may have guessed I've been at this for some time :)


An awesome response. I've also found that adding high-value, low cost gee-gaws (like continuous integration) can help fly the flag. - Jeremy McGee
[+13] [2008-09-10 02:19:08] Ben Scheirman

Listen to the team, management, stakeholders and listen for clues. They are likely feeling pain in a number of areas which Agile directly addresses.

Stick to suggestions that can directly alleviate those pains. "You can't heal what you can't feel" -- so to speak.

This takes a LONG freaking time, but building trust is of utmost importance. With past successes and having the trust of both your team and your manager, they will look to you when it comes time to make decisions.

I've seen it happen with my own eyes, after years of frustration in trying to get people to change the way we deliver software. And while I'm having successes now, I'm no where near complete. There's TONS of areas for improvement, and I'm currently having the most success with introducing small changes that directly address some type of pain we're feeling.

Lastly I'd just say be very empathetic. I made the mistake of dismissing most ideas before I'd really though them through because I didn't read about it in "XYZ agile book." Listening to your team & trying to implement some of their suggestions will go a long way.

Good luck!

[+8] [2008-09-10 11:05:14] Sam Hasler

Change Your Organization Diary [1] details one man's attempt to effect change from the bottom up.


This should be the top-rated answer. :) - Rob Howard
[+7] [2008-09-10 02:20:20] Mark

Skipping the technical, we have found that finding a group within the organization that can buy into Agile methodologies and provide a 'test bed' was crucial. We had many people at our company that didn't understand different Agile terminology, were confused by terms and processes, and there was general fear.

My research group was highly interested in trying to make Scrum work (along with several other Agile type methodologies). Our interest allowed us to form a test bed within the company to try out the various elements. We did a lot of teaching first -- hallway talk with people, presentations for company execs, etc. We didn't push hard -- we educated. Then we asked for permission to just try it out with our group.

There will be lots of answers about empiracally showing how things like pair programming, test driven development, Scrum, etc can all save time, but at the end of the day I feel that the proof needs to come from within your company. Find a group that you can use as a test bed and get them to actually do it. Nothing will aleviate fears better than showing that your group that make it happen.

+1 its exactly what I was going to say. - eglasius
[+7] [2008-09-10 02:21:12] Ethan Gunderson

Cram it down their throat, but without them noticing ;)

I've been slowly trying to implement agile principles (mainly scrum) into my place of work over the last 6 months or so. I first introduced daily stand ups, which took some getting used to for everyone, but it's working out pretty nice. Since we all work on different programs that are all part of one system, it's a little difficult to follow scrum by definition. My next step is to start sprint meetings to follow each of our releases. We go on a month long cycle already, so the sprint length isn't an issue. I also plan on fully following scrum principles during our next major project. I am one of two developers on the team for the project, and he is all for continuous improvement. My hope is that management will see the benefits of what I am trying to accomplish.

I think the key is to take it slow. People who have been in the same position for years are generally against intrusive change, but if you can sneak it in piece by piece, they shouldn't notice. Start with the small frequent meetings at first as well. By keeping them short, management shouldn't see it as a waste of on the clock time.

Just curious. but "cram it down their throat" and "the key is to take it slow" seem at odds :-) I do agree though that implementing the principals can show management (of which I am one!) that these changes can be beneficial. - Mark
Slowly and gently cram it down their throat. - mquander
[+3] [2008-09-10 03:53:06] marcospereira

Improve yourself first. Really. Example is the strong way to talk about agile. Moreover, as someone already said, avoid technical definitions and just use terms that managers and executive people can understand. Two weeks instead Sprint; Planning instead Sprint Planning or Planning Game; Product Manager instead of Product Owner and so on. Michele Sliger did an amazing presentation about Agile in the Waterfall Enterprise [1]. Really a must see video. You may also be interested in another videos about agile adoption [2].

Where I'm working for, I learn that Scrum is a good way to start agile because management understands it fast. It is simple and has a nice name. Latter, when doing Retrospectives, you could suggest XP practices as improvements and will be a quite easy that people accept at least try them.

Kind Regards


[+3] [2008-09-10 02:15:39] jodonnell

Test-driven development. Demonstrating how unit tests can speed up your dev. time while simultaneously making the code more stable is a great first step toward drinking the agile Kool-Aid.

[+2] [2008-09-10 02:17:44] Glenn Slaven

We introduced it into our 'Maintenance' tasks (bugs, low-impact changes, etc) as a 2-week sprint. So the developers that were working on longer-term projects stayed as is, but we had a rotating Maintenance sprint. So everyone got a go at using burn-down charts and poker estimations while not disrupting the major projects.

Then as each major project ended, we started the next one using agile 2-week sprints. This whole process took a few months before everyone was on sprints, but it meant that there was less disruption & everyone could 'ease' into the process

[+2] [2008-09-10 02:24:05] Ash

Within the development team, introducing Agile is much more something you have some level of control over.

However I see the major issue is the requirement Agile has on requiring ongoing feedback from your "customer" or customer representative.

Therefore you really need to focus on the education side of things for those outside your direct development team, as they are likely to need to change the way they work in some way (ie much more contact with the development team).

The best way I would say is to focus of the inehrent benefits of taking up an Agile process and convey these clearly to your customer. Of course if you have a sales/accounts area in your company, the same applies there.

[+2] [2008-09-10 02:44:28] codeLes

Step 1: ensure your project has a beefy backlog, and make sure it's prioritized

Step 2: introduce SCRUM practices (manageable iterations, daily standups, scrum-master, product-owner, burndown charts)

Step 3: each iteration present team results with the burndown

implement TDD/BDD, pair programming, code reviews (all very gently), and if you have a good enough team get everyone co-located (a team-room if possible).

Above all, understand there will be resistance (WILL BE), so be ready to manage that.

Another thing to remember is that if you are a part of an organization (large or small) that as a whole will not follow these best practices then it may take a while (if ever) to feel like you're making progress.

[+2] [2009-03-26 20:52:36] eglasius
  • Demonstrate success - see mark's answer
  • Pay special attention to principles/techniques that would cause the highest impact in the company
  • Remember it is about agile principles, and not a process checklist

[+1] [2009-03-31 15:31:57] Osman

People are always resistant to change, and moving to scrum is a pretty big one. Motivation and direction are key.

The first step is to get people motivated to give scrum a chance. I found that Ken Schwaber's Google Tech Talk [1] has been very useful in getting people to recognize the benefits of scrum while providing a good introduction. Start with people who you feel will be receptive to the change whether they are developers or managers, so you can build some momentum. Getting managers on your side going to be a necessity at some point, but how you handle that depends on your environment.

After that, everyone needs to be trained, whether it means reading a book or having a lecture series. Unless people know how scrum works, you cannot start trying to implement the process.

Once people are motivated and have an idea of what they need to do, you need to have your first planning meeting and set up the necessary parts of scrum (scrummaster, daily meetings, etc.).

I would expect that the first planning meeting will not go smoothly, and will be a learning experience for everyone. Also the first few sprints will be very rocky, and probably behind schedule. The key part now is discipline and persistence. Do not let daily meetings run too long, keep the planning meetings on task, and make sure everyone is doing their roles correctly.

I think the people who are most resistant are people who have been doing software development a long time, or people who feel that by moving to scrum, they are admitting that they were doing something wrong before. It's a tricky obstacle to overcome, but I think by showing them the benefits you can slowly convince them. It just takes time. In my experience, product managers really are resistant because it forces them to be more clear about their requirements and what they want. But once they see how the agile process benefits them and makes their lives easier they get on board pretty fast.

Good luck!


[0] [2008-09-11 02:06:27] Troy DeMonbreun

Can anyone speak to cases where you tried to introduce Agile but you were "shot down"? Also, do you now have a hindsight understanding why you were "shot down"?

This is not an answer. ;-) - hstoerr
This is not a comment. =:-( - chaos
(1) This is not a reply. :-) - Troy DeMonbreun