Coaching Case Study Part 2: How a Skeptical Team Forged Its Own Path to Agility
This is Part 2 of an article about how we helped a team overcome Agile doubts to drive small sets of incremental change that improved performance, teamwork, and culture. Read Part 1 to learn more about the background and challenges we faced. And read on to learn about the coaching plan we executed to help this team develop a more Agile mindset.
Overcoming the Resistance
To help this team of 25 overcome its challenges of skepticism, lack of Agile knowledge, and cultural barriers, we crafted an Agile coaching plan with four key characteristics.
- Working with leadership to provide transparency and create space to experiment and learn
We believe that engineers generally want to do the best work they can. What keeps them from doing so are usually environmental factors, for example, management overhead, compliance requirements, or ineffective practices. If you give engineers the tools they need to do a great job and get out of their way, they will attempt to optimize. They still need vision and guidance to know what they’re doing and why, but ultimately, management needs to trust the team for Agile approaches to thrive.
To build that trust, we had regular, honest discussions with management about what the team needed from them to be successful in an Agile culture. We helped create a safe space for the team to take risks and make mistakes without fearing top-down reaction from management. This built the foundation for a positive team culture driven by learning and continuous improvement. We were fortunate that the senior management was supportive of this approach and encouraged us. Without this partnership, we would likely not have succeeded.
- Adopting a retrospective process and using it as an engine for change
Agile processes work best when teams reflect on their progress and chart a new course based on what they’ve learned. This requires a culture of understanding value and making data-driven decisions. We introduced the team to the retrospective process as a recurring conversation to identify the most important issues that needed our focus, creating action items to address them. We focused on moving from statements like “I feel…” to statements that included “based on our metrics, we know…”
With support from the Technology Director and the business unit, we began focusing the team‘s work on alignment with business goals. We initially agreed with the team on three metrics they felt would be useful for measuring their progress. The key is to find metrics the team values, not metrics management values. When teams are pushed to track metrics they don’t believe in, it creates bad behaviors, like gaming the system or optimizing for the wrong work. For instance, tell a new team you want them to report their velocity, and they will spend a lot of time debating what they should “get credit for.” Even worse, tell a team you will reward them for better velocity, and they will hyper-inflate their story points.
Instead, have a team identify a few metrics they feel are true measures of their ability to deliver value, and like monitoring the speedometer on a car, they will watch them and adjust behavior accordingly more often. That combination of regular retrospectives, alignment, and metrics enabled the team to find the gaps in their processes. It also helped them begin building a culture of collaboration and trust.
- Educating the team on the value of Agile (the “why”) while focusing on a small set of goals
For a team to take off, it needs to have a sense of purpose. One of the biggest mistakes organizations make is focusing too much on the mechanics of implementing Agile processes and not enough on the “why.” This leaves the team with a sense of routine, but not of motivation. Our goal with an already Agile-skeptical team was to motivate them by demonstrating how Agile could benefit the team and each person on it.
It was important to show benefits that were tangible, not theoretical, and to help them understand that Agile isn’t the solution for every problem, but it is a useful mindset for arriving at solutions. Their team didn’t fit into an “Agile mold,” but by using introspection and Agile techniques, they developed a sense of purpose and ownership, not just of the product, but also of the process.
- Not imposing a method, but problem-solving toward a method that worked for them
We didn’t want to tell the team how to implement Agile. We prefer teams deal with challenges themselves, which gives them a sense of ownership. Scrum was a viable approach to address the gaps in their process, but the team was resistant to imposing a predefined methodology – largely because they believe the work they do with data manipulation and scaling is vastly different from typical software development activities. So, we began solving for specific problems within their way of working and used each of their retrospective challenges as an opportunity for them to form their own solutions.
First, they agreed they needed better visibility of status, so they developed their own version of standup meetings to share updates. The next problem was a need to more easily obtain stakeholder feedback, so they began having the equivalent of sprint reviews. At this point, we were able to demonstrate how feedback from the reviews could flow into retrospectives to drive action.
It became clear they needed a tool to provide transparency and track data for metrics, and JIRA became useful as they began to see the benefits of using it correctly. Cross-team communication was enhanced, and they could see one another’s progress toward common goals. The ability to identify opportunities to swarm also began to emerge.
They identified a need for sprint planning when the team agreed they lacked a clear understanding of what they were working on and where they were going. We implemented a sprint plan format that works for them, which drove an understanding of the usefulness of capacity planning, the difference between story points and task estimates, and how to use each effectively.
So a method was never imposed, and the team discovered the benefits of Agile for themselves. All they needed to overcome their skepticism were the discipline of continuous improvement through data-driven retrospectives and trust in an experienced guide.
The team learned a lot on this journey as a stream of small, incremental changes improved performance, teamwork, and culture. To be effective, Agile solutions require a shared understanding. For that, we need metrics we agree are important, clear goals, and aligned expectations on what “good” means. We need management support and a shared understanding of goals, as well as a culture of trust, respect, risk-taking, and continuous improvement. Coaching an Agile-skeptical team demands a personalized approach that will work in that team’s unique environment, but eventually, it often leads to that “Aha!” moment we all seek.
Related Reading: Coaching Case Study Part 1
As a Trusted Advisor, NeuEon helps organizations reach their high-performance goals by applying our strategic experience to your situation. To learn more about how we can help develop a strategy for your Agile-skeptical teams or assist with other structural or cultural challenges, contact us today.