Real Scrum requires significant organizational redesign. I have seen two common settings to pilot Scrum: 1) project group and 2) component team. As those are existing structures, it is convenient to just use them. However, without organizational redesign, you would end up with fake Scrum.
In this article, we focus on the organizational setting with component teams, and discuss two alternatives before we are ready for organizational redesign to adopt real Scrum.
Here is the starting point.
Let me clarify some terms I use here:
Features are requirements for the product. They are customer centric and associated with business value.
Component requirements are requirements for the component. They are actually tasks from the perspective of the product.
Component tasks are internal tasks in the component.
Traditionally, TL is responsible for the component team and is held accountable for delivery of the component work.
Fake Scrum with team PO
This is what usually happens while adopting Scrum for a component team.
Of course we introduce the roles of SM and PO, right? As there used to be one TL, I have seen two common arrangements:
TL becomes the PO, who is a team PO as well as a fake PO, as he is clearly not responsible for maximizing value of the product. Another person is found to fill the SM role.
TL becomes the SM. Another person is found to fill the team PO role.
Usually, regardless of whether the TL becomes the PO or SM, the delivery accountability is still kept with the TL.
Those are good progress. However, in both cases, focus on the component misses the most important point behind real Scrum – maximizing the value through inspection and adaptation based on features and whole product perspective. Therefore, this is fake Scrum with a team PO.
Real “Scrum” with TL
An alternative I would recommend is to keep the TL role, but transform the role to 1) do the fake Scrum on the component, 2) shift focus to the product and features, and 3) advocate for organizational redesign.
Let me elaborate:
Do fake Scrum on the component
consolidate all component work and prioritize (i.e. what the fake PO does)
coach the team to self-organize for delivering the component (i.e. what the SM does)
Shift focus to the product and features
connect component work to the product and features
connect component team to the real PO
coach team to self-organize with other component teams in delivering features
coach the real PO to inspect & adapt on the product
Advocate for organizational redesign
prepare with cross-learning and technical excellence
spread the knowledge and experience on organizational redesign towards feature teams
This approach better follows big ideas behind Scrum, even though Scrum roles are missing. Therefore, this is the real “Scrum” with TL.
Only after the organizational redesign and creation of feature teams, the team would work directly with the real PO, and it would take end-to-end responsibility for feature delivery. Eventually, the TL would be replaced by a SM – a coaching role not responsible for the delivery. That would be the real Scrum.
End note
In fact, TL working this way is well defined in the book Leading Self-Directed Work Teams. It describes the TL role as a boundary manager. Please, do not introduce team PO for a component team, TL will do.
In the first part of this blog series, I explained how to identify the organizational elements to include in your product definition. In this blog, I explain how you can refine your product definition to organize into effective cross-functional teams.
Some elements are more equal than others
Below you can see a simplified view of the organizational elements at one of my customers.
We discovered that some organizational elements are required more than others to develop product features. The more often a particular element is required, the stronger the dependency. We visualised the strength of the dependencies with a heat map – see the figure below for an anonymised simplified example.
The y-axis shows product features. The x-axis shows the organizational elements. A green area indicates an element that is needed to deliver the feature
The elements that heat up the most indicate the strength of the dependency – these are the hotspots. Note that the WEB element is needed in 28% of the time to develop product features, the APP 20% of the time, while Legal is required only 7%.
NOTE:Avoid focusing too much on the percentages. This is not exact science, but rather a guide to help you move forward. Other than percentages I have also successfully used categories to estimate the strength of the dependencies like: Seldom, Now and Then, Frequent.
When all the teams can pick up any work that comes in and deliver it completely to “done”, you have maximum adaptability. That would mean that each team has the skills to cover the whole heat map. Unfortunately, this was not the case for us. There were just too many technologies and domain knowledge for the teams to comprehend. Also, there is value in team specialisation. The solution was for teams to specialise in the customer domain first, and then to learn about other product domains as needed.
Learning can take many months or even years, and in the meantime, we needed to determine how to start. Which organisational elements should the teams cover first and which shall we add later? This decision depends upon the strength and type of the dependencies.
Find the balance between adaptability and speed
When a team can work on all components but only one feature, a team covers a complete row, as drawn in the figure below. Such a team has no external dependencies; hence they probably deliver fast. On the other hand, when a team covers all features but only one component, it covers a complete column in the heatmap. Such a team can work on all feature-parts; hence they can adapt to all work that comes in, but cannot deliver end-to-end.
Therefore, the size of the heat map area that a team covers strongly determines its
feature delivery speed
flexibility to pick up work from the product backlog
Our challenge was to find the optimal balance between speed and adaptability in our 11 team context, and that depended upon several variables:
The teams’ cognitive capacity. When teams specialise in a customer domain they can still work on customer features without needing to understand the other customer domains of the product.
The type of dependencies between the elements. This helps the teams determine which organizational elements to cover first and which later.
Specialise in the Customer Domain
Our product was a large insurance system. We used interviews and questionnaires to determine where users spend most of their time when using the product. It turned out that there were a couple of main groups of users. (For this blog, I just use 2 groups: “Claims” and “Evaluation” and call them “red” and “yellow”.) Some users mostly used the red-colored features – red area – while the other group primarily used the yellow-colored features – yellow area. The orange features were used by both groups of users – they overlap or intersect both red and yellow areas.
The next step was to find the most significant heat map area that the teams could cover.
The type of dependencies between the elements
We used the following rules to decide which elements to include from the beginning and which to add later.
Rule 1 – Contain reciprocal dependencies within one Value Area: The work of one team is input for another team and vice-versa, and there is uncertainty about how to accomplish the task, which makes frequent alignment necessary.
Rule 2 – Ensure sequential dependencies between Value Areas with iterative planning when one team’s work is dependent upon the work done by another team. Applicable to work with low uncertainty and predictable work.
Rule 3 – Manage pooled dependencies across Teams and Value Areas with simple coordination rules. For example, sharing of a single test environment, or dependency on a person with a scarce skill.
Below you can see an example result for the red Value Area.
The Web, App, Siebel, Portal components are used often together and their interdependencies are reciprocal. The teams in the red area decided that they would need to cover at least these elements.
Furthermore, you can see that the area has a pooled interdependency with Legal, and that it is a relatively strong dependency of 14%. The weakest interdependency is with the Sales Force. We choose not to include Sales Force initially and only add it when the teams mastered the other elements. Legal was also not included because it was a pooled dependency.
The yellow Value Area below has a different set of dependencies.
The teams decided that they needed to cover at least the APP, Sales Force, Siebel and WEB components.
For this area, Legal is not needed at all. And there is a weak sequential dependency on Portal. We decided to not include Portal in the first step. In the exceptional case that a feature needed a change in Portal the teams would coordinate with the red-area to get it done. We also used these as opportunities to learn more about Portal.
How to handle features in the intersecting orange area? A solution is to decide based on the feature itself.
For example, F10 could be picked up by either the red or yellow area. F18 requires only APP and can be picked up by the yellow area. The only complicated feature is F11. It requires knowledge of both Sales Force and Portal which neither the red or yellow area possess. So, how to handle this one? Well…, remember the golden rule of Scrum Mastership: “Always ask the team.”
Final Result
The product definition includes all elements, but we choose to not include Legal skills in any of the teams from the start. Why? Because it is a pooled and weak dependency. Also, the teams felt they were not yet able to cover more skills right from the start. Instead, Legal became the next activity to include in their Definition Of Done.
In the infrequent case when a feature requiring Legal skills would appear on top of the Product Backlog, we would plan for that by working together with Legal in refinement events and during the Sprint.
During Sprint Planning, the team that selected that feature would then coordinate to work together with someone from Legal to get the feature done. Preferably, the Legal person(s) would also use the opportunity to teach the team so that they understood a little bit more about Legal at the end of the Sprint. When a team keeps selecting to work on features with the Legal part, eventually they would learn enough to add Legal to their Definition Of Done. Bas Vodde calls this accidental specialization.
NOTE:Not all teams need to know everything about all elements in the Product Definition right from the start. Teams can have their own speciality as long as all teams as a group can pick up any element from the top of the Product Backlog.
This is the first part of a blog series about product definition in LeSS.
In large product development, teams tend to work on just a part of the real product. The part – a narrow product definition – is often a component or a specific activity in the development process; it is not a product.
A narrow product definition creates all kinds of problems for a product group. It locally optimizes the performance of the teams at the cost of the performance of the group. The causal loop diagram (CLD) below explains this dynamic. (See this blog for a quick overview of CLD notation.)
Narrow product definitions make it more likely to have specialized teams that only work in their silo, which in turn decreases adaptability and speed of learning at the overall product level. Broader product definitions lead to teams that cover multiple components and activities that together address the needs of end-users.
What is a Product Definition?
A commonly used definition of a product is “something that is made to be sold.” The product provides a way of making a profit.
A product has users who are people.
A product provides features to those users that address their needs and problems.
A product has a business model, revenue stream, independent profit & loss, or return on investment.
A product is developed and sustained by a system of people, components, and processes.
The product definition determines what organizational elements (people, components, processes, and systems) are needed to develop and run the product. If your product is Mortgages, then your Product Owner is probably a business person who understands the market. The Product Backlog might have items like “Loan offers to small businesses,” and the users are likely to be paying customers. Mortgages is a broad product definition when it contains all the parts needed to produce an end-to-end solution to the end customer.
How To Define the Product?
The product definition includes multiple components, activities, and provides solutions to the needs and problems of end-users. You can define your product using the following two steps:
Step 1 – Identify the required organization elements to develop and sustain the product.
You start with the elements – your component teams – you currently call products, the activities, the people, and the processes you have presently in your group. You then study how the work works for your group so that you understand the types of dependencies that exist to develop, maintain, and sustain your product.
The typical steps to achieve this are:
Identify some typical external end-users of your group.
Identify some regular needs these end-users want to be addressed or tasks they need to complete.
Identify some features for each of the users that they consume to address their needs or perform their jobs.
Identify the boundaries through which the users consume the features to satisfy their needs/problems etc. (for example a Browser, App, API, Connector or Helpdesk)
Next, you want to identify the organizational elements that are needed to produce the feature and satisfy the customer. You do that by studying how each feature flows through your organization into the hands of the customer. You start at the boundaries and work through the components, systems, people, and processes until completion.
Step 2 – Clarify the revenue streams
A proper product definition identifies a group broad enough so that it includes revenue streams. Without it, the teams in the group will likely be disconnected from market concerns where the real value lies, and instead, the teams focus only on the part of the whole product.
In this step we ask the question: Do the identified organizational elements produce a product that generates revenue for the organization? Or are there missing parts to do so? The way we prefer is to find answers to the following questions:
How do the elements together generate cash? For example, is the product definition able to have usage fees? Asset sales? Subscription fees?, Licensing? If not, what would need to be added to the product definition?
Does the product definition have an independent profit & loss? If not, what organizational elements are missing?
What business KPIs can you assign to the product definition? For example, can you assign it an increase in gross income? An increase in new customers? Customer satisfaction?
If you cannot give a meaningful answer to all of the questions above, then your product definition is too narrow, and you would need to expand it.
Product definition completed?
At this point, you identified a set of organizational elements that together produce value for end-users and have an independent revenue stream. The result typically includes tens of components, skills, activities, and it can involve hundreds of people in total.
With such a large group, you may ask yourself, “How can I create effective cross-functional teams that include all these capabilities?” In the case of more than around ten teams, we recommend to organize the teams among Value Areas and contain dependencies per area.
A Systems modeling technique to visualize and act on deeply entrenched systemic issues.
Everyone carries a model, fuzzy as it may be, a map of sorts to navigate reality as perceived. As team members we have expectations from each other. This internal picture of our expectations, and reasons, and emotions, and all the mess that is being human is our mental model. The differences between what actually happens and what we expected it to be, reinforces our mental models or alters it. Learners are able to update their mental models more often, and thus adjust their actions and expectations with ever emerging reality.
I find that curiosity is the doorway to learning. Accumulation of knowledge on the other hand is founded on the mistaken belief that knowing about a thing is the same as knowing the thing.
By learning, I do not mean accumulation of knowledge or a collection of jargon to impress your colleagues. By learning, I mean understanding that enables you to take actionable steps in a very real practical sense.
Here I want to share an actionable technique that I have used to assist teams in learning together. But first, let’s acknowledge that everybody has a blind spot. No one at any time, not even once, can be all knowing.
Everybody has a blind spot
Learning never stops, and this is the humbling truth. Mental models are at best approximations of reality, and can never be perfect.
As a hobby motorcycle rider, I constantly update my ‘model’ by continuously orienting myself to [sic]changes[sic] in road conditions, weather, other drivers on the road. We make up for lack of accuracy in our mental models by noticing these changes and adjust accordingly.
On the other hand, developing a perfect model will require that the rider account for every breeze, every pebble in order to develop an accurate picture of the situation at hand. And then take the next course of action. This as we know is analysis-paralysis. This affliction is detectable when people mistake knowledge about a thing, to knowledge of the thing. People who know about motorcycle maintenance talk more and do less, whereas actual mechanics talk less and do more.
We do not want to be bogged down with minutia, but act in response to emerging reality. A rider observes to validate or update their understanding of ground conditions. Additionally the rider continually scans/reorients to collect a good enough picture of emerging reality.
Never let your eyes fix on an object for more than two second, keep looking around. – Motorcycle rider manual.
Intense periods of concentrations may improve your resolution, but it comes at the risk of increasing your overall blind spot. If you have driven under snowy conditions, you know about the perils of tunnel vision. Focusing to appreciate each unique snowflake is not a recommended way to force an invitation to meet with your maker.
Without further ado, here are the steps to facilitation.
Step 1: I wonder…
There is no learning without curiosity. So what are you curious about? I find that framing your curiosity as “I wonder…” opens people up to alternative possibilities, and perhaps awakes our inner playful inquisitive spark. Following are some examples:
I wonder why my team does not take on challenging work, or increase their productivity.
I wonder why management focuses on metrics so much?
I wonder why my team is unable to release software more often?
Step 2: Just talk
Bring your curiosity to your team, and check for interest in exploring this topic further. Give up on knowing, and you will invite others to wonder together with you. ‘Just talk’ is best practiced as a relaxed conversation with your team members.
Remember everybody has blind spots. No one, not even you will have complete understanding. By ‘just talking’, you and the team members are exploring various factors that surround a topic.
We will use the first statement as an example for illustration.
I wonder why my team does not take on challenging work, or increase their productivity.
A brief 5-10 minute conversation within your team may yield the following related factors.
Fig. 1: Brainstorm related factors
Related factors are often the ones that are perceived to change (increase or decrease) along with the topic at hand.
For example, in your ‘just talk’ session - you may have a talk about the situation when following a certain process step imposed by higher management leads to misunderstandings in team processes. You may capture this as two related factors “higher management process mandates” and “team understanding of management processes”, or as I have expressed above “team has autonomy over processes”. Fewer factors is better, and best not to get bogged down with wordsmithing.
CAUTION: These are by no means the only possible factors. And in your discussions within your team there will very likely be a different set of factors.
Within a team, each member has their own blind spots, but collectively the diversity within a cross-functional team will allow team members to cover for each other’s gaps in understanding.
Step 3: Sensitivity check
Expect that different members in the team will have different degrees of sensitivities, and therefore you may find more than a handful of factors.
While it may be tempting to acknowledge everyone’s sensitivities on this matter, trying to consider too many factors at once will lead to analysis-paralysis. And our goal in this exercise is to be actionable
CAUTION: From the superset of related factors, select no more than eight factors. Fewer than four and you may not have considered the diversity of factors, and more than eight (or perhaps ten) and your collective efforts will remain stuck in analysis-paralysis.
As a team you can collectively agree on top eight factors, or use a prioritizing technique, such as dot-voting, to select factors that closely correlate with the subject of your team’s curiosity.
In our example, we have selected the following eight factors.
Fig. 2: Selected factors
Step 4: Around the clock
Organize your items on a physical/digital whiteboard so that items together form a large enough circle, with the items arranged roughly on the hour positions of a clock.
Fig. 3: Circle arrangement
This step is best performed by randomly selecting one of the eight or so factors, and placing these randomly on the hour positions. Avoid unnecessary analysis.
Step 5: Select a facilitator
I strongly recommend that you have a facilitator for this step. During the next analysis step, your team will dive into the relationship between selected factors.
A dedicated facilitator will
prevent the whole group from getting too bogged down into the details.
move the team along, and avoid tunneling.
The facilitators primary concern is to avoid analysis-paralysis, which merely leads to accumulation of knowledge, but no practical understanding that enables action.
The facilitator focuses on group interactions for remaining steps, and does not contribute in any other way.
Step 6: Simple cause and effect (Analysis)
The facilitator will invite team members to discuss relationships between sticky notes. The facilitator invites discussion within the team by posing a question:
“Is it because of [cause] therefore [effect] ?”
This is by far the most tedious step in this process, and takes a while to get comfortable with. As a facilitator you will need to use this phrase over and over again. By repeating the same sentence structure you are refraining from undue influence, and establishing a pattern for others to know when you are inviting discussion to consider the next relationship.
Round and around, relationships in a merry go round.
(a) Is there a cause-effect relationship? and which way?
Starting with the first sticky note item at the 12 O’clock position, the facilitator will ask the rest of the team to check for simple cause & effect relationships:
“Is it becausepeople feel empoweredtherefore we have inspiring goals/vision ?”
AND then, after a brief pause check for causality in reverse:
“Is it because ofinspiring goals/visionthereforepeople feel empowered ?”
By checking for directionality of cause and effect in both ways, your team may quickly discover the nature of the relationship between the two sticky notes (factors)
- OR -
conclude that these factors are not directly influencing each other.
In the example above your team may agree that inspiring goals/vision make them feel empowered.
(b) Is there a dominant direction?
Now keeping the same sticky note at 12 O’clock position as the anchor item, and moving clockwise, the facilitator will ask the team to check for relationship between the anchor item and the next in line factor:
“Is it becausepeople feel empoweredthereforeincrease in team productivity ?”
AND then, after a brief pause check for causality in reverse:
“Is it because ofincrease in team productivitythereforepeople feel empowered ?”
While the team is analyzing the relations, the facilitator must avoid getting dragged into their considerations. The facilitators role is to prevent analysis-paralysis from taking hold. While facilitating, ask the team members to pick one directionality as dominant.
DO NOT ALLOW FOR A RELATIONSHIP BETWEEN FACTORS TO BE BIDIRECTIONAL.
I say this with extra emphasis, not because bi-directional relationships do not exist, but because opening the exercise to also consider bi-directionality will confuse matters in the long run, and will get in the way of being actionable.
So when your group thinks that there is bi-directional relationship between two factors, pick one direction that is more likely or truer for your specific case.
In the example above, your team may find that when people feel empowered the productivity of the team improves as the more dominant relationship. Although it may also be true that when the team is productively humming, its sense of empowerment improves.
Fig. 4: Cause and effect directionality
(c) Round robin
Keeping your 12 O’clock factor as the anchor, check for cause-effect relationship with remaining factors. Once your team has considered the relationship between the anchor factor “people feel empowered” with remaining factors, you will go through the same process all over again.
This time, you will move clockwise and select the factor at 2 O’clock position to be the anchor item. Since we have discussed the relation between the new anchor and the previous anchor, we will have one less relationship to discuss.
After cycling through anchor #2, you will select the next in line anchor moving methodically in clockwise fashion. Each time you cycle through, there is one less relationship to discuss. Until finally there is only one relationship to discuss between the seventh anchor and the eight factor.
Hence, my caution in step 3 above to limit the number of factors to a maximum of eight.
This analysis is essential. By exploring cause-effect relationships, the team is collectively forming their shared mental model of factors and relationships between them.
You may end up with a map of cause and effect relationships like this.
Fig. 5: A web of cause and effect relations
(d) You can not present this
This messy ball of relationship yarn, must be confusing to you. Just as it should be. You were not involved in the discussions that led to it. This diagram would mean as much to you as it does to a playful kitten. Something to toy around with, and perhaps to get entangled in a cute mess with.
Fig. 6: Do not present your ball of yarn, unless you are this cute
The value of Simple cause and effect analysis lies in enabling structured conversations within the team. This is an approximation, at best, of shared understanding of the context within which this team operates. The hidden systems structure that governs observable behaviors and events. This visual representation means a lot to the team members who participate in its creation. It provides a reference for all team members to visualize together. A snapshot of how team members intuit their organization system to really work. How cool is that!
Curiosity (I wonder…), and participation (engagement) are prerequisites to understanding. You cannot present this model. It will make no sense to your manager or your friend. They will have to engage in a conversation with your team and influence the shape of this shared mental model. And as a consequence they will share their learning with others, to increase overall team awareness. Therefore, I strongly encourage managers to participate and wonder along with their teams.
The services of a facilitator are crucial. Their patience, and methodical channeling of discussions to keep momentum helps a team to not get bogged down in minutia. With practice, Step 6 - Simple cause and effect takes 15 - 20 minutes.
But the facilitator’s role is not done yet. The best is yet to come.
Step 7: Dominant factors (Synthesis) - a debrief
Learning together as a team involves owning your insights and taking actions based on them. You cannot borrow these insights from the “best practices manual”, and no tool is a substitute for judgment. As a team you will have to arrive at your own insights, and take action based on your own understanding.
In complex systems, any system that involves people, there is never really a single cause nor a real single effect. Things are interconnected, and in surprising ways. With the simple cause and effect diagramming above, our objective is not to play post-it billiards. Instead we want to develop a shared understanding by considering the system as a whole. There are revealing insights in the picture above, if you know how to look for it.
For each factor count the number of arrows going out, and the number of arrows coming in.
Fig. 7: Count INs and OUTs
A quick reminder on our curiosity that led us here:
I wonder why my team does not take on challenging work, or increase their productivity?
Dominant effects
Reviewing our counts reveals that the system as modeled, through team conversation, has the following dominant effects:
Increase in team productivity. (0 - OUT, 4 - IN)
Team takes on challenging work. (0 - OUT, 6 - IN)
Nothing terribly surprising here. Of course since the manager and/or the team is curious about lack of initiative from the team in taking challenging work and wants to increase productivity, we are now assured this is indeed a visible outcome of this systems structure.
To put it simply, dominant effects are the most visible.
Everybody sees the dominant effect, and worries about it. Visibility attracts attention. And as a consequence of attracting attention, it gets measured. Any real or perceived lack of meeting expectations, or desire to showcase improvement will draw attention to this most visible factor. The dominant effect.
Managers may rush to create a team member skills competency matrix so they can hold them individually accountable. Or hold a team meeting to set expectations on the number of story points/breadth expectations from the team. Such interventions are easy to announce, and may show marginal improvement in the short term. And therefore, perhaps, these continue to be tried over and over again.
Such interventions are naive, because they work against systemic leverage. Understanding points of leverage within your system and directing interventions appropriately can unlock long term shifts.
Dominant cause
A quick review of our counts reveals that the system as modeled, through team conversation, has the following dominant causes:
Culture of trust (4 - OUT, 0 - IN)
Inspiring goals/vision (4 - OUT, 0 - IN)
Team has autonomy over processes (4 - OUT, 1 - IN)
Notice that I am ignoring factors that have almost the same number of arrows IN and OUT.
A dominant cause is one that affects many factors directly or via other factors. Interventions aimed to make desirable shifts in dominant causes hold more promise.
To put it simply, dominant causes are points of leverage.
Dominant causes often become entrenched and hidden. They can be hard to pin down. And this is why we have gone through all the steps so far - so the system at play can reveal its secrets.
Systems modeling is a collective activity for the whole team, and not for a manager alone. Through modeling, team discussions, and visually representing a shared model, your team will unlock additional insights that could hold revealing breakthroughs to make shifts at these crucial points of leverage.
For our purposes, we will go through the example discussed to consider some practical steps that can be taken by a team. These may not be applicable to your specific situation.
Building a culture of trust can be a humongous task when considered at the scale of a corporation. But at the same time building pockets of trust may be feasible within a single team. What can team members do to improve trust between themselves and with their managers ? Your team may start holding retrospectives again or take time out to socialize over virtual lunch. For an example of technique that I have used, see sharing values exercise to improve the degree of trust within your sphere of influence.
Managers may also consider easing down on prescriptive ways or, even better, set up a decisions agreement with their team, see decide how you are going to decide, so the team and management can have explicit agreements in areas where the team has autonomy over its processes.
Understanding the points of leverage for your system at play can open up a wide array of possibilities. A tiny change at these points of leverage can have disproportionate (non linear) impact on the overall system dynamics.
Get creative. Mix and match to design counter-measures that make a tiny dent across multiple factors, or consider a set of related counter measures to be tried all at once.
Because the dominant causes are so entrenched, they may not easily budge. And so, paradoxically, attempts to influence dominant causes lead to safe-to-fail experiments. Because big changes cannot be tried at once, you have to take incremental steps. And also because no one expects you to actually tip the system, you have the advantage of attempting multiple creative interventions.
Fig. 8: Dominant factors
Boundaries
Of course there is no way we can model all the factors that are involved. Remember everybody has their blind spots.
Clearly there must be some other factors that cause changes to “culture of trust” and “inspiring goals/vision”. Just because in our systems diagram there are no factors that affect them, it does not mean that there are no other factors that affect these dominant causes.
Our understanding of factors itself will also also be incomplete. Of course a culture of trust is not the only factor that affects a team’s autonomy over its processes. There may be instances where we collectively modeled incorrectly, or failed to notice a relationship that actually in fact exists. These are our collective blind spots.
These boundaries of comprehension and understanding are our limits. Teams benefit from keeping this visualization so that the shared systems model can be easily updated.
There is no way one can consider the totality of everything involved to make the best decision. Courage to act from incomplete understanding is foundational to team learning. And this simple cause and effect systems modeling technique can aid your team to collectively build shared understanding of your system at play. So you can decide and agree on what to do about it.
Curiosity awakens
I wonder…
Learning never stops. After attempting this activity in your first area of concern, you will undoubtedly uncover new areas of inquiry.
My hope is that managers and leaders open doors to team learning through their example of practicing curiosity, engaging in collective learning and boldly attempting counter-measures to some of the deeply entrenched issues of the modern work environment.
Do you want to go beyond the basics?
If you found this article useful, join our Accelerate Advantage™ mailing list. Evolve Agility is founded on the belief that people care deeply about their places of belonging and are not afraid to take action. Join our mailing list to stay connected with a growing community of practitioners who believe in actionable learnings.
Virtually every Team in their first Sprint is confronted with the problem of single-specialization causing work imbalance. What happens? The Product Owner orders the Product Backlog to maximize value. But when the team members are specialized in a single dimension - such as QA, Java development, front-end development - some team members regularly will find themselves with no work related to their area of specialization. Single-specialization inevitably causes work imbalance.
Organizations typically react by applying the following quick-fixes, (1) have people be on more than one team, (2) give additional work to the team, or (3) do work for the next Sprint (e.g. design) or work related to the previous Sprint (e.g. QA). The latter two quick-fixes are easily recognized as they lead to half-done items at the end of the Sprint, often referred to as ‘carry-over’ or ‘spill-over’ work.
Key point:The phrases ‘carry-over’ and ‘spill-over’ are not Scrum. They’re signs of dysfunctional Scrum.
Each of these quick-fixes inhibit well-oiled teams and reinforce responsibility at the level of individual members. For most organizations, Scrum entails a change in teams from individual responsibility (of my area of expertise) to a team-shared responsibility (for all work required to achieve the goal of the Sprint). Scrum makes this explicit by having a role: ‘Team’ – a single role of multiple people, rather than roles of team members.
Shared responsibility through balanced specialization
How do teams resolve the problem of specialization and work imbalance? Although it is up to the team, most teams have members learn and create secondary areas of specialization. This does not mean that all team members become generalists – either single-specialization or generalist is a false dichotomy.
Team behaviors that lead to balanced specialization are:
Whenever the team has the right expertise for current work, every task is a learning opportunity. Any team member can either pick it up and do individually or request to pair or mob.
Whenever the team feels there is currently enough learning going on, the tasks tend to be picked up by the team members with the most expertise in them.
Whenever the team does not have the right expertise for the current work, the team discusses how to gain that knowledge through learning and collaboration.
Implications for organizational structure
Most organizational structures, such as functional departments, functional career paths, or component teams cause single-specialization in either functional skill or technology area. When these structures are kept in place while adopting Scrum, they cause conflicting loyalties. Team members have one loyalty towards their team for their shared work and another loyalty to their organizational unit. The organizational loyalty is involved in performance reviews, promotions, and bonuses and therefore tends to ‘win.’ Shared team responsibility only happens when these traditional single-specialization focused organizational structures are eliminated.
Scrum implies a shift from individual responsibility to shared team responsibility, which in turn implies a change from single-specialization to multi-learning. This can only be achieved by eliminating organizational structures that promote single-specialization. Scrum adoptions by ignorant managers that avoid these changes are likely to lead to pretend-Scrum – the same old with new words.
RSS feed