The pilot will be the first time the new life cycle is exposed on a real project with a real team. In effect it is a marketing event for the new process. If you choose the wrong type of pilot you could end up aborting, which would be a poor advertisement for the new process.
With that thought in mind, you want to select a project that will push you through the test but not shove you. You want time to test the process in all areas such as requirements, design, development, testing, and implementation. You also want to give your pilot team time to acclimate to their new level of ownership. Agile is about a process and a about culture. You want the team to understand the literal process, but you also want them to start understanding what it means to be Agile. You want them to start envisioning what it is like to own a project and being highly involved in decisions throughout. Let’s take a look at the traits of a good pilot project.
One of the easiest ways to complicate your migration is to test your new methodology on a large project. A large project will require training many people on the new methodology, and potentially several third parties. This will delay your ability to gather feedback on the new process and adjust it, which is the ultimate objective of the pilot.
HOW LARGE IS TOO LARGE?
Let me give you an example of a project I worked on that would be considered large. We were upgrading the company intranet platform and the project was scheduled to run for eight months. The project went through several gateways to obtain funding. The project required high involvement from the software provider. Consultants were also needed to train the team on the new software. Since the application affected the enterprise we engaged several internal teams to help us with training, communication, and security. A project of this length and scope would not allow time for testing new processes. We also do not want to work on a project that is too small. If a project is too small you will be limited on the areas and phases the new process can be tested in.
HOW SMALL IS TOO SMALL?
An example of a small project would be one that I recently managed. My company decided to change the appearance of our brand. All of our web pages would need to support the new company colors, logos, and slogans. Our project would need to touch every page of our sites, but we could do most of the work by changing one style sheet. The project required high involvement for the User Interface team, but the development, implementation, and testing areas had minimal work to do on the project. The project was completed in a few weeks. If this project were used as an Agile pilot, the User Interface team would have learned more about Agile but the other teams would have had limited exposure. The new process would not have been tested well because the areas outside of User Interface did not perform their typical project tasks.
So what is the right size for a pilot? Your pilot project should have an overall estimate somewhere between a few weeks to a maximum of 8 weeks. If your project runs longer than this you will extend the time needed to record feedback on the process, which will delay your ability to adjust the process.
On occasion I cross the path of folks who do nothing but large projects. They tell me that a short project for them is three months and they do not know how they could do a pilot that meets my criteria. The way to handle this issue is to find a subset that meets the criteria of a short project. The question you need to ask is, "What do you do within a project that can be completed within 8 weeks?"
The first thing to do is to look for a subset of features within the project that can be completed within 8 weeks. Is there a group of features that could go together as a mini-project within the larger project? For example, if we were building a web site similar to eBay, the project may take 6 months to a year.To test our new methodology, we could grab a few features and test the new process on them. For example, we could do a mini-pilot project around seller feedback and its related features.
If you go the subset route you may have limitations on how far you can test the new process. Your subset of features may need to rejoin the other features and go through the legacy testing and deployment processes. If you experience this issue you can try to pull the features completely out of the project in subsequent tests, running the features all the way through to deployment.
A MEDIUM PRIORITY PROJECT
Your pilot project needs to have some level of urgency to test the new process under pressure, but if the project is deemed critical failure will not be a viable option. You may panic, abort, and revert to methods you are more comfortable with to complete the project. As mentioned in section 6.1, the pilot project is a marketing effort as well as a test of the new process. You do not want to send a message to your company that the pilot was aborted.
So how can you tell if a project is critical? A project is usually critical if your company or the customer cannot survive without it. Here are some example projects that a business would consider critical:
- A project to ensure a revenue stream.
- A project that supports meeting a regulatory or compliance deadline.
- A project with expiring funds (budget tied to a timeframe).
- A project that delivers functionality that is a foundation for the organization (i.e. SOA).
From a customer perspective, these projects could be considered critical:
- A project tied to a fixed bid.
- Dependency on the project for a marketing campaign.
- A regulatory or compliance issue on their end.
Your objective should be to find a medium priority project. A medium priority project will allow some flexibility as you feel out your new process and it will also provide a level of urgency. You are moving to Agile to better support urgent projects, therefore you need to simulate this with your pilot.
Here are some examples of medium priority projects:
- Adding the ability to book hotels on an existing travel site.
- Delivering a maintenance release onto an existing platform.
- Adding customizable stock quotes to a portal page.
- Modifying your HR application to allow employees to view their vacation balance.
- Adding advanced search capabilities to your existing simple search.
- Converting your existing merchandise site to an auction site.
This article is based on Chapter 6 of Becoming Agile by Gregory S. Smith. It is being reproduced here by permission from Manning Publications. Manning early access books and ebooks are sold exclusively through Manning. Visit the book's page for more information.