I was about to start this section with something like, "Scrum pilot projects have become more and more rare over the past four years. The benefits of Scrum have become so recognized that companies are now forgoing pilot projects and jumping right in." And then I decided that perhaps I should look up the definition of pilot project. Perhaps, like inconceivable toVizzini in The Princess Bride, it did not mean what I thought it meant. What I found was that there are indeed two slightly different meanings. One is that a pilot project is a test, with the results used to determine if more of whatever is being tested will be done. This is the type of pilot project that most companies now bypass—they know they want to use Scrum; they don't need to "pilot it" to verify that.
The other definition I found is that a pilot project is undertaken to provide guidance to subsequent projects; it pilots the way in doing something new. It is this second meaning that I'm interested in—the pilot that leads the way rather than the one that is conducted as a test. As an industry we have enough evidence that Scrum works; what individual organizations need to learn is how to make Scrum work inside their organizations. So, they often conduct one or more pilots as learning projects.
Four Attributes of the Ideal Pilot Project
Selecting the right project as a pilot can be challenging. Jeff Honious, vice president in charge of innovation at Reed Elsevier, led his company's transition to Scrum. He and colleague Jonathan Clark wrote of their struggle to select the right pilot.
Finding the right project was the most critical and challenging task. We needed a meaty project that people would not dismiss as being a special case, yet we did not want a project to fill every possible challenge—too much was riding on its success. (2004)
Not every project is equally suited to be your first.The ideal pilot project sits at the confluence of project size, project duration, project importance, and the engagement of the business sponsor. You may find it impossible to identify the "perfect" pilot project. That's OK. Consider the projects you do have and make appropriate trade-offs between the four factors. It is far better to pick a project that is close enough and get started than it is to delay six or more months waiting for the perfect pilot to present itself.
Duration. If you select a project that is too short, skeptics will claim that Scrum works only on short projects. At the same time, if you select a project that is too long, you risk not being able to claim success until the project is over. Many traditionally managed projects claim to be on track 9 months in to a 12-month schedule, yet in the end are over budget and late, so a Scrum project proclaiming the same may not be very convincing. What I find best is to select a project whose length is near the middle of what is normal for an organization. Ideally and frequently this is around three or four months. This gives a team plenty of time to start getting good at working within sprints, to enjoy it, and to see the benefits for the team and for the product. A three- or four-month project is also usually sufficient for claiming that Scrum will lead to similar success on longer projects.
Size. Select a project that can be started with one team whose members are all collocated, if at all possible. Start with one team, even if the pilot project will grow to include more teams.Try to select a pilot project that will not grow to more than five or so teams, even if such projects will be common in your organization. Not only is coordinating work among that many Scrum teams more than you want to bite off initially, but you also probably wouldn't have time to grow from one team to more than five anyway if you are also looking for a project that can be completed in three or four months.
Importance. It can be tempting to select a low-importance, low-risk project. If things go badly, not much will be lost. And people may not even notice a failure on a low importance project. Don't give in to this temptation. Instead, pick an important project. An unimportant project will not get the necessary attention from the rest of the organization. Additionally, some of the things required of a team transitioning to Scrum are difficult; if the project isn't important, people may not do all that is required of them. Early agilist and inventor of the Adaptive Software Development process Jim Highsmith advises, "Don't start with an initial 'learning project' that is of marginal importance. Start on a project that is absolutely critical to your company; otherwise it will be too difficult to implement all the hard things Scrum will ask of you".
Business sponsor engagement. Adopting Scrum requires changes on the business side of the development equation, not just the technical side. Having someone on the business side who has the time and inclination to work with the team is critical. An engaged business sponsor can help the team if it needs to push against entrenched business processes, departments, or individuals. Similarly, there is no one more useful in promoting the success of the project afterward than a sponsor who got what was expected. One sponsor commenting to another that a recent project tried Scrum and delivered more than past projects did will do wonders in getting other sponsors to ask their teams to also try the new approach.
Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010
The other definition I found is that a pilot project is undertaken to provide guidance to subsequent projects; it pilots the way in doing something new. It is this second meaning that I'm interested in—the pilot that leads the way rather than the one that is conducted as a test. As an industry we have enough evidence that Scrum works; what individual organizations need to learn is how to make Scrum work inside their organizations. So, they often conduct one or more pilots as learning projects.
Four Attributes of the Ideal Pilot Project
Selecting the right project as a pilot can be challenging. Jeff Honious, vice president in charge of innovation at Reed Elsevier, led his company's transition to Scrum. He and colleague Jonathan Clark wrote of their struggle to select the right pilot.
Finding the right project was the most critical and challenging task. We needed a meaty project that people would not dismiss as being a special case, yet we did not want a project to fill every possible challenge—too much was riding on its success. (2004)
Not every project is equally suited to be your first.The ideal pilot project sits at the confluence of project size, project duration, project importance, and the engagement of the business sponsor. You may find it impossible to identify the "perfect" pilot project. That's OK. Consider the projects you do have and make appropriate trade-offs between the four factors. It is far better to pick a project that is close enough and get started than it is to delay six or more months waiting for the perfect pilot to present itself.
Duration. If you select a project that is too short, skeptics will claim that Scrum works only on short projects. At the same time, if you select a project that is too long, you risk not being able to claim success until the project is over. Many traditionally managed projects claim to be on track 9 months in to a 12-month schedule, yet in the end are over budget and late, so a Scrum project proclaiming the same may not be very convincing. What I find best is to select a project whose length is near the middle of what is normal for an organization. Ideally and frequently this is around three or four months. This gives a team plenty of time to start getting good at working within sprints, to enjoy it, and to see the benefits for the team and for the product. A three- or four-month project is also usually sufficient for claiming that Scrum will lead to similar success on longer projects.
Size. Select a project that can be started with one team whose members are all collocated, if at all possible. Start with one team, even if the pilot project will grow to include more teams.Try to select a pilot project that will not grow to more than five or so teams, even if such projects will be common in your organization. Not only is coordinating work among that many Scrum teams more than you want to bite off initially, but you also probably wouldn't have time to grow from one team to more than five anyway if you are also looking for a project that can be completed in three or four months.
Importance. It can be tempting to select a low-importance, low-risk project. If things go badly, not much will be lost. And people may not even notice a failure on a low importance project. Don't give in to this temptation. Instead, pick an important project. An unimportant project will not get the necessary attention from the rest of the organization. Additionally, some of the things required of a team transitioning to Scrum are difficult; if the project isn't important, people may not do all that is required of them. Early agilist and inventor of the Adaptive Software Development process Jim Highsmith advises, "Don't start with an initial 'learning project' that is of marginal importance. Start on a project that is absolutely critical to your company; otherwise it will be too difficult to implement all the hard things Scrum will ask of you".
Business sponsor engagement. Adopting Scrum requires changes on the business side of the development equation, not just the technical side. Having someone on the business side who has the time and inclination to work with the team is critical. An engaged business sponsor can help the team if it needs to push against entrenched business processes, departments, or individuals. Similarly, there is no one more useful in promoting the success of the project afterward than a sponsor who got what was expected. One sponsor commenting to another that a recent project tried Scrum and delivered more than past projects did will do wonders in getting other sponsors to ask their teams to also try the new approach.
Source of Information : Pearson - Succeeding with Agile Software Development Using Scrum 2010
|
|
0 comments
Post a Comment