This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Using Agile To Scale Agile – Part 4
In my last post, part 3 of Using Agile To Scale Agile, I laid out an example of what an Agile Transformation Release Plan might look like for our mythical organization. In part 4 we’re going to dive into the first epic of the release, ‘Identify the right pilot project’.
In my experience and based on discussions with some of my peers in the agile development community, one of the most important criteria for success with agile is that it have a fertile environment to take root and grow. In an organization this can be best characterized by executives that are willing to provide and support an environment for learning and adapting, which enables continuous improvement. Executive support for the pilot projects to serve as learning opportunities is essential, and as we know, we learn more from failure than success. This requires the fertile environment that fosters learning and adapting that I mentioned above.
Once you can secure even a microcosm of the this type of environment, then you can look for projects that can meet the following criteria.
Pilot Projects Should Be Visible & Meaningful
Don’t be tempted to select pilot projects that are off the radar and of little importance. You are just inviting those fearful of change to sabotage your efforts because the cost is low to them and the organizations. Be sure to pick projects for your pilots that have visibility & meaningful impact to the business.
Early agilist and inventor of the Adaptive Software Development process, Jim Highsmith, probably put it best in Agile Software Development Ecosystems: “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.”
Of course if your efforts are more grass roots, the level of criticality will have to be balanced because it can be difficult to get stakeholders to take a risk when they aren’t yet educated on the benefits of agile. In other words, they may be missing the reward data when they intuitively perform a risk/reward analysis.
Another important criteria for selecting candidate pilot projects is project length. Look for projects that have a relatively short release time line, preferably less than 90 days. This makes it easier to demonstrate the delivery of value and keep momentum and interest high. Nothing makes converts quicker than successful delivery of value; getting early and frequent ‘wins’ is important.
Once you’ve identified some candidate pilot projects, now you need to consider your ability to staff the key roles. You don’t want a critical project to be your pilot project if you can’t put ‘A’ players on it that are dedicated and committed to its success. Let’s take a look at the key roles.
Product Owner Role
It must be understood that the Product Owner is perhaps the key role to staff with strong players to help ensure your pilot project’s success. This role must be committed to the project and empowered to decide on scope and schedule.
From my experience, not having a strong product owner role that is deeply involved with and available to the team, and who is empowered to make decisions about scope and schedule control, is usually one of the main impediments to success with agile.
I refer to the PO as a ‘role’ because it is unlikely to be one person in a successful scaled effort. Once we have secured the right player for the Product Owner role we need to ensure the availability of a dedicated and cross-functional team.
Dedicated Cross-Functional Team
To help demonstrate the true capabilities of an agile team, it is important that the team for our pilot project(s) be cross-functional, with representation from Dev, QA, UI, business analysts and if appropriate, tech writing. Another advantage of starting out with a cross-functional team is that they will all get educated and indoctrinated into agile and will take the message back to their functional constituency to help get others at least curious about trying out agile.
Our cross-functional team needs to be dedicated to the pilot project effort. If the pilot team is split amongst multiple projects, this has a high probability of failure. It puts at risk the trust the team has with respect to the organization’s commitment to the change, it will effect the commitment of the team and it can compromise the team’s velocity.
Scrum Master / Agile Project Manager
The final role that we must be sure to select wisely is the Scrum Master (if Scrum has been chosen as the agile project management framework) or the agile project manager. This individual needs to have a strong understanding of agile project management and the approach the team has selected. They also must have strong facilitation skills.
Additionally, it is highly useful for this individual to have experience with escalating issues in their organization and know the right people to get things done. This will be vital in their agile role on the pilot project, as they clear the impediments for the team to allow them to be as productive as possible.
With our candidate pilot projects identified and available staffing considered, we should now be able to select the specific pilot project(s) that will have the right visibility / important and the right staffing to maximize our chances for success. In part 5 of Using Agile to Scale Agile, we’ll discuss agile assessment, education and coaching for our pilot project pilot team and the wider organization as part of our overall Agile Transformation efforts. Stay tuned…