Posted on

Management is a Function, not a Role

Self organizing teams are self managing teams. They govern themselves. They are self governing.

Some folks new to Agile think that when you go Agile, that management goes “out the window”, is a bad word, is evil, is something that imposes prescriptions, issues commands, and is controlling, and something to be avoided.

The reality is that the need for planning, measuring, and observing does not go away in Agile.

Far from it! Rather, the function of management is handled by the team, instead being handled by a single person in a role like the “project management” role.

Moral of the story: the need for management does not disappear in Agile. On the contrary. We actually do more planning in Agile. We do it as needed, continuously, and just in time. The function of management does not go away. Instead, the function of management shifts from a person (in a role) to a self managing team.

The Core Idea: In self managing teams, management is a function, not a role. The team handles the function of managing itself.

Self management aligns with this principle, found in the  Agile Manifesto:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Posted on

Kanban and Organizational Permaculture

This post identifies an agricultural technique (actually an agricultural-sustainability hack) called permaculture.

Permaculture principles and practices associate with culture hacking in general, and Kanban (in particular.)

A full set of links for all footnotes are provided at the end of this post.

Culture Hacking, Permaculture and Kanban

Kanban is a method for managing work and work flow. It is visual, and exposes certain things that are going on within a group doing work, and makes those things explicit. In the canonical form of Kanban, it imposes at least SOME structure by also making policies explicit, limiting work-in-progress, and so on. (If you need a primer on Kanban you can reference link [3] to catch up).

Organizationally, it’s hard to object to Kanban, in part because it does not ask very much of you– at least at first. There are few if any  anxiety-triggering changes in current roles, goals, meetings, and artifacts. This makes it easy for everyone to relax, and opt-in to the Kanban game, because Kanban, at least at first, does not seem to demand very much of you. Kanban is something that is easy to insert into the situation. And that ‘something’ is a refocusing of attention on things that matter to work groups, things like “the type of work we are doing”, “the flow of that work”, “the regulation of those flows”, and the like.

Now I want you to notice that when you introduce Kanban, you are actually engaging in the introduction and composition of new elements with existing elements in ways that are complimentary. Repeat: With Kanban, you are engaging in the introduction and composition of new elements with existing elements in ways that are complimentary.

Which brings us to the fascinating topic of permaculture.

Permaculture

Permaculture is a form of agriculture. It is a discipline of design and composition that leads to the sustainable extraction of value from the resulting system. Rather than make wide-scope changes, permaculture practitioners compose complimentary elements in service to sustainability of yield:

Permaculture asks the question, “Where does this element go? How can it be placed for the maximum benefit of the system?” To answer this question, the central concept of permaculture is maximizing useful connections between components and synergy of the final design. The focus of permaculture, therefore, is not on each separate element, but rather on the relationships created among elements by the way they are placed together; the whole becoming greater than the sum of its parts. Permaculture design therefore seeks to minimize waste, human labor, and energy input by building systems with maximal benefits between design elements to achieve a high level of synergy. Permaculture designs evolve over time by taking into account these relationships and elements and can become extremely complex systems that produce a high density of food and materials with minimal input. (Source: Wikipedia [4] )

It’s drop-dead obvious that Kanban is an application of permaculture applied to low-producing social-systems instead of low-producing tracts of land.

Intrigued? Check out these 12 Principles of Permaculture…as you examine the list, map the permaculture concepts listed to what is going on inside Kanban implementations as described in the book KANBAN by David Anderson [5]:

Permaculture Principles

  1. Observe and interact: By taking time to engage with nature we can design solutions that suit our particular situation.
  2. Catch and store energy: By developing systems that collect resources at peak abundance, we can use them in times of need.
  3. Obtain a yield: Ensure that you are getting truly useful rewards as part of the work that you are doing.
  4. Apply self-regulation and accept feedback: We need to discourage inappropriate activity to ensure that systems can continue to function well.
  5. Use and value renewable resources and services: Make the best use of nature’s abundance to reduce our consumptive behavior and dependence on non-renewable resources.
  6. Produce no waste: By valuing and making use of all the resources that are available to us, nothing goes to waste.
  7. Design from patterns to details: By stepping back, we can observe patterns in nature and society. These can form the backbone of our designs, with the details filled in as we go.
  8. Integrate rather than segregate: By putting the right things in the right place, relationships develop between those things and they work together to support each other.
  9. Use small and slow solutions: Small and slow systems are easier to maintain than big ones, making better use of local resources and producing more sustainable outcomes.
  10. Use and value diversity: Diversity reduces vulnerability to a variety of threats and takes advantage of the unique nature of the environment in which it resides.
  11. Use edges and value the marginal: The interface between things is where the most interesting events take place. These are often the most valuable, diverse and productive elements in the system.
  12. Creatively use and respond to change: We can have a positive impact on inevitable change by carefully observing, and then intervening at the right time.

Source: Wikipedia Permaculture Design Principles [6]

Is understanding the language of permaculture a key to understanding and implementing effective culture change in organizations? Probably!

What’s interesting is how the language of agricultural permaculture supports the best incremental-culture-change ideas found in my book THE CULTURE GAME book [2] and the KANBAN book from David Anderson [3].

 

Kanban…is permaculture…applied to knowledge workers. — Alexis Nicolas (France)

 

The Organizational Permaculture Approach

Here is even more support for the incremental, here-and-now permaculture approach, from a blog post, by noted complexity-science authority David Snowden [7] :

So if you want to change organizations, three basic principles:

  1. You don’t lecture management on how they are old fashioned in their thinking, instead you put them into situations and give them tools where old ways of thinking are not sustainable and they have to act differently. If they work it out for themselves its sustainable.
  2. You pick off areas where the pain threshold is the highest, for example (to pick up Agile themes) the interaction between approaches such as Agile and the measurement and management practices of the HR function.
  3. You then create approaches that change the measurement and feedback mechanisms that work in parallel with existing methods.

Implications of Organizational Permaculture

  1. Client organizations, coaches and other culture hackers can probably benefit tremendously by studying and applying the core concept of permaculture to the design of interventions. Kanban is an element for designing and composing permaculture learning solutions inside existing organizations.
  2. The most effective culture hacks are probably those that strongly align with the 12 Principles of Permaculture. This likely explains (in part) the success of Kanban [3] and the 16 Culture Game Tribal Learning patterns [2]
  3. We probably need to pay particularly close attention to Kanban case studies, since Kanban is actually a particularly good example of how to introduce and apply permaculture techniques and permaculture thinking to culture change in organizations.
  4. We probably need to search for and find more easy-to-introduce permaculture technologies like Kanban and repeat the pattern. Techniques that can co-exist with what is already there and substantially improve team learning quickly are what we are looking for.

Summary

Kanban implementations are significantly aligned with the 12 core principles of agricultural permaculture. Culture change via the incremental permaculture approach is an interesting idea whose time has come. Most effective culture hacks probably have very strong alignment with the 12 Principles of Permaculture.

 

Footnotes:

[1] Kanban and Tribal Learning (link)

[2] The Culture Game Book (link)

[3] Kanban Explained (Wikipedia entry) (link)

[4] Permaculture (Wikipedia entry) (link)

[5] KANBAN: Successful Evolutionary Change for your Business (link)

[6] Wikipedia: Permaculture Design Principles (link)

[7] David Snowden Blog Post with 3 Big Ideas: “Rose Tinting” (link)

Posted on

Agile Coaching Values

Agile Coaches are familiar with the patterns of naive and vulnerable client organizations that are new to Agile. In my view, Agile Coaching pros have an obligation to help clients understand what is best for them. This always includes helping the client take 100% responsibility for their own learning. This usually means the coach must refuse opportunities to play a larger role.

Being there, 5 days a week, full time, for 3 months or more can be lucrative and hard to resist. As coaching professionals, we do our best (and live up to our potential) by serving the learning of the client organization. This includes challenging the client org to take 100% responsibility to reach a self-sustaining state of Agility, without the need for an external coach.

These Agile Coaching values and principles listed below are a good and solid basis for guiding coach-client relationships and interactions. These values and principles are listed in the familiar ‘agile manifesto‘ format.

The content- these values and principles– are optimized on the continuous, progressive and ongoing organizational learning of the coached organization.

 

In serving our clients, we have come to value:

Creating Independence over generating billing
Championing Learning over avoiding risk
Building Relationships over building transactions
Inviting Participation over assigning responsibility

 

We use these Principles to guide our work with clients:

Voluntary engagement of everyone involved in organizational change is an essential requirement for success.

Coaching every single day in an organization creates a serious risk of client dependency and is to be avoided, consistent with common sense and good judgement with respect to client needs.

Organizations are responsible for their own learning. Arms-length, time-boxed working agreements between clients and coaches are essential.

Coaches must look for every opportunity to increase the learning of the organization as a whole, with strong intent to vacate or otherwise evolve the current coaching role as soon as possible.

Coaching requires the willingness to identify any cultural impediments to continuous improvement, and to communicate these to the people in the organization who have the authority to address them.

The primary task of a coach is to help improve the effective results and working lives of the people employed in the organizations they serve.

The ability of an organization to respond to change is the primary measure of progress.

Leaders in an organization must continuously signal positive encouragement, and create safe space for others to think and learn, if positive culture change is to be lasting and effective.

Posted on

Estimating and Team Learning

There is a big debate out there about the value of estimation on Agile projects. There are two items that need to be distinct when we talk about this. The first is estimation as a Team Learning activity. the second is estimation as part of the basis for planning.

Let’s look at team learning first:

Estimating as a Team Learning Activity

The primary value of estimating (as a group) is in the team learning. The estimate “deliverable” is secondary. Repeat:  The primary value of estimating (as a group) is in the team learning. The estimate “deliverable” is secondary.

Planning poker in particular provides a structure for making sense of the estimating task and the learning that comes from that. When teams estimate with planning poker, they are learning about the work, and EACH OTHER.

Not Understanding Requirements Creates Anxiety

Agile processes are patterns and practices that increase sense-making at the level of group. When we do not know “what a requirement means”, we worry about it. When we know what something means, like a requirement, that reduces anxiety by increasing the perceived sense of control. A sense of control makes us feel good. We know what it means. That reduces worry about what to do next.

All Learning is Change, All Change Creates Anxiety. Therefore: Learning Creates Anxiety.

All learning is change. Change is stressful because the process of change reduces the “known” and/or increases the “unknown”. The ratio of “unknown items” to “known items” goes up when the process of learning is taking place. The initial process of learning creates a progression from the known to the unknown.

Knowing where you are is very comforting. Not knowing is stressful. Learning is de-stabilizing and causes stress. Learning causes you to shift from the known towards the unknown as you engage in the learning process. The process of learning creates substantial instability…until your new learning is fully integrated.

Lack of Structure Creates Anxiety

As if the process of team learning was not already problem enough, we also have the structure problem. This is a social problem. People feel stress when structure is lacking. We also tend to feel a sense of control when we are participating in well-structured social activities.

Ritual Creates Safe Space for Learning: Planning Poker As Ritual

Now let’s discuss estimating using planning poker. As stated previously, the primary output from the activity is learning, not the estimate itself. The act of estimating using planning poker is a ritual activity whose goal is manage the sense-making, and the subsequent integration of the know-how.

Planning poker is a ritual. A ritual provides known A-B-C steps for beginning, experiencing and completing a journey through the learning. A planning poker session that is facilitated can be viewed as a ritual of learning that manages the state of “not knowing”. The planning poker ritual provides structure and a predictable experience of dialogue and structured learning.

In summary: team learning creates instability. This ambiguous state of being is best managed with predictable rituals that help in getting from here to there.

With the discussion of team learning behind us, we can now talk about a very basic problem: using estimates for planning.

 

Almost All Estimates are Wrong

Estimates are usually wrong. Especially early in a project, not much at all is known. Any estimates are flawed. Pretending this is not true does not make the reality go away. What usually happens is, we take these flawed estimates, use them for projections of cost, features, delivery date, and quality. We then make commitments that are binding between the development team and the product owner and/or project sponsor. This is a serious error in many dimensions.

Almost All Rituals are Good

That said: we can argue that Agile methods manage the instability inherent in all team-learning. Planning poker, for example, is a well-understood ritual for generating team-learning as a primary side effect of producing an estimate. We can say that each Scrum meeting is a kind of team-learning ritual.

Are Scrum Ceremonies Actually Rituals That Help Manage the Instability of Learning?

Yes. Jeff Sutherland and Ken Schwaber refer to Scrum meetings as ‘ceremonies’ in the Scrum literature. This is very telling language.

Could it be that Scrum is actually implementing a repeatable series of rituals that are managing the in-between, destabilizing nature of team-learning?

What is Planning Poker Really?

Planning poker is a team-learning ritual that is focused on understanding software requirements. The planning poker ritual is predictable, repeatable, and structured. While maybe 3% of all agile teams are comfortable in total ambiguity, the other 97% need rituals to help them impose some structure on the  process of generating (destabilizing) team learning.

We can argue that Scrum ceremonies like the Retrospective are also rituals that are managing states of uncertainty. They provide structure to help navigate the often ambiguous states of being that are created during team-learning.

What Can We Do?

We can do the following to advance the state of the art:

  • Admit that group-estimating procedures like planning poker are actually rituals that are helping to provide structure during learning states;
  • Admit that the true value of estimating is the generation of team-learning and not the estimate itself;
  • Admit that estimations are tremendously under-rated precisely because estimates (even when incorrect) serve reduce the “sense of ambiguity” that comes from not knowing the ultimate cost of a project;
  • Design useful, customized and tailored agile-learning rituals , beyond planning poker, which manage the ambiguous nature of team-learning.

The moral of the story? It ain’t as easy as it looks.

Related Links:

Sense-Making: http://en.wikipedia.org/wiki/Sensemaking

Posted on

Functional Stupidity

Some of what looks like lack of smartness is actually good for stability of an organization. How does this work?

Organizations that constantly learn are constantly in flux and experiencing ambiguity … and usually, more than a little anxiety and mixed feelings. Constant learning is stressful and constantly adapting to change means constant changes to practices and policies.

“Functional Stupidity” serves the purposes of leaders who value stability over learning and adaptation. As such, it may be rational in the short-run to optimize on stability. Can Functional Stupidity be useful in the long run?

Probably not.

The tradeoff between stability and learning is a classic trade-off between getting a quick, short-run fix, versus crafting a long-run solution.

Good policy (“we optimize on learning”) usually makes you worse, then better. Bad policy (“we optimize on stability”) provides a quick fix…and a longer-term compounding of the larger organizational learning problem.

Read the intriguing paper: A Stupidity-Based Theory of Organizations

Posted on

Practices Change, Principles Don’t

“Practices change, principles don’t.” This is a saying I picked up from Traci Fenton of WorldBLU when I interviewing her by phone last year. Since that time I have come to internalize this saying and use it for guidance when coaching executives and teams.

The Agile community isn’t calling this out and really leveraging the idea. The Agile Manifesto has 12 principles. They appear as an additional page, after the values. You have to click through to see them. I’m not sure how many people know about these 12 principles.

Here is an enlightened blog post from Joshua Kerievsky which makes good sense to me. In this post he advocates dropping the use of story points and velocity in Agile work. For mature teams, this is probably OK. Now, what’s interesting about these two practices is that they really do not directly support much of the Manifesto principles at all. See it? In addition, Josh calls out how making his adjustment does support one of the Manifesto 12:

“…Using the new process, we shipped (on average) 1-2 times per week. Our agility had increased by removing once-sacred pieces from our process. We were now even better at delivering on the promise of the Agile Manifesto’s first principle:”

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

These 12 principles supply enough guidance to build a team that can learn and adapt. In my book The Culture Game, I explain this. These 12 principles are so good and complete, you can use almost any practice that does not violate these 12 ideas, and be OK. If you map Scrum to the Agile Manifesto, it is clear that Scrum is not violating any of these principles.

Likewise, you can institute ANY practice and so long as you are in alignment with these 12 principles from the Agile Manifesto, you are going to be OK. People learning to learn a a group need something like Scrum to start. After experiencing Scrum and internalizing some of the 12 Manifesto principles, teams can try all kinds of things. They may find Scrum ws better than they thought, or they may develop a higher level of group functioning that includes “Examining What’s Normal”, something I devote a complete chapter to in The Culture Game book.

The point here is simple: it’s not whether Scrum or Kanban is better. Or whether iterations or continuous flow is better.

What matters is that you tie your practices BACK to the 12 Manifesto principles, because alignment with them makes your team much smarter. You can use any practice at any time and be OK if you do this. So, when evaluating your practices, or discussing them, be specific about how they do (or do not) align with the 12 Principles of the Agile Manifesto.

“Practices change, principles don’t.” – Traci Fenton, www.WorldBLU.com

 

 

 

Posted on

Scrum Authority Mapping

 

Authority issues are at the root of most failed Scrum implementations. Most organizations doing Scrum are unaware of the way Scrum roles contain specific authorized tasks. In Scrum, there is a clear separation of non-overlapping powers across the 3 roles. When this clear division becomes fuzzy, the result is all sorts of serious problems with Scrum.

Diagramming the specific authorized tasks in Scrum, by role, provides a simple and powerful way to depict exactly what is going on with authority in your Scrum implementation. I formulated Authority Mapping in late 2010 in response to client requests for diagrams describing complex authority problems in Scrum.Freely downloadable Scrum Authority Map diagrams appear at the end of this post in PDF format.


Scrum Authorized Tasks– by Role

Listing the various tasks authorized under each Role is Scrum an interesting exercise in deconstructing Scrum. Let’s enumerate the specific authorized tasks associated with each Scrum role:

 

Product Owner: Authorized Tasks

  • Gather requirements and describe in PB
  • Define per-story acceptance criteria and “definition of done” as part of requirements
  • Gather estimates and place into Product Backlog
  • Prioritize and properly size Product Backlog items
  • Present PB at Sprint Planning meeting
  • Preside in authority at the Sprint Planning meeting
  • Behave in conformance with Scrum rules at all Scrum ceremonies
  • Optionally abort the Sprint
  • Accept or reject the increment per definition of DONE
  • Develop Release Backlog & Plans
  • Preside in authority at the Sprint Demo
  • Participate in the iteration retro

 

Team: Authorized Tasks

  • Supply estimates to PO for PB items
  • Pull work (the “what”) from PB to SB during SP meeting
  • Carve SB into tasks (the “how”) during Sprint
  • Execute Daily Scrum meeting per Scrum rules
  • Follow the protocol of the three questions
  • Deliver per-Sprint increments
  • Demo increments at Sprint Review
  • Participate in iteration Retro

Scrum Master: Authorized Tasks

  • Facilitate Sprint Planning meeting for PO
  • Facilitate Sprint Review (demo) meeting for PO
  • Facilitate Sprint Review (retro) for Scrum Team
  • Facilitate Daily Scrum (each day) for Team
  • Protect Team from distractions and threats
  • Referee the rules of Scrum (keep the process)
  • Identify and remove impediments for Team
  • Arrange for Daily Scrum (location and time)
  • Help identify a Product Owner

 

Authorized Tasks

I do not believe a list of this sort has ever been assembled as a way to analyze and view Scrum along the lines of authorized tasks.

Scrum’s clear roles are actually containers that contain authorized tasks— tasks which that each specific role has the right to do per genuine and authentic Scrum per the Scrum Guide.

It is useful to note that there is little or no overlap in the powers (“authority”, or “right to do work”) assigned to each Role. Early versions of Scrum vested the Product Owner AND the Team with the dual authority to kill the Sprint. The modern and most current version of Scrum per the Scrum Guide (found at Scrum.org) now assigns that authority ONLY to the Product Owner.

 

Mapping Authorized Tasks

The clear containment of specific authorized tasks by Role in Scrum creates an opportunity to visually depict or map the Role. This can be done by utilizing a simple “radar” graph, where each ‘spoke’ in the diagram depicts a specific authorized task for the role under consideration.

For example, here is the Scrum Authority Map for the [Team] role:

Figure 1: The Scrum Team Authority Map: Team tasks mapped to a radar graph

With this map, we can now depict the various ways in which a Team can take up (or not fully take up) the Team role. The map provides a way for you to accurately depict what is going on.

In your organization, you are probably familiar with people who “over-step” their Role. They take up more authority than the Role requires. Over-stepping is a common occurrence. Just as common is “under-stepping”– that is, NOT taking up all the authority vested in a Role.

This is exactly what new Scrum teams do: they under-step, and do not take up the full authority Scrum provides to the Team.

Now here is an authority map, filled in to depict the typical new Scrum team:

Figure 2. The Authority Map of a new Scrum Team who is not “taking up” all of the task authority granted to them in Scrum.

Here the new Scrum team is at about 50% on all the tasks they are authorized to do. This means they are assuming only about 1/2 of the authority they have per the Scrum rules. This is typical and entirely normal for new Teams, who often are uncomfortable (at least initially) with the higher levels of authorization granted by Scrum.

The green color signifies the level of authority they have effectively taken up, the yellow region depicts the substantial additional authority they have yet to “take up”. Teams new to Scrum typically “under-step” for many complex reasons.

Authority is not something that lays there unclaimed for very long. I’m sure you have seen persons in your own organization that actively collect authority “scraps” and begin wielding these small chunks of power.

Authority is often ceded, abandoned or otherwise left behind. Since authorization is valuable, others “take it up”. This is exactly what happens to new Scrum teams who are not sure how much authorization they have. The authority to do things gets picked up by others, such as the Scrum Master or the Product Owner.

For example, if the team is timid about pulling work from the Product Backlog during Sprint Planning, the Product Owner or the Scrum Master might choose to “help” by actually assigning the work into the Sprint Backlog. Once that happens, the Team is blocked, demoralized– and de-authorized. They check out and become a de-authorized team of zombies– a zombie team– present in body only, not engaged and definitely not passionate about this de-authorized brand of “Scrum”.

Depicting an Impeded Team with an Authority Map

Here is how a blocked team might look– a Team who is slow to take up their full Role, and is in fact leaving authority on the table. In such cases, the Scrum Master or Product Owner (or someone else) actually picks it up:

 

Figure 3. A Team with authorization blockages depicted.

Here, red signifies that some other person, group or organization is effectively impeding the Team from fully taking up all the authority genuine Scrum provides. In this depiction, the Team is ‘surrounded’ by others who are taking up about 50% of their total authority per Scrum.

In real-life scenarios, the Authority Map has various odd shapes that vary according to the situation.

The Artful Scrum Master

Teams typically are slow to take up the full authority granted by Scrum. There are many reasons for this. They might not want the higher levels of authorization Scrum provides. The new Team role with higher authorization might not be comfortable. The team might want to told what they “should” do. Or the Team may have low confidence that the organization is capable of actually maintaining high levels of Team authorization.

Eventually, if the organization is genuinely committed to Scrum, the Team will begin to take up the full authority vested in them by Scrum itself. It is the job of an artful Scrum Master to MAKE SURE that others do not “take up” the Team’s task authority during this delay. This is part of what is meant by the phrase “Protect the Team”.

If you have an artful Scrum Master, then within 2 or so iterations, the Team will begin to put its toe in the water, testing to see if they really do have the power to load the Sprint Backlog, define the Tasks, conduct the Daily Scrum and so on. When they realize they do, their Authority Map starts to looks like this, the Authority Map profile of a extremely healthy Scrum Team that has excellent execution and no impediments:

Figure 4. A healthy Scrum Team who fully “takes up” all the authority granted by Scrum.

Authority Mapping is a simple yet powerful way to depict exactly what is going on with authority in Scrum– by Role. Similar maps can be created for the Product Owner and Scrum Master role. An endless variety of situations can be depicted accurately using the Authority Map technique.

Practical Use of Authority Maps

Authority Maps are useful for depicting authority-related impediments, and provide a visual context for examining the problem under consideration. These maps are particularly useful for depicting issues with Scrum to sponsors, executives and Product Owners, as well as Teams. Use of Authority Maps is especially useful for Scrum Masters during Retrospectives with the Scrum Team. These diagrams are also useful at the start of adopting Scrum, to help describe and depict the various ways sponsors and executives can help Scrum take root. For example, a depiction of the Team’s Authority Map before and after an executive attends a Daily Scrum as an Observer can be useful for habituating those executives to Scrum and Scrum dynamics

Case Study Example: Teams Dominated by Product Owner and Scrum Master

The following is an Authority Map of a Team that has problems. The Product Owner is doing certain of the Team’s tasks and is doing so outside the rules of Scrum. Likewise the Scrum Master has grabbed certain tasks reserved for the Team role in Scrum. The result is a Team that cannot function well. Intrusions into the Team role and the taking up of Team tasks by others are depicted in RED in Authority Maps.

The Product Owner (PO) is pulling the work “for the team” or to “help the team” in the Sprint Planning (SP) meeting and is also “helping the team” by carving the Sprint Backlog (SB) into tasks during the Sprint Planning meeting. The Scrum Master (SM) is updating the BurnDown chart which is a task that only the Team is authorized to do in Scrum. This team was train wreck for these reasons.

The coverage in green is very low due to the Team being dominated by the Product Owner and Scrum Master. The other authorized tasks of the Team are not well-executed because of these unauthorized intrusions by the PO and SM. The game of Scrum was poorly played by this group of people.

 

 

Summary

Explicit examination is a hallmark of genuine and authentic Scrum. Authority maps extend our ability to visualize social dynamics in an easy-to-read yet powerful depiction of the current reality of your Scrum implementation.

Authority Map Diagrams are Available Now

You can download blank authority maps for the Product Owner, Team and Scrum Master roles below, for use in your own coaching and Scrum Mastering work.

Links:

Reference: Boundary, Authority, Role and Task: BART Analysis of Complex Systems

Download: This article as a PDF:  ScrumAuthorityMapsArticleV2

Download: Team Authority Map: TeamA-MapV2

Download: Product Owner Authority Map: ProductOwner-A-MapV2

Download: Scrum Master Authority Map: ScrumMaster-A-MapV2

***

About the Author

Daniel Mezick: An expert on teams and a trusted adviser to CxO-level executives worldwide, Dan consults on enterprise-wide culture change, implementing Scrum, and the often difficult adoption of authentic Lean principles. Learn more about Daniel Mezick here.

 

Posted on

Lack of Team Authorization

Team authorization is at the heart of Scrum. Scrum provides TWO places where teams have substantial authority: The Sprint Planning meeting, and the Daily Scrum. Teams must believe they have authority over team life before they can self-organize. Without authority over team life, Scrum teams can never inflect to 2X, 3X, or 4X levels of productivity.

This post analyzes the levels of formal team authorization that Scrum defines for the Sprint Planning and Daily Scrum meetings. This post calls attention to how most problems in implementing Scrum are rooted in very low levels of team authorization.

Original date of note: 06/30/2010 by Dan Mezick

Background

I wrote the highly incendiary post on ‘Zombie Teams‘ some time ago. It caused a lot of people to say “Absolutely” and “hell ya!” This Zombie Teams post generated other feedback as well, some not quite so positive.

For the record, Jeff Sutherland is linking to that post, displaying it on his Scrum log. See it here.

This newer article and others like it are planned, to provide a bit more background on the dynamics of “team de-authorization”. The Zombie teams post may seem a bit “over the top” but serves to call attention to an essential aspect of good Scrum– which is, very strong support for team authorization.

Team authorization is at the heart of authentic and genuine Scrum. Please note that these insights are coming directly from my experience coaching Scrum teams in all kinds of organizations and situations.

The coaching work is providing experience to gain these insights and I am sharing them with you directly, here. Some of these insights seem obvious when you read them, but the reality is that the actual authority dynamics are often very subtle.

Read on.

Team Authorization 101

The typical problems in new Scrum implementations are derived from an ambiguous or otherwise troublesome lack of clarity about team authority. The main problem is a lack of sensitivity to Team Authorization.

Team must believe they have substantial authority to self-determine most aspects of team life. Scrum provides high levels of formal team authorization in two Scrum ceremonies: the Sprint planning meeting and the Daily Scrum.

Sprint Planning

In Sprint Planning, ONLY the team is authorized to fill the Sprint backlog. Note that while teams are authorized, behavior is constrained per the Scrum rules: the team must pull from the TOP of the Product Backlog. That fact is less important than the fact that only the TEAM is authorized to do this.

Here are some ways to undermine team authorization in the Sprint Planning meeting:

1. “ZONED PRIORITIZATION” GAMES BY PRODUCT OWNER. ‘Zoned’ prioritization of the Product Backlog by the Product Owner. Instead of unique priority numbers for each backlog item, have ‘groups’ that are listed as priority 1, priority 2, etc. For example, have 12 items labeled as “priority 1”, then another set of items labeled “Priority 2”. This is the same as telling the team what goes into the next two Sprints. This de-authorizes the team and leads to very weak Scrum.

Guidance: Counsel the Product Owner to stop telling the team what to do indirectly via Backlog Item priority zones. Explain that the team must pull from the top of the Product Backlog and that each item in it must have a unique priority number. Postpone the Sprint Planning meeting until and unless the PO complies with this request.

2. PRODUCT OWNER CAN FIRE TEAM MEMBERS and/or SCRUM MASTER. In addition to zoned prioritization, make sure the Product Owner cannot fire or otherwise influence the employment of team members or the Scrum Master.This de-authorizes the team and leads to weak Scrum.

Guidance: Be mindful that the team is not going to stick their necks out and tell the truth about how they feel if doing so might get them fired.

3. WEAK SCRUM MASTER PATTERNS. The Scrum Master is supposed to mediate and protect the team…from what? From the Product Owner, that’s what. If the Scrum Master does not understand this, other otherwise takes up the Scrum Master role in a weak way that does not protect the team, the team experiences “de-authorization” during Sprint Planning and learns to be quiet and do what they are told. Organizations that do not want to do authentic Scrum often exhibit a pattern of having temporary or not-too-knowledgeable Scrum Masters, or Scrum Masters who often can be fired by (“under the authority of”) the Product Owner.

Another scenario is a Product Owner showing up at the Sprint Planning meeting with a Product Backlog that is not in good shape. Now the weak Scrum Master sits idle as the PO attempts to push epics on the team, and succeeds. This is usually because the team and/or the Scrum Master can be fired by the Product Owner.

Guidance: Notice the weak-SM pattern and question and inspect the pattern. Ask: how is your organization actually exhibiting it? For example, is it expressed as a series of team members who occupy the Scrum Master role for 1 or 2 iterations each? Or is there some pre-existing authority relationship between the PO and SM, such as the PO being able to fire the SM? Examine the situation closely.

Daily Scrum

In the Daily Scrum, ONLY the team is authorized to speak. This is not strictly true since the Scrum Master is authorized to play referee, and can speak when the team is not following the rules of Scrum in the Daily Scrum meeting.

There are many ways to screw up the Daily Scrum. Let’s look at a few of these opportunities to derail Scrum team authorization during the Daily Scrum:

1. SCRUM MASTER ACTING AS PROJECT MANAGER. The Scrum Master is authorized to speak during the Daily Scrum when the team gets off-task. If the Scrum Master oversteps by speaking more frequently, the result is team de-authorization and a weakened Scrum implementation. The Daily Scrum is the team’s meeting. If the ScrumMaster oversteps, the result is weak team authorization and a weak Scrum implementation.

Guidance: Emphasize to the team that it owns this meeting and provide counsel to the Scrum Master to stay out of the way.

2. SCRUM MASTER IS ALSO A TEAM MEMBER. This causes all kinds of problems– in particular during the Daily Scrum. The dual-role over-authorizes this “team member” during the Daily Scrum and leads to all kinds of problems. When the person in dual-role (SM and team-member) speaks during this meeting, which role is actually speaking? This confuses the team about Scrum and weakens their sense of team authorization during the Daily Scrum. Note that the highest levels of team authorization provided by Scrum occur during the Daily Scrum. Period. Screwing with this teaches the team that they have low levels of effective team authorization.

Guidance: Avoid dual-role for the Scrum Master. If you must do this, carefully manage it by adding constraints to Scrum Master behavior IN ADDITION TO the constraints defined by Scrum.

3. WEAK BOUNDARY MANAGEMENT BY SCRUM MASTER, ESPECIALLY DURING THE DAILY SCRUM. The Daily Scrum is the team’s meeting. In reality, per the rules of Scrum, the Daily Scrum has three roles: team-member, Scrum Master and Observer. As a practical matter, if the CEO of the organization attends the Daily Scrum, they attend in Observer role. Observers may not speak during the Daily Scrum. This means the CEO is in fact de-authorized in that space and that time in his or her own organization!!

It is essential that everyone involved understands this.

If people with high levels of organizational authority are allowed to speak, that is in fact a corruption and diminution of the extremely high level of authorization Scrum defines for the team in this meeting. This meeting is the team’s, and is facilitated by the Scrum Master. If the boundary management from the Scrum Master is weak or non-existent during the Daily Scrum, the result is extremely low levels of team authorization and a “check out” on the part of team members. They become a Zombie team.

Guidance: Make sure all Scrum rules are adhered to during the Daily Scrum. Observers need to arrive on time, adhere to the rules, and exit upon the conclusion if the meeting. Is short, Observers need to honor the team.

4.SCRUM MASTER CAN FIRE TEAM MEMBERS. This is a cardinal sin in Scrum. The Scrummaster has formal authority to fire team members while also responsible for “protecting the team.”. This is a fundamental conflict and every team member knows it. If the SM can fire you, you are not saying anything difficult to say, that might get you fired.

In the real world, managers and project managers that have hire/fire authority become Scrum Masters…..this leads to profoundly weak Scrum.

Guidance: (direct from Jeff Sutherland by the way) … if there has to be a firing, the Scrum Master needs to ‘delegate it up’ to his or her boss. The SM should never fire a team member.

For hiring, make sure the team is consulted. Consider scheduling a team interview and/or including the team in the hiring or team-member-selection process in some otehr way. make sure the team BELIEVES they have some influence over the selection of new team members.

Summary Guidance:

High levels of team authorization are at the heart of genuine and authentic Scrum. Take care to notice that Scrum literally authorizes teams, formally, via rules for the Sprint Planning meeting and the Daily Scrum.

Scrum literally mandates formal authorization of the team via the Sprint Planning and Daily Scrum rules, Pay attention to this– and take care to avoid undermining authentic and genuine Scrum team authorization in any way.

***

About the Author

Dan Mezick: An expert on teams and a trusted adviser to CxO-level executives worldwide, Dan consults on enterprise-wide culture change, implementing Scrum, and the often difficult adoption of authentic Lean principles. Learn more about Dan Mezick here.

He creates and teaches specific, useful tools and techniques for facilitating successful enterprise-wide adoption of agile and Scrum. Dan’s articles on teams and organizational dynamics appear on InfoQ.com, ScrumAlliance.org, and AgileJournal.com. Learn more about Dan Mezick’s agile writing here.

He’s the organizer of the Agile Boston user group and a 3-time presenter at Agile2007, 2008 and 2009, an invited speaker to the Scrum Gathering (Orlando) in 2010 and a news reporter for InfoQ.com

Reach Dan at:

dan.mezick [at] newtechusa [dotcom]

You can learn much more detail about Dan via his Agile Coaching page here.