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"?
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 :)
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.
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.
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
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
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.
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!
Before thinking about introducing agile development first explore which is the best fit for your organisation / project. If for example you are looking at scrum consider whether you'd use it strictly or if a more loose form of scrum, or even another method altogether might better fit. My answer then is on scrum as your agile method.
Scrum is great for projects that require innovation, where little is known and where experimentation is needed. It isn't the best fit for doing things like maintaining existing products or handling recurrent maintenance work. Fortunately though, scrum is a loose framework and you can use it the best way you can.
For maintenance work Kanban might be better for you or you might try just a few scrum elements for managing the sprint and doing things like daily standups. I call this "scrum-but", "yes we do scrum in our company but...". That's fine, don't feel bad about it.
For introducing scrum proper in your organisation you need involvement of the product owner and stake holder. If you're a small company, that guy might be one person, the boss, and in a larger one a product manager and the department head / boss. I would suggest two routes for introducing scrum:
1) you can start using scrum in a slightly looser form for managing existing work queues immediately. But look into Kanban too.
2) start using scrum in a more strict form on some new project that will require innovation, early feedback and where much is unknown. You can suggest to the boss / product owner that scrum would be ideal for this new project.
But remember! this isn't just about code, the product owner has a crucial part and must understand and fulfill his/her role. That means for example not writing all the specs up front, rather starting with the minimum, rapidly iterating, getting feedback, learning and feeding that back in and so on. Try to work with a product manager who would be as keen to introduce scrum as you are but from the product owner side, and ideally he/she should be tough enough to fend off management requests and protect the sprint.
It'll take united effort from development and product management to introduce scrum.
On such a new project, try and get the new team moved to a separate room and use post-it notes to visualise work in the various states such as backlog, in progress etc. Don't get bogged down in electronic tools at this stage, keep things as simple as possible. Don't feel silly doing planning poker with cards when you start too, once your team is up to speed you probably won't use them just say the numbers.
In my experience it is easier to introduce scrum in a pure form first then ease up on it for more maintenance type work queues. It is harder the other way round.
My final comment is to beware thinking scrum is some development panacea, it isn't. Scrum is a useful and simple framework for product innovation but explore other methods combining as your business requires it and don't feel bad about it.
Some years ago, I was consultant in a very large company (nearly 20,000 employees) that was running many large enterprise software projects. I was on one of them. A quite critical one.
We faced many problems and the pressure was strongly pussed on us, the development team. Problems were just common to software industry, but the management had a more infrastructure oriented experience and very few software oriented experience. So everything was focused on us. I thought it would be a great idea to tell the management about Scrum.
I was faced with strong reluctance, so I dropped the idea for a while. But the problems continued to add up so with the sponsor of the team leader, we finally decided to make Scrum anyway, by ourselve.
Anyone, including me, had any experience with Scrum. So we discovered the framework by doing...
Today, Scrum is generalized to the whole enterprise through a program administered by a certified trainer. I do not know if our initiative was the trigger. That said, I know that it was a real revolution in quite rigid company.
I think to introduce something into an enterprise like that, you must respect the following principles:
It has to change is necessary. If there is no compelling reason that the change must be done, there is no reason why management teams in place to take risks.
We must focus on the problems of management and not to mention the problems of the developers, unless they are part of management concerns. In other words, you must come with a solution for them, not for you. Put yourself in the management's shoes. What are their concerns?
You should not propose to change the whole organization at once. You must propose a pilot project which you would take the responsibility. I advise you to give realistic goals, such as the significant increase in the visibility on what is going one in the project. It is, IMHO, the main contribution of Scrum to software management. It allows the human common sense to operate and thus move forward.
Finally, it is imperative to ensure that experienced people are in control of this introduction. Do not just read a book or two. You have to go to training and I would say it is rather necessary to use an experienced coach. Obviously, it can be done without, but it will be in pain :)
If you follow the principles and come with facts, it will works. About facts, you'll find many in the book Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, And Leave Competitors In the Dust. It's the latest book of Scrum's creators, Ken Schwaber and Jeff Sutherland.
In a blog post of Ken about the book you can read:
Jeff Sutherland and I have done it. We wrote a book together, our first joint writing since the initial publication of Scrum in 1995. What prompted us? The question that we frequently are asked:
How do we sell Scrum to our management?
I’ve always been puzzled by this question. Why would you have to sell more predictability, productivity, quality, value, risk control, satisfied customers, engaged employees, and less waste to anyone in management? However, I talked with Jeff and we figured that where there was smoke, there must be fire.
We spent the last half of 2011 writing the book. Any manager, from top to bottom, can easily pick up and read this book.
[...]
We see it all the time. (full disclosure: I'm developing a project management application). The problem is that agile methodologies introduce an inherent tension into traditionally managed organizations. Typically, upper managements wants to be able to plan ahead. They want 3-year plans; they want properly estimated projects; they want to be able to budget hiring new people; they want to be able to commit to significant milestones when it comes to partners/customers.
But then the R&D department decides it's going to go agile. It's no longer about planning ahead for two months before writing code. Sprints are going to be short and beyond sprints you get very low-resolution estimates of the stuff that's in the backlog/roadmap. R&D realizes that requirements change way too frequently for classic waterfall to be effective, but product managers want a clear, thought-out and well budgeted vision of what the product will look like in 12 months.
The problem, then, is to reconcile the two. As I said, we see this all the time happening with our customers. Our solution is thus to unify the tools used to do both sprints and long-term planning. Okay, now here comes the part of the shameless plug, so feel free to take it with a grain of salt. One of our unique features is that we use a zoomable-user-interface for managing tasks. Meaning it's very easy to drill down into some user-story/task and elaborate on it. (you can see how it looks here). There's actually no concept of a "project" in our system at all. It's all tasks containing other tasks, linking to other tasks (a fractal, really). This creates a nice blur between user-stories, tasks, projects, epics, etc.
In practice, what many of our users who practice agile methodologies do, is create a telescopic plan that merges the long-term road map (or backlog) with managing the short term sprints (or iterations). Managers still get to see a nice, estimated road-map of major features waiting to be added, and developers simply zoom in more deeply and deal with actual work tasks. One advantage this has is that it reduces the amount of "haggling" that takes place when managers review the work-plan. Instead of the development team providing only very rough estimates (i.e. "4-6 weeks!"), they get a chance to zoom into each user-story in question and break it down to smaller chunks. When you do that there's suddenly less room for haggling. You spend 10 minute breaking down a 5 week user-story into chunks that are about 1-day in size, and all of the sudden the argument isn't "no, you can do it faster. no we can't. yes you can." but "here's what goes into this effort, including all the hidden work the initial estimate didn't consider. What do you suggest we eliminate? Quality assurance? Testing? Training the new guy? Setting up the build environment?".
This approach works as long as you're using a tool that lets you change plans as quickly as you initially draft them. Which is the real reason people these days detest waterfall. Most systems make it exceedingly hard to completely redo existing plans and people are very rationally refusing to waste time on this activity.
Okay, I feel like this is turning into a sales pitch, so I'll stop now. :)