One of the most important success factors for agile is the selection of the right project for you to apply agile methods. Good agile project candidates share these characteristics. First, you need to deliver a quality product quickly, but do not need to deliver it all at once. Next, you expect the requirements to change or evolve. Also, your organization is willing to free up very capable team members that can independently make decisions about the product you're producing. And, you believe the product can deliver business value in incremental pieces.
Let's look at a few examples of agile and non-agile projects to put this in perspective. Let's say you want to implement an executive information system. You have an agreed budget, strong executive buy-in, you have seven executives, each with very different needs. They definitely want something delivered sooner versus later, and they want the project done by the end of the year. This project has agile written all over it. The requirements will undoubtedly change and evolve as the executives start to see the possibilities. You can easily break down the project into sprints, as you could categorize and implement features by executive.
Let's look at another example. You need to do a business process refresh, replacing administrative processes with updated ones to meet greater customer demand. This is something your company does every three to four years, with a proven set of steps and processes to follow. The budget is agreed, all the scope must be completed, and you know what business areas and the number of processes that must be updated. This is not as good a candidate for agile. It does not serve a purpose to perform sprints, and ask if there are new features required at the end of each sprint.
The project's been completed in the past using other methods, which have worked, and people are used to. Could this project be implemented in sprint-like iterations? You bet. But just doing something in iterations does not make it agile. That project life cycle is sometimes called iterative, and can be a smart way to run a project. We also know all the processes must be refreshed. So it's not okay to time box the project, and only allow for some of the processes to be refreshed based on a pre-agreed schedule, which could happen with an agile project.
Best to use the more traditional approach which has worked in the past. Not all projects have to be implemented as just an agile, or non-agile project. It is possible to implement a project as a hybrid, of agile and non-agile. Take an introduction in a new product line in an existing business, for example. I might use agile techniques to develop new marketing products and get done as much as possible by the desired product delivery date. I would use a more traditional life cycle for the reorganization of people into the new product department, as each person must be evaluated, have their job responsibilities changed as required, and have their new job created.
I would apply the people changes first for a given area, and then the business process changes could be made by the newly reassigned staff. Using agile for the process changes is wise, as it forces the company to carefully prioritize the work, and implement the most important features, business process changes, first. Putting people into new positions is best done in a more traditional project approach. In summary, agile can be applied to several different scenarios and be implemented in different ways.
It all depends on the project and organization you're working in, and whether the characteristics of agile are the best way to create change for your customer.
- What is agile project management?
- Selecting an agile project
- Scoping the project
- Designing your sprint structure
- Collecting requirements
- Running stand-up meetings
- Managing issues and risks
- Tracking lessons learned
- Responding to change requests
- Closing the project
- Spotting signs of trouble