This post is inspired by a question on LinkedIn but I felt required a full blog post to really explain the answer.

There are plenty of companies that still develop their applications using the traditional waterfall model, or even a complete lack of formalized processes. This is somewhat surprising considering the amount of information available that talks about the benefits of agile development. There is a lot of information that also shows very good statistics about agile development success and traditional waterfall development failure.

So, why do companies not adopt agile processes? Sometimes their first exposure to agile development is with Extreme Programming (XP). XP is one of the most disciplined approaches to agile development, and one of the harder processes to implement. XP is also very developer focused, so project management and business owners may not feel entirely involved in the new processes. Many developers also have issues with the XP process because it is very different than what people are used to. Scrum is another process that companies may try because it does not seem as drastic a change as XP. The problem here is that Scrum looks like it is more flexible, but it is not. If anything, Scrum requires discipline from more people because it is targeted at the full project, not just the development team. So, this includes QA, the business owner, the product manager and anyone else that has a vested interest in the project. What may happen with Scrum is that the people not directly involved in development, meaning the business owner, product manager and others, may not be fully committed and not adhere to the principles of Scrum.

After the agile project fails, whether it is XP or Scrum, the company sees agile processes as failing in their company. You will hear things like “Yeah we tried Scrum, but it really does not work well in our environment” or “We did XP for a while but we did not really see the benefits that everyone talks about”. If you ask these companies about the projects that failed, you typically hear that they eliminated various roles or practices from the processes for some reason. In XP, you hear that pair programming was eliminated because the project was already behind schedule and they couldn’t afford to have two programmers work on one task. Now, the company feels that agile is bad and will always fail “in their environment”. The company is now anti-agile.

So, how do you re-introduce agile processes into an anti-agile company and succeed with your agile projects?

Lies and entrapment.

What do I mean? Let me explain. First, the developers need to agree on adopting Scrum as the general process. Two week sprints are also a good starting point as they allow a team to get stable features released instead of just tasks completed. At the end of the sprint, the “release” must be deployed to a somewhat stable development server at the minimum. The development manager and project manager, meaning the people with those HR titles, need to agree that Scrum is a good direction and that they will take on the roles of Scrum Master and Product Owner. If these two people are not in agreement, the project will go nowhere. Try to get QA involvement as well. If QA agrees to test features as they become available, and have a regression test cycle at the end of the project, you will have a much greater chance of success. If this is not possible, the Scrum Master and Product Owner will need to test the new features in order to “accept” the release. This acceptance is based on passing unit tests, the demo at the end of the sprint and whatever functional testing they are able to do within one week. Lastly, you should not mention Scrum or the agileness of the project to anyone outside of the team.

How is this lying? Within the team, everything stays agile. You can have burn down charts, a product backlog, user stories and any other agile practice. Outside of the team, you can report progress based on the traditional waterfall project plan. It may be a little extra work for the project manager, but the benefits can be huge.

What about the entrapment? If your project is long enough, at least 6  2-week sprints, start inviting other people to the sprint demo. Let the business owner and product manager view the demo and give them logins to the development system so they can use the application. Essentially, give them a little taste of the drug, and by the time the project is finished they will be addicted. Even with the demo, you still do not want to mention Scrum or agile, but you can state you do the internal deployments to ensure you can test functions against a baseline. So, if you are making changes to a previously developed feature, you can go back to the previous version to see how it was working before. By seeing the progress of the project, and being able to actually uses the system before it is released to production, you can gain adoption from people outside of the team.

I have seen this practiced at two organizations where Scrum had failed previously and the company was definitely hostile to agile methods. In one case, the company saw the benefits and slowly rolled out Scrum to various project teams. In the other case, the company saw the success and immediately switched to Scrum for all future development. Admittedly, this may not work in every organization as it is highly dependent upon how independent your development teams can be. What’s the worst that can happen? Your project fails, just like the failed waterfall projects before them, and nobody is any wiser.

http://static.zemanta.com/readside/loader.js