Posted on

Does Software Influence Culture?

Does software inform– or even create— culture? Probably.

We know from Conway’s Law that people in an organization will create systems that match their general pattern of communication. I think it is a little deeper than that, and has more to do with the formal pattern of authority distribution inside the organization. The communication paths follow from that.

In organizations that take the hierarchy literally, we find that loosely-coupled, peer-to-peer, well-interfaced, object-oriented “design patterns” of software design are usually hard to get implemented. Instead, more centralized and hierarchical designs are favored. This is “Conways Law”:

organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations

 

Now it gets interesting.

The inverse– is it also true? This is my expression of the inverse:

organizations are constrained to employ organizational designs which are copies of the authority distribution structure underlying the software systems they use.

 

Call it Mezick’s Inverse if you like.

 

Consider the internet. It is built on TCP/IP: the down-low substrate, the fundamental “under it all” stuff that connects everything.

It is a P2P network protocol. Peer-to-peer. No one computer has any more “control” than any other regarding how packets (data) make it from A to B.

On top of that, higher-level, P2P-oriented layers of protocol emerge: HTTP, IRC, SMTP.

On top of those protocols, applications like instant messengers show up.

Then, still later, very rich P2P apps. Facebook. Twitter. LinkedIn.

These are rich, end-user P2P apps… with P2P architectures… that encourage and in fact enable P2P relationships by and between the users.

What is the result… at the highest level of abstraction? Peer-to-peer culture. Or, at least more demand, more pressure, for genuine P2P culture.

Worldwide. And, in your country. And, in your org. And, on your team…

 

And so: does software create culture? Prob-ab-ly.

Just take a look around.

***

Related Links:

Conways Law (link)

McCarthy Show podcast “Software Creates Culture” (link)

 

 

 

 

 

 

 

 

 

 

Posted on

Theory A

Here is a brief summary of “Theory A“: a theory pertaining to microsociology which may explain some of the actual mechanics of “self organization” in human social systems.

Theory A

Respect is felt feelings of esteem for another individual, and demonstrations of those feelings, through behavior. You can look it up. Most folks understand what respect is. In typical 1-to-1 interactions, mature people always send at least a minimal level of respect to everyone they encounter. “Treat others as you like to be treated” is a basic rule of thumb here. The Golden Rule.

So, respect is routinely sent and received by and between individuals. When those individuals are in the same group, the “packets” of respect get tagged with various additional properties.

Chief among these properties is the “Authorized-To-Lead” tag. The details of that tag contain the message “you have my consent to help lead the group.”

This is the A-tag.

 

Details Of Theory A

Coherent groups seek leadership. And so members send these “A-tagged” packets of respect to others, who receive them. The receivers may then either accept or reject these packets.

The packets are tagged with “consent to follow.” Tagged with “you have my permission to help lead”. Tagged with “you have my authorization, permission and support to actively help lead this group.”

This is the “Authorized-To-Lead” tag. The A-tag.

 

If I tag you, you receive it. You may ultimately reject my tagged send. The tag does after all come with some duties, doesn’t it? You make a choice, conscious or otherwise. Accept or reject.

If you accept my send, others notice.

Say your name is Michelle. My name is Daniel. Say we are in the same group. I send you some respect, tagged with the A-tag. You receive it, and accept it. This is a “from 1, to 1” send and receive. This send and receive is by and between a dyad– just two people.

We are in a group. Others in the group notice that “Daniel tags Michelle.” The others are observant, and independent agents… and so they each decide individually (consciously or unconsciously) what’s best… and what’s next… for them.

The options are:

  • Do nothing, or
  • Send some respect to Michelle, and tag it exactly the same way, or
  • Send some respect to Michelle, with different tags, or no tags at all

There are obviously some other interesting options, right? This is a concise summary, and so let’s keep it as simple as possible for now, shall we?

 

“Daniel tags Michelle.” Others notice and may respond. Note that no response is a response. There’s no time limit, and everyone, as always, does only what they want to do, consciously or otherwise.

If enough people tag Michelle with the A-tag,  and she accepts being “drafted into a leadership role”, then Michelle is now a de facto person of influence in our group. Someone with some special permission from the group.

Seems so simple, doesn’t it?

Not so fast.

 

Summarizing Theory A

Being tagged with authorization is very flattering to the ego, and can be the cause of many sorrows.

And not just for the “tag-er” and the “tag-ee,” but for the group as a whole.

In self-organizing systems with high levels of maturity, authorization routinely flows to where it can do the most good, in service to the group’s primary task. This assumes of course that the group has clearly identified the primary task– that is, what it actually wants. The primary task of a group can and does shift over time, causing shifts in levels of authorization– and coherent leadership.

***

 

 

 

 

 

 

 

 

 

Posted on

Return On Attention

Random thoughts bring random focus; intentional thoughts bring intentional focus.

Your attention- that which is being focused- is a scarce resource. We spend attention over the course of our day. In social interactions, attention takes on some aspects of a currency. It starts to look and feel like a store of value, and a medium of exchange.

“A fool and his money are soon parted”, says the proverb. Said another way, “a fool and his attention are soon parted.”

We may routinely squander our attention unintentionally. When we do that we receive little or nothing, per unit of attention spent.

We may “squander” or “leak” or “burn” some of our attention on purpose, for example, to relax. The fundamental difference here is the intention to do so.

When we intentionally choose to focus our attention on this or that, we receive more and more, per unit of attention spent. If we do this for awhile, we figure out that there is a clear “return on attention” that can be outlandishly positive. Over time, we can experience at least the potential to do more and more, with less and less, as we “pay” attention.

***

Related Link:

Attention Economy (link)

 

 

 

 

 

 

 

 

Posted on

Now What?

Regarding: The coach vacating the organization for at least 30 days following the 2nd Open Space in Open Agile Adoption.

The 2nd Open Space event in Open Agile Adoption (OAA) is a closure event. It serves to delineate the boundary between the previous chapter of organizational learning and the next one. It is the terminating point in the organizational passage rite that Open Agile Adoption is implementing. For the passage rite process to work, the organization must have a sense of “leveling up” or graduating.

Using a different venue and different Facilitator for the 2nd Open Space event is recommended. Making these changes avoids the feeling of a “re-run” and supports a sense of progress. The requirement that “the coach’s role must change” also supporting “leveling up” and a strong sense-of-progress and moving to the “next grade” or level. It supports feelings of graduation.

If the coach role does not change, there is a diminished sense of progress. The coaches role must change. The goal of OAA is to bring the organization to a state of self-sustaining, “freestanding” agility as soon as possible. For this to happen, diminishing the coach’s role and perceived authority with the teams is absolutely essential.

It’s important to note that, by vacating the organization for a time, the Agile coach is also vacating the role of Master of Ceremonies (MC) in the months-long passage rite that OAA is implementing. For that OAA passage rite to stick, it is essential that the MC role is temporary, and that it ends upon the end of the ritual itself. Passage rites by definition have an MC, and also by definition, passage rites have a beginning, a middle and an end. The MC role (in the canonical form of a passage rite) is temporary by design.

By vacating, the authority projected upon the Agile coach by the organization (as coach and as MC of the OAA passage rite) runs out of gas. The 2nd Open Space was yesterday. The coach has vacated.

The game is over. It’s JUST US. Now what?

 

On Vacating the Organization

I’ve done some experiments taking this concept one (radical) step further. Before the 2nd Open Space I now foreshadow that I am not available AT ALL after that event- no phone calls, no email– for 30 days. The idea is to get the org to realize that it is all alone– and always has been. And that it now has all the know-how (and everything else it needs) to continually improve…. without an “external authority” telling it what it “should” do.

I am pleased to report that this technique works very well. Amazing actually! The org realizes that it has learned a lot and initiates experiments to improve… all by itself. What they do takes on many forms. The org might make changes to existing meetings, and replaces long and poorly structured meetings with shorter, focused meetings. In one client a key manager who was an obstacle to org improvement felt the shift in the culture and quit. In general, the general tolerance for wasteful practices across the entire org decreases dramatically as the people who do the work come to enjoy taking action, being in control of it and improving their results.

So: IN OAA, the last act of the coach is to VACATE COMPLETELY for 30 days. Doing so punctuates THE END of something old, and THE BEGINNING of something new. Thereafter, the coach may reenter, in a new role, for example coaching just Scrum Masters, or just executive leadership. Vacating the org is an extremely powerful way to make the passage rite very REAL for the organization. As such, vacating for 30 days after the passage rite it is now incorporated into OAA and is a core and essential aspect of the Open Agile Adoption method.

 

Related Links:

“Rite de Passage”

Open Agile Adoption

Open Agile Adoption Components

 

 

 

 

 

 

 

Posted on

My Guru is Google

It’s a natural human instinct to be sensitive to authority. To want to be led.

Most of us are only too happy to have someone else tell us what we want, what we think and what we feel. If you poke around the web, in various communities, you can observe how certain participants actively contend for authority to lead.

This is changing, little by little. Each day, more and more people are waking up to the fact that THEY are their own authority. They THEY are the managers of what they believe and what they want. That they are at least passively authorizing (tolerating) some of what they actually disagree with.

By doing nothing at all about it.

For the younger people, this is not something to learn. Instead, it comes completely natural to them. The youth have been born into it.

The easy thing to do is to tolerate the lack of responsibility, the lack of sincerity and lack of stewardship from illegitimate leadership. The leadership you are (at least passively) authorizing.

The more difficult thing to do is to think for yourself- and demand more from leadership. To be highly selective about who– and what– you are authorizing.

Right now, there is lots of change in society, powered by highly intense technological change. With so much in flux, the leadership game has completely changed.

Technology and several others forces at play in society are encouraging– and almost instantly rewarding– independent thinking.

And that’s why my guru is Google.

 

Related Link:

The End of Guru Culture (link)

 

 

 

 

 

Posted on

The Mandate of Holacracy at Zappos

(Published on: March 04, 2014)

In case you have not heard, Zappos is rolling out a defined authority distribution scheme called “holacracy”.

The way everyone works will change. Every single employee will be forced to comply with a set of rules they had no part in creating.

Under this new set of rules, the people who work at Zappos must submit to (and are in fact compelled to participate in) the company-wide change. There is no “opt-out” possible, except to quit.

The change is a change in the way authority is distributed. This change is effecting every single employee. There is no escape.

Tony Hsieh is the CEO of Zappos. He wrote the book DELIVERING HAPPINESS. In that book, in the Appendix (page 233) he describes a “Happiness Framework” which states that people need to feel control and belonging (“connectedness”) to feel good and be happy. I totally agree.

And that’s why, unlike so many others, I am predicting some very major problems with the widely celebrated rollout of this new process change at Zappos…unless something changes quick.

Mandating a process change is a recipe for disaster. As a management consultant who makes a living helping organizations improve, I have seen it firsthand, working with lots of executive and teams inside nearly 100 organizations since 2007. My book THE CULTURE GAME tells many of these stories, and concludes: engagement is the name of the game.

Engagement drives everything, and mandates kill engagement. End of story.

The mandate reduces feelings of control, as the new way of working is forced on you without any regard to what you want, what you think, or what you feel.

This creates disengagement.

Next, the mandate comes from “on high”, from “higher ups”, and the decision is one you have no part in whatsoever.  Not participating in the decision generates very reduced feelings of belonging. No one wants to play a game that they have no part in creating. Good games have opt-in participation. Mandates don’t.

This mandate from authority creates disengagement and eventually, the very negative feeling of resentment.

These feelings of disengagement and resentment work against the process change. The people that stay on are unenthusiastic…they murmur, and drag their feet. Instead of engaged, enthusiastic people, the result is disengaged, unenthusiastic, resentful people.

Many of these people will be unable to name their feelings at first; they just know that something ain’t right.

Mandating process change is a bad idea because it makes people unhappy when their feelings of perceived control and a perceived sense of belonging are greatly diminished.

The other problem is the fact that the people working there are selected for “culture fit” with the 10 Core Values of Zappos. How does this new system of organizing support those 10 core values? This remains a very open question… and one that many employees are probably already asking.

Maybe it will work perfectly. A more likely scenario is:

  • Many employees feeling a low sense of control and belonging will eventually seek new jobs,
  • Zappos will hire new people to replace them, and
  • The entire org will be in a state of dissonance with substantial employee turnover for some time to come.

It does not have to be this way, and there is a very simple solution to this very big problem.

Here it is:

OpenSpaceAgility.com

 

About the Author: I am Daniel Mezick. I am a management consultant and expert on culture and employee engagement.  I am the author of THE CULTURE GAME and other books. Reach me here, at 203 915 7248 or email: dan [at] newtechusa [dot] net.

Whatever you do, don’t follow me…don’t follow anyone…as explained quite clearly, in this 45-second video: https://www.youtube.com/watch?v=jVygqjyS4CA

***

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Posted on

Capitalize We

In digital terms, culture is an application platform consisting of a core operating system kernel and associated components, modules and low-level applications.  This implies We can hack culture by screwing with these cultural platform elements.

The operating system, components, modules and low-level applications of culture are actually our stories and narrative. Thoughts become things, and stories are highly organized, memetic compositions of related thoughts. Stories are culture-things with structure and content. Changing culture is an exercise in selectively hacking specific stories— the essential modules and components that constitute the core cultural platform.

(You can learn more about culture, story, and language here.)

Computer programs are written in a programming language. The programs are stored on digital media. Cultural programs– stories— are written in a natural language. The stories are stored in your head. The stories are the cultural software in your head. The language you use determines how the stories can be told.

Well understood stories get memorialized in writing– in language. Languages have a vocabulary, a syntax, and some rules and conventions. Modifying language is a way to make a change (to refactor) all the stories in that language.  To hack culture, hack the stories. The most efficient way to hack all the stories (at global scope) is to hack the language.

There is a rule in English that says We capitalize “I” and not “We”. This implies “I” is more significant than “We”. Anyone can chose to capitalize We. In so doing, “We” gets on an equal footing with “I” in sentences composed in the English language. By capitalizing We, the signal in writing is that “We” is at least as big, and as important, as significant, and as valuable as: “I”.

“We” is just one example. Anyone can choose to hack language and see what happens. If that language hack of yours comes into widespread usage, the language changes globally. As language goes, so goes story and narrative. As story goes, so goes the culture.

To hack your culture, hack your language.

Capitalize We.

 

Posted on

Scrum Values

Genuine and authentic Scrum strongly supports the values of Respect, Commitment, Focus, Courage, and Openness. Genuine and authentic Scrum is in fact powered by these values. The good news is: you do not have to be perfect at them. Just do them now, as best you can. Good stuff happens immediately regardless of where and when you start.

Respect

Respect denotes both a positive feeling of esteem for a person or other person, and also specific actions and conduct representative of that esteem. Scrum absolutely supports and encourages respect. Without respect, there is no meaningful positive communication. Instead there is high potential for miscommunication, disrespect, low (or NO) communication frequency, and hurt feelings. Authentic Scrum requires respectful interactions.

Commitment

Commitment is the act of binding yourself to a course of action. Scrum encourages commitment. If you cannot commit, you cannot act. You are in a state of do-nothing limbo, a state of inaction. Scrum binds you to commitments. Genuine Scrum displays high levels of commitment. Authentic Scrum is not possible without everyone involved paying attention to and keeping commitments.

Focus

Focus is the concentration of attention. Scrum encourages focus. If you cannot focus, you are not paying attention in any meaningful way. If you cannot focus, you cannot learn to any meaningful level of depth. Authentic and genuine Scrum is always focused. Scrum encourages and requires focus to be effective.

Courage

Courage is a quality of spirit that enables you to face danger or pain without showing fear. Scrum supports courage. Often, truth about reality is obscured when no one has the courage to say it. Often, teams feel unsafe to describe reality honestly in the workplace. They are afraid to get fired or otherwise damaged for saying what everybody knows. Courage is necessary in Scrum. It takes courage to call out problems, identify impediments, ask for help, receive help, and offer help. In an authentic and genuine Scrum implementation, courage in evident in the way people behave. Courage is honored and encouraged in Scrum. Scrum without courage is Scrum that only goes so far. Authentic Scrum requires courage.

Openness

Openess is characterized by an attitude of ready accessibility (especially about one’s actions or purposes); without concealment; not secretive. Scrum strongly encourages openness. instead of asking “why should I share this information?”, ask: “why wouldn’t I share this info?”. Authentic Scrum generates a high level of ‘transparency’. Everyone knows everything about the work in a genuine and authentic Scrum implementation. Real and genuine Scrum displays a huge level of openness on the part of everyone participating.

 

Organizational Culture regarding Respect, Commitment, Focus, Courage, and Openness.

You may find yourself in an organization or team that does not value Respect, Commitment, Focus, Courage, and Openness. If you honor these five values, and “they” don’t, you are in conflict with the organization or team you are a member of.

A good policy for teams new to Scrum is to write the five Scrum values on a big poster and place it where everyone can always see it. After a while of attending to these values, things can start to get better with your team-wide interactions. If your company’s culture does not already strongly support these values, you may start to notice the difference when you are ‘inside’ and ‘outside’ your Scrum team. The main difference is in what is valued. Genuine Scrum shows you, right away, what level of value your company places on Respect, Commitment, Focus, Courage, and Openness.

 

Summary

The Scrum values of Respect, Commitment, Focus, Courage, and Openness.are part of the heart of Scrum.

A personal decision to live out the Scrum goals of Respect, Commitment, Focus, Courage, and Openness in all of your work, play and interactions can greatly improve the quality of your life. It does not take long. As soon as you do this your team, your department, division, organization and yes, even your world, gets better.

Take a shot at this. Consider implementing punctuality as an entry point into the world of Scrum values.

 

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.