A Domain is an area within the overall organization. What is done and produced in that domain, and the value delivered, needs to serve the purpose of the overall organization. People’s understanding of the organization is limited, and the environment is always changing. Therefore, it’s essential for the delegator of a domain and other relevant stakeholders to regularly check in with the delegatee(s). They should take the time to evaluate and evolve both the design of the domain and how people account for it as their understanding of the domain deepens. People might do a great job of accounting for a domain the way it’s designed, but the design of the domain might be primitive or flawed. Conversely, even if the design of a domain is poor in the first iteration, it will improve over time through this process.
Over time, we discovered that simply talking together isn’t enough. Aside from how clear and relevant the purpose of the domain still is, we need to closely examine certain aspects of a domain and team or role:
Assess the Key Deliverables: Are they being delivered as agreed? If not, why? What’s preventing them?
Examine the Key Responsibilities: Are they being adequately addressed? If not, why? What’s preventing them?
Evaluate the Team Level OKRs and their progress: Is progress in line with their OKRs? What is hindering progress?
Review the Fundamental Responsibilities: Are they being addressed good enough for now? If not, what changes are needed? What support does the team need from the organization? This includes the personnel situation of the team - do they have the people with the required mindsets and skills?
In the above, they refers to either the Team or the Rolekeeper, the Delegatee(s).
We’re still exploring the best ways to conduct Domain reviews. This is our current approach, which we aim to refine over time. Join us in this endeavor and help us improve with each iteration.
In our company culture, teams don’t report to management nor does management dictate their tasks. Consequently, the review of a team’s output, their processes, their challenges, and their needs can be initiated from any side—even by another team. It’s always a collaborative effort.
The team has, through various means, an understanding of their work, their progress, their ways of working, their current impediments, and from this, how effectively they meet their team’s responsibilities and advance their team-level OKRs.
This should typically occur during internal team retrospectives and reviews of their work (for example in sprint reviews), and arise tension-based when something seems off, or when new opportunities emerge.
The concept is that the team, often with the support of a Scrum Master or Team Facilitator, continually understands their performance. This knowledge stems from working in iterations, reviewing work, conducting retrospectives on processes, and more. It also encompasses social elements, team dynamics, and the satisfaction levels of VSHNeers.
There should be someone who can grasp the broader perspective and represent the team to the Delegator or other teams. Typically, this is either the Product Owner focusing on the What the team does (reviewing work), or the Scrum Master or Team Facilitator focusing on How efficiently the team operates and what obstacles they face.
As the Delegator remains overall accountable for a team, they need to understand how effectively the team delivers on their purpose and identify areas for improvement. The Delegator might also perceive required changes within their domain, have inputs for prioritization, and need clarity on whether there are aspects the teams think should be modified or clarified. The goal is to stay in the loop, both to empower the team to create value and to ensure the team’s delivery on their purpose and deliverables. It’s essential for the business not to overlook issues when things don’t function as they should.
Periodically, the Delegator should check in with representatives of the Team (as mentioned above) to assess how things are progressing. This interaction can follow a simple format and should be documented for future reference. Essentially, it involves going over a list of topics and collaboratively deciding if everything is being managed well and identifying areas for improvement.
The Team comes up with a plan how to improve on the things that are not good enough yet. The Delegator plays a role in creating these plans, gives consent to them, and holds the team accountable over time to achieve the necessary improvements. This accountability is bidirectional; the Delegator also has responsibilities towards the Team, mainly in enabling them.
Anyone in any team or role might stumble across things that seem to not be how they should be (problem) or how they could be (opportunity). We don’t live in a culture where you simply report problems to management and hope for a resolution. We share the responsibility. The subject matter specialist, for example you in your team, who identifies the problem usually has deeper insight into it than the Delegator. Paired with the Delegator’s high-level context, a first iteration solution might be closer and simpler than you’d expect.
As a Delegator, approach the Team; or if you’re a Team member, consult with your peers and then approach the Delegator. Share what you’ve observed or experienced and describe the potential problem or opportunity.
Align on the topic, evaluate its relevance, urgency, and importance (we call this Consent to Driver), and then think about the next steps. This might entail a one-time action or a significant governance decision.
|It’s always a collaborative effort - you spot an issue, we collectively delve into it, and then we act. It begins with you.|
We review based on specific matters: a case, a problem, an opportunity, or a responsibility that hasn’t been addressed. We avoid vague feedback like "everything is bad; do something about it." While such statements might arise from frustration, the only constructive way forward is to dive deeper. We need to address each issue individually, get specific, and collaborate on potential solutions. Implement the changes, assess the outcomes, refine, and review again. In our intricate world, there isn’t a single solution to the sentiment "everything is bad."
Is the purpose of the domain still clear and relevant to the organization? Does it summarize what the team or rolekeeper actually do and why, can they identify with this purpose?
Are the expectations clear? Are they adequately fulfilled? If not, why? What obstacles are present?
Are they still relevant and clear? Does the team deliver as agreed upon? If not, why? What is preventing successful delivery?
Is there sufficient progress as outlined in the Objectives and Key Results (Os and KRs)? If not, what’s holding them back? How can we remove obstacles or enhance progress?
Is there sufficient progress to deliver the required features on the roadmap within the stipulated time? If not, what’s the barrier? How can we alleviate the constraints or boost progress?
Do they effectively address all of Fundamental Responsibilities good enough? If not, what needs improvement? What support do they need from the organization?
There isn’t a one-size-fits-all approach here. For a team of two, a simple work tracking mechanism might be enough, whereas a nine-member value stream team might adopt full-fledged Scrum to handle the Prioritization and Planning responsibility.
Refer to Anyone might have tensions anytime. It could be a task within your team where you were obstructed by another team, resulting in a delay in getting what you needed. It might be an instance where there’s a lack of clarity hindering progress, your team lacking specific skills, or perhaps someone departing from your team necessitating a hiring decision. Address any situation that either doesn’t arise or can’t wait for another scheduled review session.
This might be specified in your domain description, or the following defaults can serve as guidance. There’s no absolute right or wrong. As long as both the Delegator and Delegatees are informed and operations are satisfactory, all is well. If there’s no shared understanding of operational efficiency, it’s crucial to address it.
The team internally conducts a retro on the topics defined in What to review. The frequency and timing depend on the team’s cadence and iterations (such as sprints). Sprint reviews on your work and retrospectives on your processes usually occur at the right intervals. Often, this frequency suffices.
There might be more significant concerns or "elephants in the room" that demand dedicated retrospectives or other formats. Address these as often as necessary. Avoid conducting them without a genuine need.
If the two points above aren’t addressed, hosting a dedicated team internal retrospective before a review meeting with the Delegator might become essential. Otherwise, providing a comprehensive overview and effectively representing your team can be challenging.
Address tensions as they arise. Do not delay. Refer to Anyone might have tensions anytime.
Initiated by either the Delegator or Team, come together and discuss What to review.
While we don’t have a set guide for this yet, given that a role is a domain assigned to an individual, most of the guidelines in Review the Team and their Domain can be directly applied to role reviews.
One distinction is that, for instance, in a team internal role, your team acts as the Delegator for your role. Delegating and reviewing roles within your team align with your team’s Fundamental Responsibilities.