2017 Scrum Coaching Retreat in Kiev is in the books!!! The event has brought together a few dozens of agile coaches and trainers from nearby and far away.
The participants came from different backgrounds and focus areas but due to everyone’s extensive experience in self-organization and self-management, got the show on the road very quickly. After a short round of self-intros, each participant introduced a few topics that they wanted to discuss. By using a combination of dot-voting and affinity clustering techniques, the group came up with a handful of key topics that everyone wanted to deep dive into. The group broke up into four teams, with each team picking one high-priority topic – to be worked on in consecutive three (3) sprints.
The team I joined (“Happy 7”) picked up the topic “How to influence decisions of senior management directly, from the bottom of organizational pyramid”. The team consisted of experienced ScrumMasters, Team-level and Enterprise-level coaches.
The problem statement that defined our team’s effort was:
“There are so many instances, of challenges and obstacles that teams face, are not being heard at the top of a food chain. And even when they are heard, often, original messages get distorted and lose urgency, as they travel up through multiple “translational” layers. What can be done to fix this problem? What techniques could be used to effectively segregate impediments that are local and can be resolved by teams and the ones that are systemic/organizational – and must be aggressively escalated upward?”
The problem above has direct dependency on organizational design, specifically, on its thickness: the number of organizational layers between working teams (on one hand) and senior leadership/paying customers (on the other) – is a well-recognized challenge today.
Our working group has identified the following organizational design scenarios that define dynamics and human interaction in modern Product Development:
- Development teams and Product Owner belong to the same organization and end-Customer is positioned internally
- Development teams and Product Owner belong to the same organization and end-Customer is positioned externally
- Development teams represent Vendor-company and Product Owner represents Client-company and relationships between Vendor and Client are based on:
- Out-staffing model – when a vendor provides human assets (developers) that are then owned by a customer, from management perspective, whereas legal ownership (e.g. insurance, taxes) is still by a vendor
- Out-sourcing model – when an entire project gets outsourced to a vendor and a paying customer has no or minimal interaction directly with human assets (developers) that do work (most of communication flows through Engagement Management)
Interestingly, since many of our working group members had a lot of experience with #3 option above, the primary focus of our discussion was about how to bring closer senior leadership of paying customers and agile teams of delivering vendors, closer together, despite multiple “anti-agile” organizational layers that frequently reside in-between the former and the latter.
The ultimate result of our brainstorming was the invention of a non-commercial, collaborative game that was given the name of Influence Poker.
Our game’s purpose was:
- To identify challenges that delivery teams often face
- To classify challenges, based on origin, severity and implications
- To discuss potential ways of resolving and/or escalating challenges
- To ensure resolution ownership and transparency on its progress
Note: The initial contributors to the game creation were: Serhiy Lvov, Kiryl Baranoshnik, Artem Bykovets, Alexander Karitsky, Mark Summers, Jonas Mann and Gene Gendel .
The most serious organizational design challenge, when a paying customer engages with a vendor-company, is seen with an out-sourcing model. Here, no matter how agile/robust technology teams are, their ability to deliver effectively is hindered by:
- Involvement of Delivery Manager (usually, placed on a client site) who owns a relationship with a customer, serves as a single filter-channel of communication between a customer and teams, makes commitments and furnishes progress reporting on behalf of teams. The same person also streamlines feedback from a customer back to teams and frequently assigns work to team members. This is usually accompanied by micro-management and command and control behavior. The situation can be further worsened by the presence of Vendor Management function (customer side) that enforces SLAs, SOWs and other formal contracts between a customer and vendor: this just adds additional tension to a relationship and moves further apart end-customers and delivery teams.
- Weakening of Product Owner role – the importance of this critical Scrum role gets downplayed, because a customer company no longer sees value in direct communication with technology teams. Instead, Delivery Manager is treated as a single person, responsible for project delivery. This dramatically narrows all communication media that are used in Scrum (holding events, sharing artifacts).
The above two challenges are inter-related through a positive feedback loop: the less disengaged Product Owner becomes, the more pivotal the role of Delivery Manager becomes. The opposite is true too: strengthening the role of Delivery Manager, leads to further “excusing” Product Owner from stepping into the game, as Scrum requires. This is a viscous, de-stabilizing loop that continuously weakens Scrum.
Please, look out for the Influence Poker.first official release that is coming soon! It may greatly help your teams visualize their organizational problems and discover potential workable solutions.
Note: For attendees and participants, here are additional shortcuts: