Gaining alignment on the goals and desired results of agile can influence the structure of a coaching group. When the coaching group structure begins to mimic the structure of the organization it is working to change, trust can decrease across the organization and visibility is reduced between the products’ outcomes and how things are implemented within teams. This report describes the issues of a siloed or hierarchical coaching model and how we shifted to a more product-based coaching approach.
1. INTRODUCTION
Companies of size require more than one agile coach for support, and how coaches are organized can help or hinder organizational change and influence the results of coaching. As agile coaches, our goal is to help organizations gain better business results by creating environments of trust and improving value delivery.
Skylar Watson is a software consultant and agile coach who implements high-value software to satisfy customers’ needs. He has worked in a wide range of industries and helped organizations detangle their large, unwieldy projects into manageable micro-services, develop cloud storage technologies to ensure data integrity for consumers, and write customer-facing mobile applications. Skylar works with both leadership and developers to assure the organization that their business outcomes are driving the transformation.
Allison Pollard is an agile coach and consultant who helps people discover their agile instincts and develop their coaching abilities. She has worked in companies both large and small to leave them with greater agility and an internal coaching capability that enables continuous improvement. Allison typically works with leaders to develop a change strategy and inspire trust, mentors Scrum Masters and agile coaches, and encourages teams to adopt agile practices that make sense. Allison facilitates conversations that produce new thinking and lead to actions for change at all levels of the organization.
During transformations, it’s common to bring in experienced agile coaches like Skylar and Allison to support change efforts. In this report, we share our experience working in a large organization undergoing an agile/DevOps transformation that started with a siloed coaching model and eventually shifted the coaching structure to focus on product outcomes as results. We will highlight some of the issues of coaching in a siloed structure, compare this approach to our experiences coaching in a product-based model, describe how we influenced shifting the coaching structure, and share our takeaways for future engagements.
2. CONWAY’S LAW AND THE SILOED COACHING STRUCTURE
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” —Melvin Conway [Conway].
When an organization is beginning an agile journey, it’s not uncommon to see a caravan of agile coaches eagerly trailing closely behind. Organizations indirectly influence the outcome of coaching based on their expectation of the coaches’ roles, and this influence isn’t necessarily indicative of the success or failure of the engagement. At first sight, everything is exciting, new, and sometimes even welcomed with opened arms. Once the coaches enter the engagement, they begin receiving their assignments–“You, ma’am, will work with our executive layer and now be known as an executive coach. You, sir, have some amazing technical chops and will now be known as a software craftsmanship coach.” And so on.
Agile coaches are commonly structured to focus on different parts of the organization based on their specialties (e.g., technical, business/program, executive), resulting in a model that mimics and reinforces the structure of the organization it is working to change. This separation of coaching roles and responsibilities creates a siloed structure that is a copy of the organization’s current communication structure: Conway’s Law is clearly in effect based on the current (rather than future) state.
Figure 1. Conway’s Law and Siloed Coaching
After the coaches have received their assignments, they travel this new unchartered land relatively alone. Coaches are spread across the organization to touch as many groups as possible; they may meet regularly (often based on their specialties) to compare findings and create tools to use with those being coached (new training offerings, templates, metric tracking systems, etc.). The work in progress for a coaching group structured this way is high and typically focused on framework adoption (“better Agile”) across the whole organization [Rothman]. Coaching results are typically measured by a number of people taught, team maturity assessments based on adherence to a framework, and perhaps a coaching satisfaction survey. With specialized coaches touching various parts of the organization, localized improvements may be achieved but a holistic view is lacking. Connecting the impact of agile coaching to business results is challenging in this model.
3. OUR SILOED COACHING EXPERIENCE
We were brought in as agile coaches to an agile/DevOps transformation that was underway in a large organization. As additional agile coaches were brought in to support the transformation, a siloed structure was established by the consulting company leading the effort. In the siloed coaching model, Skylar was reduced to being seen as a software development lead or possibly a software craftsmanship coach, and it was unclear where Allison fit in. Technical coaches were to talk to technical coaches, process coaches were to talk to process coaches, and so on–each coaching subgroup sharing perspectives and ideas within itself to figure out how to best transform within that area or specialty.
We should not have talked with one another since we had different coaching responsibilities, but we knew one another before this particular engagement and found value sharing what we were seeing with one another. We found ourselves hitting invisible boundaries in the organization and were deterred from talking to this group or that stakeholder because other coaches were responsible there. A divide between coaches surfaced and mirrored dysfunctions seen in the larger organization. Those who coached the executive tier were superior to those who coached the directors, and those coaches had a higher status than those who coached the business, and the technical coaches, well, they sat on the bottom of the totem pole. In a few conversations with other coaches in the organization, it was explicitly stated that we should stick to our specialty areas and not provide feedback on the overall coaching strategy. This divide and sense of power created an unfortunate misalignment on what transformation meant at the expense of the client while not making use of our collective experiences and wisdom as agile coaches.
Cracks began to appear in this approach as teams, managers and stakeholders received different coaching that unintentionally did not align together. Product owners were being taught Behavior Driven Development as their developers were focusing on microservice architectures. Pair programming was emphasized when business was learning about Objectives and Key Results (OKRs). Technical coaches would try to focus on test-driven development or continuous integration practices with developers and quickly realize that the backlog was not written in a way to support these techniques. New language was being used in pockets across the organization, and it was causing confusion. The connection between technical practices and business results was not communicated well across coaches, and executives grew concerned about teams not doing test-driven development and pair programming as they were led to believe these practices would solve quality issues and reduce operational costs. A few teams received significant training and coaching in these practices, which increased the cost of delay for their products and lowered their ROI as the development effort was exponentially larger than originally estimated. Business stakeholders grew increasingly frustrated by “IT’s transformation.”
Siloing agile coaches based on specialties meant the same conversation about a new way of working had to be conducted multiple times–once with the team, another time with IT management, and separately with business stakeholders–and created further delay of change as a shared understanding was being established in a piecemeal fashion. Lack of alignment on coaching outcomes resulted in good agile practices being introduced without clear value that created poor buy-in deterred learning of underlying principles, and potentially missed business results. Eventually, the hierarchy that emerged between the siloed coaches led to conflict within the group as coaches struggled to be effective in their roles; the coaches’ internal conflict created additional challenges for the organization in establishing a future vision and focusing on business outcomes. As agile coaches, we were frustrated with the roles we found ourselves in and the lack of success we were seeing for the client.
The financial cost of bringing in technical, business, and executive coaches was significant, and the results of the investment were (at best) mixed. Sponsors had relied on consultants to drive a successful transformation and now questioned how much to invest in coaching going forward. Replicating the success one product team proved to be harder with a second product team than following the same recipe of roles and practices. Trust up, down, and across the organization decreased as it became apparent that developers, management, and business stakeholders related to a given product were receiving different directions from their various agile coaches. We realized at this point the organization was resistant to transformation (whether it was agile, DevOps, or product), i.e, phase two of Virginia’s Satir Model of Change [Smith]. Recognizing this, we were able to navigate through this predicament with our unique shared perspective of the situation.
Figure 2. Virginia’s Satir Model of Change
Reflecting on our experiences in other organizations where we’d been successful, we discovered an important question that got us thinking about a different model to coaching:
Extreme programming talks about thin-slicing to deliver value early and often; why aren’t we coaching in a thin-slicing style that compliments the thing we’re trying to do (build trust and improve business results)?
4. AN ALTERNATIVE STRUCTURE – PRODUCT-BASED COACHING
“Technical infrastructure and practices have no purpose except to support competitive capabilities for business operations. Similarly, competitive capabilities cannot be supported without close support from technical staff and a technical environment tailored to the need. The two concerns cannot be treated separately.” —Technical Coaching for IT Organizational Transformation [Nicolette]
The agile coaches had been structured based on a set of assumptions of transformations in large organizations: one framework or set of practices would apply to all teams, every team would need to be coached to be successful, and the results would be measured by practice adoption or adherence to the framework. Seeing how an IT-led transformation caused turmoil with business stakeholders and made product management’s role harder in managing ROI as initial development costs grew, we went back to the original goal behind transformation: improving value delivery across products and increasing trust between business and IT.
In our other engagements, we would take a systems view to focus on practices with maximum impact to measurably improve teams and business outcomes by targeting coaching around specific products. Early conversations with a team may center on understanding what success for their product looks like and their current delivery capabilities. Conversations with managers and other stakeholders may further clarify the product goals and desired benefits of adopting agile [Larsen]. We would evaluate where the team’s delivery bottleneck is and determine what practices or techniques may be helpful to introduce and support through training, mentoring, and coaching. Our emphasis would be on identifying what is preventing the team from delivering more value for the product and teaching techniques that solve that problem.
Figure 3. Product Coaching
At the beginning of a previous engagement, Skylar had been a prisoner to the daunting hierarchical model. He navigated this dangerous terrain by building trust and explaining how technical practices would improve business results; he was gifted with the ability to coach as he saw fit as a result. Equipped with this new ability and the shackles of hierarchy removed, Skylar worked with leadership to truly understand their desired outcomes and how they’d like their organization to improve. Although this new way of working was new and appeared wizard-like, it was observed that teams started to work on things that mattered to the organization. This inspired Skylar and Allison on how to help shift the coaching model away from the siloed, hierarchical structure.
5. CHANGING THE COACHING STRUCTURE
We knew something had to change. We had struggled to feel effective as agile coaches with our hands tied in the siloed model and couldn’t bear to stand by whilst our client was not getting the benefits of agile they desired from transformation. To change the coaching model, a multi-faceted approach was taken. To start the coaching model shift, we focused on one product and partnered with trusted internal leaders to build relationships with other stakeholders to hear their concerns and understand the product goals. We then helped the team connect the value to the practices being introduced.
5.1 Building Relationships
To better understand and empathize with the organization’s needs, we knew we needed to spend more time with certain stakeholders. Skylar scheduled several (almost weekly) happy hours with management from both business and IT. Off-hours and offsite conversations helped Skylar and Allison better understand the true frustrations they had with transformation and what was happening in the organization. In the office, we attended status meetings where we knew these stakeholders would be present; it became more apparent to us that the siloed coaching structure had created a great deal of miscommunication. The business partners thought the focus of the development team was something completely different than what it really was. The truth was being lost in translation–a game of telephone was going on between the coaches and everyone involved. Our presence in these meetings and openness about what we were seeing happen at the team, program, and management levels acted as the foreign element that quickly put the organization into phase three, chaos.
5.2 Understanding Product Goals
By having conversations and starting with the stakeholders for one product, we allowed them to define their expectations and goals of the product. The product goals could later be used to guide what practices might be taught and coached with the product team.
Skylar centered on one particular product to clarify the outcomes desired. Initial conversations with stakeholders referenced increasing revenue, matching functionality provided by competitors, creating a better user experience and minimizing customer complaints, and improving operational costs. Ultimately though, stakeholders were frustrated that nothing had gone to production yet despite the significant development costs invested so far. Development had started many months before Skylar was brought in as an agile coach, and stakeholders were struggling to see when a release would be possible. Knowing this, Skylar focused on finding a way for the team to deploy something of value as early as possible and creating a simple real-time dashboard to visualize the results.
Sensing the other products across the organization might have unclear goals, Allison facilitated a workshop with representatives from six teams (including the one Skylar was coaching). The first half of the workshop had the teams posting on the wall the work they would likely be doing over the next month and a half. Themes of technical upgrades or technology changes were evident across them and interspersed with items requested by business to enhance functionality or improve user experience. Next was visualizing the other groups or teams that they were dependent on to deliver the work. Yarn was hung this way and that, first between the work items of the six teams present and then with groups outside of the workshop. The yarn highlighted the significant number of handoffs, approvals, and coordination points needed to deliver value. The second half of the workshop looked at the product OKRs–the vision or objective of the product and the key results or metrics that business cared about. Webpages, backend systems, and a collection of user capabilities were all being called products but had unclear charters. One goal of the transformation was to create autonomous product teams so they are able to test and deploy independently, and this activity showed much more coaching would be needed to make team autonomy and product ownership a reality.
5.3 Connecting Practices to Results
Those definitions of product goals helped us introduce and coach agile as an implementation for our coaching rather than treat agile as a process–we focused on communicating the connection between practices and outcomes. Allison facilitated workshops using the Agile FluencyTM Game with a new product development team and later with IT management to clarify team practices that might be introduced and their potential benefits. The product development team gained confidence in having conversations about what they might be learning from an agile coach and identified what practices seemed most important to them. Management realized that their teams’ current struggle to balance addressing technical debt and delivering new business functionality was harder than the game simulation, and the teams would need more help than learning a few new techniques in order to be successful.
By valuing “Individuals and interactions over process and tools,” Skylar could share how there was more than one way to help the team deliver value better for their product. A technique used to help transform stakeholders’ way of thinking was to start referring to the product’s OKRs when talking about work-in-progress and feature requirements. This helped connect business value to how software is implemented. As the organization started to pivot to this product-based approach, there were still a few skeptical to a different way of coaching. What value is there in having a technical coach communicating to our business partners? To help answer this question, Skylar created a mind-map to illustrate the conversations he’d had recently.
He explained that the conversations taking place with the business were around the flow of work coming into the team. What is being brought to the team? If the team is presented with a solution and not a problem needing to be solved, then it’s often tricky to thin-slice that user story (because it’s already written as a complete solution.) Being unable to thin-slice a story can create serious issues when you’re trying to test-drive the code. This is captured in the lower left branch of the mindmap.
There were also conversations with the business around the stability of certain products (middle left branch in the mindmap). Without directly understanding the business’s definition of stability, it becomes difficult to understand the cause of the stability concern. The team was defined as having a stability issue resulting from its presence of defects, rate of outages, and the deployment pipeline. The business defined a defect as something reported in production having customer impact. In all of the cases reported, there was zero automated test-coverage surrounding said functionality. Due to the lack of unit, integration, and contract testing, this seemed like a clear coaching opportunity for Skylar to work with the team to improve.
6. A NEW MODEL – FORMATION OF THE CATALYST COACHING TEAM
The previous siloed model was so fundamentally flawed in its implementation that ‘experimenting’ with a product coaching model was a breath of fresh air. Highlighting team wins in terms of product results got management’s attention and gave them the confidence to change the hierarchical coaching model and reduce the coaching staff. Having a hierarchical structure based on coaching specialties reduced visibility between the products’ outcomes and how practices were implemented within the teams to get meaningful results for the organization. Clearer organizational results of increased delivery capabilities and business value can be achieved when coaches focus on helping teams meet their product goals rather than adherence to a set of practices or framework adoption.
Eventually, the organization created an agile transformation office called the Catalyst Team; this new group is being run by the client and not any consulting company trying to help them “transform.” It’s a small group that is helping the organization establish and work towards a common vision of the future. Already this coaching group has gained insight into what matters most to the organization and is committed to learning and unlearning how to enable the organization to deliver value better. We are excited that the organization now owns its transformation and agile coaches are better positioned to serve the organization. It was a long journey, and in retrospect, if we had a cohesive transformation office from the beginning, a lot of the tension and resistance could have been reduced by allowing the client to make decisions and learn from their own struggles.
7. WHAT WE LEARNED
We learned several important lessons throughout this experience, like being aware of clients expectations going into engagements, establishing a strong trusted relationship with an internal person at the client, and understanding the abilities of the other coaches to help define a coaching strategy. These takeaways influence how we approach future coaching engagements, and Allison has even incorporated them into Improving’s Agile Coaching Field Guide for its consultants.
7.1 Client Expectations
Throughout this journey, we learned to become more aware of how leadership expects us to work within their organizations. What is their goal behind adopting agile, and how would they measure success? Do they expect a siloed way of coaching? Are they willing to try experiments? Understanding these expectations going into this engagement could have helped us steer the conversation sooner or perhaps given us the opportunity to decide if the engagement was even a right fit for us. Noticing differences between how the organization measures success and how we might measure success as agile coaches would have created an opportunity for dialogue so we could become better aligned from the start.
As agile coaches, we are now more wary of IT-driven transformation efforts and want to partner with business early. Losing sight of the organization’s pain points and how “agile” can address them can be costly for an organization. The initial coaching approach helped show the organization that you can’t always do technical work without having conversations about why that work needs to be done; sometimes conversations need to take place with business stakeholders or management that may be perceived as an “agile process” but help connect practices to results. Our client ultimately learned there’s a fine line between software craftsmanship coaching and coaching to an agile process.
We also learned to have safety amongst the agile coaches. Some people get caught up in a hierarchical power model or handle stress poorly when the coaching work in progress is high. The perceived power and weight of the transformation was too much for some coaches to bear, and they started to micromanage their peers and even disrespected the client’s management. It’s unfortunate, but the client learned sometimes it’s better to excuse these individuals to help ensure a safe environment for everyone else around. We learned the value of being able to trust our coaching peers and speaking openly with one another.
7.2 Client Relationships
At the end of the day, the biggest factor for success was finding people in the organization that really care. We were fortunate enough to find someone who had a good reputation that helped schedule monthly delivery transformation meetups, connected us with the right people for problems, helped schedule weekly happy hours and encourage stakeholders to come, and did a number of other things that helped lead to a successful mindset shift. She was the organizational ‘nudger’ that improved the transformation through hallway conversations and an unofficial coaching role.
We found for us to successfully engage with teams, we needed to have the team members pull us in rather than pushing ourselves onto the team. Learning about the team members, their current state, and product goals made it easier to get their buy-in. The ability to gain permission from a team to coach goes a long way in building internal credibility for future coaching within that organization.
7.3 Coaching Abilities
It was observed that not all coaches can speak to all levels of an organization or parts of a transformation. We’ve found this was because of a few reasons: either that coach wasn’t comfortable speaking to higher levels of management and maybe wanted to keep a focus on technical team improvement, or they hadn’t yet acquired the ability to articulate their message in ways management could understand it. There’s the added challenge of knowing what business or product practices to introduce and how to coach them. When we’ve run into this situation, the coaches started pairing with others that helped compliment the skills they were lacking. Bringing agile coaches together enables them to learn one another’s strengths so they can recognize when pairing may be beneficial, and it also creates an opportunity to understand a more holistic view of the organization by sharing what they are each seeing. With a broader understanding of the organization’s current pain points, the coaches can adapt or pivot their approach to enable change.
8. ACKNOWLEDGEMENTS
We would like to thank Tim Ottinger (Agile Otter) for introducing us to each other; it was a brief introduction that had a major impact on our ability to help an organization get the results it desired from coaching. Special thanks to our trusted partners at our client organization who helped provide the vision and support needed for the transformation to pivot after its bumpy journey. You inspired us to keep going and enabled us to better serve your organization. And thank you to our Agile 2019 shepherd, Nanette Brown, who provided us feedback on this paper so our learnings could be shared broadly to help others.
REFERENCES
Conway, Melvin E. “How Do Committees Invent?”, http://www.melconway.com/research/committees.html
Smith, Steven M. “The Satir Change Model”, https://stevenmsmith.com/ar-satir-change-model/
Larsen, Diana & James Shore. “The Agile Fluency Model”, https://martinfowler.com/articles/agileFluency.html#ChooseYourZone
Rothman, Johanna. “Agile Coaching Is Not the Goal”, https://www.jrothman.com/mpd/2018/12/agile-coaching-is-not-the-goal/
Nicolette, Dave. “Technical Coaching for IT Organizational Transformation” Lean Pub https://leanpub.com/technical-coaching
