Use Pilots to Steer Your Agile Journey
Pilots are an important pillar of agile ways of working. By setting up small, cross-functional teams to solve complex problems and empowering them to work in an iterative way, companies can experiment with ways of working that can lead to great products and experiences.
If pilots are a critical first step toward deciding whether to continue on a wider-scale change program, how do you decide where to start?
Through BCG’s work in agile transformations, we’ve encountered three questions for leaders to consider when plotting their approach to pilots. I shared those questions yesterday at BCG’s Agile Exchange conference in Amsterdam, during a round table discussion to help our clients share their perspectives.
1. What pilot will have the greatest impact?
Initial pilots have a lot riding on them. They can be the catalyst that encourage others in the company to adopt agile ways of working. The pilots should make an impact, showcase a different way of thinking, and get people excited. On a basic level, a pilot is a team of people with different areas of expertise who collaborate to come up with the best way to deliver value. They work in short cycles with powerful feedback loops inside longer development road-maps. Pilots are also used to establish what broader changes are needed in your operating model to enable this way of working.
Choosing where to start can be difficult. If you use a pilot to develop a new product, you have the luxury of building something from scratch, including team culture, skills and technical practices. But it won’t help teams working on existing products understand how agile ways of working could apply to their context. Likewise, if you run a pilot for an existing product or service, you will have to deal with a lot of existing behaviours, but you will realize faster how much change is needed in your organization. It’s hard to move the status quo, so changing how you work will take longer in an environment with an established culture. Both options can be successful, as long as you are aware of the trade-offs.
2. How should I structure a pilot?
When setting up a pilot, first decide the problem the team is trying to solve. Once you’ve identified that mission, you can use it to decide on the size of the team and the skills that team members should have. Pick team members who are willing to adopt an experimental mindset in discovering what works best for their mission.
You also need to decide on the number of teams. A single team of five to nine people can work and learn at a relatively fast pace. But opting for a single pilot team limits your ability to test how broader support systems such as governance and budget cycles would need to change to accommodate a different cadence of feedback. If pilots involve multiple squads or an entire department, developing a plan to roll out new ways of working to the entire organization could go faster. But you run the risk of alienating people by making them feel like they’re being forced to change. People resist working in new ways as a result, which could stymie change efforts. To increase your chances of success, staff pilot teams with early adopters who are willing to experiment and champion a different approach, and let others follow once they see the benefits.
3. How do I know when to expand from a pilot to a wide-scale implementation?
Pilots’ full benefits come when you expand what you learned from them to the entire enterprise. We frequently talk about this as taking a pilot beyond the tipping point , shifting work from the team level to the enterprise level. You may learn that you need more teams to deliver larger and more valuable end to end product iterations. You might discover that smaller team make it easier for team members to communicate. A pilot might show that team leaders need coaching to adopt intent based leadership that is highly receptive to feedback, or that you need to adjust the scope of a product release because it’s so complex.
It’s worth noting that not all pilots work, and that’s okay. Failed pilots teach organizations if they need to adapt to be successful and how to make those changes based on real world evidence.
**
Pilots are learning vehicles. They can help decide how to organize around value, what skills you need on a team to deliver that value and what changes to make in the broader organization to enable autonomy. But choosing a pilot isn’t easy. Consider the pros and cons associated with these experiments and if you’re genuinely open to what they might show, you’ll have started your journey to becoming a learning organisation that is ready to be agile at scale.