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"?
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.
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
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!
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.
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.
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.
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
then...
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.
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
Hope that made sense.. as you may have guessed I've been at this for some time :)
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. Really a must see video. You may also be interested in another videos about agile adoption.
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
Change Your Organization Diary details one man's attempt to effect change from the bottom up.
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"?
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 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!