If your organization is planning to adopt an agile methodology, one of the first and most important challenges you'll face is selecting the right project for your agile pilot.
Over the past eight years, I've worked with a large number of organizations that have made the transformation to agile. I've found that picking the right project for the pilot is critical, as it can demonstrate the effectiveness of the methodology, win executive support, and instill employee confidence. The wrong choice can have quite the opposite effect, making it difficult to convince anyone of the future value of your agile transformation.
Three key considerations to take into account in picking your first agile project include: the size of the project; the importance of the project; and the availability, location, and interest level of talent.
Ultimately, all of these considerations revolve around managing project risk. You don't want the project to be so risk-free and easy that it doesn't capture leadership attention or demonstrate the benefits of agile processes. Nor do you want it to be so important and fraught with risk that the you are compelled to circumvent the new agile process in order to just "get it done."
I tend to scope out project size in terms of the ideal size of agile teams. Ideally, I would select a pilot project that can be delivered with no more than three agile teams. Many agile coaches shy away from the idea of a multi-team pilot, but I've found that a larger project allows you to exercise different aspects of the methodology and toolsets that you'll need for future scaling. Nonetheless, this is a judgment call that's best made on the basis of the maturity of your organization. If you already have some experience with agile, then it may make sense to opt for a multi-team project. If you have no experience with agile, a smaller project will be more manageable.
Additionally, I recommend looking for projects in which the team(s) participating in the project can be fairly self-contained. The more dependencies they have on other teams or outside groups, the greater the risk and complexity of the pilot.
A related consideration involves project duration. You want your pilot to be short enough that it doesn't lead to exhaustion or disinterest, but long enough to make it through the initial change curve and demonstrate progress.
There is a school of thought that recommends that the first agile project be truly critical and highly visible. There are benefits in the level of interest and scrutiny this brings. Highly visible projects can definitely help drive executive support for your agile transformation; however, I suggest you avoid projects which are so important they cannot be allowed to fail. The purpose of a pilot is to test, refine, and prove the value of significant process changes, which will have broad effects across the organization. Coupling this type of change with no-fail scenarios and high-pressure projects adds risks both to the project and the transformation you are attempting to make.
Selecting the right level of criticality is difficult. The project(s) you select for your pilot should be of sufficient importance and visibility that business leaders will care about the outcome and stay involved in the change, but not so critical that the schedule and demands of the project always trump innovation and process adaptation.
The kind of talent available, the location of the talent, and the amount of energy and excitement the future team members have for the agile process are important considerations as well. If you select the perfect project for your pilot but your resources have no aptitude for or interest in the changes you are attempting to make, the likelihood of success is limited at best. Pick a group that includes advocates of the agile methodology who are enthusiastic about working in an agile environment.
While dissenting opinions are often good for forcing introspection and adaptation, avoid selecting team members who have a highly critical or combative stance toward agile processes. If your organization has made previous attempts at agile transformation, get the relevant background information and choose teams accordingly.
Location is also key. Virtual or distributed teams are becoming more and more common; however, they add a layer of complexity that may not be needed in your first attempt. I suggest you build teams that are representative of typical distribution in your organization, but lean toward co-location when possible.
Finally, you'll want to ensure that the skill sets you need for the project are actually available. If you have to train team members from scratch, you add more even risk and complexity to the initial project.
Beyond questions of size, importance, and talent, a few additional considerations may be worth contemplating as you look for the right project.
Innovation and new development projects will win greater support than maintenance projects. I also prefer software projects to hardware or business-side projects, as the more mechanics that are involved and the more organizational change that is required, the greater the complexity and risk.
Risk is a necessary part of any change. The more effectively you manage risk, the more likely you can focus on delivering a successful pilot that allows you to build agile processes and demonstrate what these can do for your organization.