Many of us would agree that when you are trying to implement a large change, start small. Just as it is easier to swallow a small pill than a huge one, the ability to adopt and sustain change is often simpler when the change involves baby steps.
This approach of small incremental changes applies to agile as well. For example, the improvement experiments which a team identifies during a sprint retrospective should be small to provide quick feedback on whether or not it they are worth pursuing further.
But when I read a recent HBR article by Ron Ashkenas and Nadim Matta on challenges with scaling a successful pilot project, it reminded me that this principle of starting small may not always work with agile transformations.
In the article, the authors listed some key challenges with successfully applying learnings from a pilot project to a larger context including:
- Reluctance from the mass market of stakeholders who are being asked to work in a different manner if the target audience for the pilot is those stakeholders who are likely to be the most receptive to the proposed changes. This is a “crossing the chasm” problem.
- Avoidance of organization blockers or impediments is relatively simple in the context of a single project but is geometrically more difficult as the scope of the change increases.
- Struggle in trying to lift and shift practices and learnings from the pilot project to the varied contexts of multiple different projects.
To this list, I’d add one more.
T
he primary source of delivery uncertainty to most knowledge-based projects is the predictable availability of the right people with the right skills and the right time. With a pilot, it is possible to stack the staffing deck in our favor by pulling skilled people out of their normal roles to work on the project.
If we don’t replace those staff with temporary backups, it impacts the capacity of each of the teams they were part of and likely won’t improve our relationships with the leaders of those teams. But worse, when the pilot project is over and we start patting ourselves on the back for the improved delivery outcomes, the main reason things went well is not because we were agile, but because we allowed people to focus on one work stream rather than engaging in their usual level of multitasking. When we then try to expand our rollout to multiple projects, the results are less promising because we haven’t addressed how much concurrent work we are taking on.
This shouldn’t discourage you from taking a pilot project approach with your agile transformation, but before promoting the learnings from that pilot, address fundamental work management issues first if you wish to achieve sustainable delivery benefits.
To read more articles by Kiron Bondale, visit his blog.
