SDM Implementation Patterns: SDM in Denial
This article is part of the "Finding your SDM" series.
Jane and Dave are members of an Application Development Service that features two small agile teams. Officially, Jane is the Product Owner, while Dave is the Scrum Master for both teams.
Jane is seen by the larger organization as the visible face and entry point to the Service, engaging in fluid communication with various Business Units who are customers of the service. She gathers requests and requirements, and sets delivery commitments. Meanwhile, Dave manages the day-to-day activities required to fulfill those commitments.
Dave is a skilled Scrum Master, and has helped his two teams establish a reasonably well structured set of Scrum events (planning, stand-up, reviews and retros), but feels that some of Jane actions undermine the teams’ abilities to fulfill their commitments. For example, Jane often schedules "unplanned" refinement sessions, pulling selected team members to analyze new requests from the Business and make new commitments. She also tends to introduce new work during the sprint, and has a strong preference for assigning specific work items to particular team members.
Dave has noticed that Jane has been subtly (and not-so-sublty) interfering with team decisions, using her status in the organization to influence and override those decisions. During retrospectives, for example, she demands detailed information on the impact of improvement action items on "commitments you've made already," reminding everyone of the negative consequences of missing those commitments. During Sprint Planning, she challenges the team's point estimates with "effort estimates" produced by senior developers, and sets delivery date expectations according to the Business's expectations.
The Service includes two teams that are, in principle, independent. Dave would prefer if each team focuses on complete features end-to-end, something that Jane in principle agrees with. But Dave has noticed that Jane regularly splits work between the two teams so that it can proceed in parallel and “more efficiently”, which then later creates considerable dependencies between the two, which Jane expects Dave to manage to avoid “blockers”.
As a result, the Service is overburdened with work, and both team members and customers are growing dissatisfied. Jane blames Dave for his "inability to get the teams to get their act together," while Dave blames Jane for not giving the team the room to improve that they need. This situation has become increasingly frustrating for both parties.
A service comprising one or more teams, with a clearly identified Leader
The Leader is seen by the rest of the organization as the “entry” point to the service, and also usually its “spokesperson”
The Leader is involved in making delivery commitments, but later takes no ownership of establishing a process capable of delivering on those commitments.
Process decisions and day-to-day management of flow is often delegated to another member of the service (usually a senior member, or someone in a management role), but with limited authority.
The Leader considers to have some form of “veto power” on the decisions the rest of the service makes regarding their delivery process, resulting on considerable tampering and undermining of management actions.
In a Scrum context, it can happen that either the PO or the SM become the SDM in denial.
When the SM assumes the role of SDM in Denial, it’s not uncommon for teams to have a highly inwards-looking focus, where the improvement of the process and technical practices takes precedent over the delivery of Business Value. When the PO is the SDM in Denial (as it was the case in the story above), the situation tends to be the reverse.
What makes this pattern dysfunctional?
The dysfunctional nature of this configuration arises from the disconnect between the external interface of the service, specifically the making of customer commitments, and the decision-making process that determines the delivery process capable of fulfilling those commitments.
In the story, Jane made customer commitments with only a superficial understanding of the service delivery capability and followed an informal upstream process she had designed herself (“pulling people” for Business meetings and “grooming”, effort estimations in hours, deterministic planning of work assignments, etc). Although she publicly acknowledged the teams' autonomy to manage their process, in reality, her interference and tampering influenced those decisions, without taking any responsibility for the impact. When things invariably went wrong, she blamed the team, even though she had significantly influenced their decisions.
Jane could have resolved the situation in three ways:
1) Assume full responsibility for designing and explicitly managing the process end-to-end. She could have used her positional authority to dictate policy unilaterally or taken a more collaborative approach. Either way, she would have been seen as the responsible party for those decisions. The result is the “SDM at the Front Desk” configuration.
2) Establish a clear separation of responsibility with Dave, and leave all the downstream decisions to him. This would avoid interference and tampering, and Dave would become the responsible SDM across the commitment point. This would result in the "SRM/SDM Tandem" configuration.
3) Establish a collaborative relationship where they both own the process end-to-end and make decisions together (again, with choices about how unilateral or collaborative to be respect to all the other service members). They could reserve some types of decisions for each other, such as upstream for Jane and downstream for Dave, but always make decisions together and respect each other's decisions. This would result in the "SDM by Committee" configuration.