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

Crossing Over

Regarding: The passage rite…applied to organizations:

There’s a large body of knowledge in cultural anthropology that describes the utility of passage rites. Passage rites are designed cultural experiences- ritual events- that facilitate an individual’s journey in transforming from one social status to another in the society, family or organization.

Open Agile Adoption, to be clear, does NOT do this. Open Agile Adoption (OAA) is a designed experience for an entire organization, not the individuals. The individuals do not repeat DO NOT experience a change in social status.

Really? Then what the heck is actually going on inside an Open Agile Adoption?

What’s going on is, quite simply, a passage rite through which the entire organization is passing, not any one individual or subset group of individuals. It’s the entire living system that’s leveling up, not a set of individuals. It’s the entire tribe that’s graduating– not a subset of it. It’s the organization as a whole- the tribe, the living system- that is taking the journey from here to there. The “organization”, the “living system”, might be a division or business unit of a larger containing entity or enterprise. The fact remains: that entire subset- that entire living subculture– is going through it together. As a single living system. As a single entity.

While we may be able to find some support for this idea in the Organizational Development community, we will find little if any support for it inside the usual source of information on the subject of passage rites, namely: cultural anthropology.

Arnold van Gennep coins the phrase “rite de passage” and Victor Turner later elaborates on this and the concept of liminality…at the individual level. As far as I know there is little if any support in cultural anthropology for the idea of “tribe as individual” experiencing a rite of passage.

In cultural anthropology, going from here to there inside a ritual is always an individual journey.

Yes- others are also journeying at the same time.

Yes- there is communitas.

Yes- after a group of girls in a tribe experience the passage rite and are officially adult women, there are system or tribe-level effects.

That said, the idea that a family or a tribe or a modern corporation can “level up” by experiencing a passage ritual is a new idea. With no apparent support from cultural anthropology.

Or so it seems.

The reality is: this works. The organization is a single, living system. It has the attributes of a living system as described by people like Arie de Gaus (author of The Living Organization) and others. There is little doubt that modern organizations are complete and living systems. As such, they can be addressed as a single entity. And that’s the basis of many applied frameworks from communities such as the Group Relations and Organizational Development communities.

In this sense, Open Agile Adoption is really nothing new. The components are sourced from other disciplines. These components are well-developed and well-understood by the diverse communities who have developed them. Open Agile Adoption however, is a new composition of diverse parts that make something new. The components are: invitation, Open Space, game mechanics, the psychology of games, leadership storytelling, and the essential passage rite structure.

 

On Communitas

I’ve seen the communitas concept play out in living color, larger than life. That is, the spirit of community. Certainly participants at the same level of authorization experience this feeling and spirit of community, as they go through the shared experience of learning, and engaging in the difficult business of belief change.

That is not surprising. What is surprising is how people at all levels of authorization experience communitas when going through the passage-rite process of Open Agile Adoption. While roles and related levels of authorization vary widely across an entire organization, it does not seem to matter. Those going through the OAA passage-rite process who have lower levels of authorization understand that the “higher ups” are experiencing something too. And as the higher ups are transformed in their own way, via some stressful learning, they understand that all the participants are going to school- together.

This is what a great Agile adoption is actually made of- the spirit of community.

 

 

In Summary:

And so the question remains: does the ancient cultural device of the passage rite apply to modern organizations? Yes, it does.

Can the passage rite be utilized in service to getting the organization from here to there? Yes, it can.

I’ve seen it, I have done it, I am doing it. And I plan to keep supporting others who are doing it.  I’m grateful for the help of other professionals are doing experiments and sharing their experiences with the Open Agile Adoption technique.

Others are beginning to discuss and rapidly refine these ideas— and use them to solve very difficult problems. Like reducing the number of coaching days needed to achieve both a rapid and lasting Agile adoption.

To make enterprise Agility a reality.

 

Related Links:

Open Agile Adoption

 

Arnold van Gennep

Victor Turner

On Liminality

On Communitas

Arie de Gaus- The Living Company

Group Relations Community

Organizational Development Community

 

 

 

 

 

 

 

Posted on

Authority Explained

I told you before about the difference between authority and power. Now that we are holding these working definitions, we can drill down…and deconstruct authority in more detail.

I’m drawing from Group Relations work here, and providing actionable guidance for thinking about authority. I am purposely being minimalist here, providing the essentials only.

Remember, authority is defined here as “the right to do work“. Also, keep in mind that authority is always something conferred. It is given, and can be taken away.

Formal Authority

Formal authority is what is conferred when you occupy a formal Role, for example, when you become Treasurer of a non-profit organization. That role comes with a Title, and a collection of Tasks (“work”) you are formally authorized to do. Police for example are formally authorized to enforce the law.

Personal Authority

Formal Roles are well-defined in theory and actually have much more that is undefined and ambiguous. How far can I go? What are the limits of my authority around a task? Etc. It is here that your approach comes into play. Personal authority is your personally held, “perceived right” to do the work a certain way. 

The policeman that pulls you over can let you go without a warning. That policeman makes a decision about how to handle his role in a given situation.  That’s personal authority.

We are all familiar with ‘overstepping’ authority and the related dysfunctions of that. Like a policeman who tries to make you let him into your home when he knows for a fact that he can’t make you let him in, unless certain other conditions are true. That cop is attempting to over-step the formal authority boundary of a role.

 

Understepping and Overstepping

We are far less familiar with ‘understepping’, that is, not fully “taking up” a given role.

This is a bigger and far less understood problem!

When your sense of personal authorization prevents you from fully occupying your formal Role, serious dysfunction results. Why? Because you leave what I call “scraps of authority” lying around. If you do this on the job, for example as a Manager or Director,others are unusually quick at picking these these scraps up, and using them outside of the Role they are intended for– the one you are occupying!

The distortions created by this cause a range of organizational illnesses- a.k.a. “dysfunctions.”

 

Informal Authority

Informal authority comes without formality: without a formal Role and related title, etc. It is the authority that most of the others confer to you. Most of “the others” may or may not occupy formal, highly authorized Roles.  (Usually it is a mixture of people in various Roles.)

The source of informal authority is the willingness of others to have you do some specific work.

We all know of people who get loads of critically important work done, yet they do not occupy a “higher-up”,  formal Role (with formal authorization) inside the group. Yet these folks seem indispensable to how the team or organization functions.

What gives here?

Informal authority shows up as influence. It’s the conferred right to do certain kinds of work. It is conferred from others. It’s based on reputation, and a certain kind of willingness on your part. It is offered to you, and can be accepted by you…or not. It can be given, and taken away.

Summary

I just defined the following for you: formal authority, personal authority and informal authority…subcategories of “authority, the right to do work.” I hope you find these definitions useful. In the next post, I will deconstruct influence, that available-to-everyone, “always-on” ability to literally cause a shift or “change in state” in our socially constructed universes. I plan to discuss willingness, roles, and being “drafted” into roles…with and without your consent.

social construct:

a perception of an individual, group, or idea that is ‘constructed’ through cultural or social practice.

 

Related Links:

http://newtechusa.net/agile/authority-and-power/

http://akriceinstitute.org/displaycommon.cfm?an=1&subarticlenbr=34

https://twitter.com/DanielMezick

Posted on

Team Learning is Not Random

Team-level learning requires intent. Team learning, and group learning generally, is NOT random. If it was random or automatic, then our families, our teams, our organizations, even our societies, would automatically learn, and evolve. Instead, in terms of learning, we typically DEVOLVE in groups. We become ineffective after a while. That is what is automatic.

If we want to adapt, we must learn quickly as a group. Especially in times that feature lots of change, like the times we are living through right now. Organizations that learn faster than peers eclipse them, leave them in the dust, call it whatever you want. If we can figure out how to learn as a group, we have the secret to just about everything.

A valid question to ask is: why are we so dumb when we get into groups? Why do we design and implement soul-sucking interactions, stupid meetings, and ineffective team and organizational structures? Why do we behave badly? Why don’t we wise up??

One answer may be found in a community of folks called the Group Relations (GR) community. They are curators of a body of knowledge based upon the work of Alfred Bion. He developed a kind of depth-psychology for explaining what goes on in groups.

I attended a GR conference in 2008 and it opened my eyes. A pure experiential conference, the event focuses on the study of leadership and authority in groups. The object of study is the behavior of all attendees over a 4-5 day period.

Team learning, and group learning generally, is NOT random. If it was random or automatic, then our families, our teams, our organizations, even our civilization, would automatically learn, and evolve. If learning in groups was automatic, we’d be done with world hunger, and cancer, and war. We’d be colonizing other planets. We’d be done with poverty on earth. 

We get dumb when we get into groups. Period. That is what is automatic. Opposing this pattern requires full intent. My book is one small contribution to the body of knowledge around team learning. Team-level learning requires intent. The good news is, We now know how to do it. People like Jim and Michele McCarthy, Jeff Sutherland, Ken Schwaber, folks in the GR community … all of these folks are pointing the way. We can literally create genius teams- IF WE WANT TO.

We have the technology to routinely do this. The problem is conquered. 

What is missing is the intent. Are you in?

 

 

 

 

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.

Posted on

BART Checkup for Teams

This note provides a set of diagnostic questions with respect to observed BART (boundary, authority, role and task) properties on an agile team. I believe if enough agile/Scrum community leaders and members pay attention to BART analysis, the agile/Scrum work is advanced.

Specifically, BART analysis can help discover:

1. Important differences between stated and actual ground rules used by the team;

2. informal roles;

3. Informally authorized roles and tasks;

4. How people on the team are “taking up” formal and informal roles and associated tasks.

Canonical Scrum per the Schwaber-Beedle book and actual working Scrum implementations are great places to start with BART analysis.

Original date of note: 10/25/2009 by Dan Mezick

BART Checkup

BART properties populate typical “working agreements” that are created on agile teams over time. The following diagnostic questions help to quantify what is going on within a team.

Note that BART properties in Scrum are well defined as compared to typical organizational context; that is, typical company culture.

Teams deal in the BART properties of the organizational culture, the BART properties of Scrum and the emergent BART properties they add to form cohesive team culture in the absence of clear ground rules for a given role or task.

Teams for example may choose (via “working agreements”) to institute a working agreement about daily start time, perhaps allowing a flex-time scenario on the team. In terms of BART, this means team members are formally authorized by the team to choose their start time within agreed-upon boundaries.

ROLES

o Are all formally defined roles in Scrum taken up by specific individuals? Are all formal roles taken up appropriately? That is, well within role boundaries, but also taken up completely?

o Do any informal roles exist? If so what are they? Does the existence of any these informal roles impede the work of the team? If so how? Who is occupying any informal roles detected?

o Is any one person taking up more than one formally defined role in the Scrum implementation?

o If the team is an intermediate-to-advanced user of Scrum and for some reason has added additional roles, are these roles completely described?

TASKS
o Do all the team members exhibit great clarity and a shared mental model of the stated task of the team?

o Is there a person or persons available to the team who can distinguish all the different tasks?

o Does the team collectively believe that even repetitive tasks are unique as of the moment they are executed?

§ This means the team believes that every moment is unique, regardless of the seemingly familiar task at hand now.

AUTHORITY

o Is authority formally defined for each defined role?

§ If so, is formal authority:
· Clearly specified?
· Understood by all?
· Adhered to?

o Do team members:

§ Take up formal authority appropriately?

§ Do they work within the defined boundaries of the formal authority granted?

§ For defined tasks with unclear authority boundaries, how do team members define authority boundaries in the absence of formal definitions?

o What authority if any is observed associated with any informal roles that exist?

BOUNDARIES

o Are boundaries on roles, tasks and related authority:

§ Clearly specified?

§ Agreed upon?

§ Adhered to?

Fuzzy, ambiguous BART property definitions tend to encourage unconscious behavior at the group level.

Clear, well-defined BART property definitions tends to encourage the conscious attention of the team toward the stated task; i.e. producing “working software”.

Well-formed BART combined with Scrum’s ‘cadence’ via time-bounded Sprints (iterations) tends to entrain team-level production at the expense of team-level waste.

Advanced users of Scrum may choose to alter certain BART properties of Scrum. For example some may choose to add a ceremony, an artifact or a role to canonical Scrum.

That can be tricky. BART analysis can be useful for noticing how any tailoring of Scrum is affecting your effort at the Team level.

***

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.

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.

Posted on

Scrum, BART and Group Relations

This is a note explaining the connections by and between Scrum, BART and Group Relations. Scrum’s contains clear BART (boundary, authority, role and task) definitions. BART analysis comes from the Group Relations community of practice. Group Relations is concerned with psychology of some depth, at the level of “group”.

I believe if enough agile/Scrum community leaders and members get to know BART, the agile/Scrum work can advance. Specifically the community-level Scrum knowledge level advances as the study of Scrum’s BART properties increases overall insight into Scrum itself.

Original date of note: 10/25/2009 by Dan Mezick

Scrum

We all know something about Scrum. It’s a framework consisting of 3 roles, 3 ceremonies and 3 artifacts in its canonical form. The full description of canonical Scrum is listed in the reference links below.

BART

BART is short for Boundary, Authority, Role and Task. The full story on this is found via the BART reference link below.

Figure 1. Scrum is related to Group Relations (GR) theory through BART (Boundary, Authority Role and Task) analysis

Scrum is a great study in BART analysis. Upon examination of the roles in Scrum, per the Schwaber Beedle book on canonical Scrum, what is clear is that Scrum has well-defined BART properties. This greatly reduces the waste normally associated with any need to define roles and discover boundaries. The BART properties of Scrum are well documented in the aforementioned book.

Even so, Scrum does have some ambiguity in terms of BART properties. For example, during the Sprint, does the Product Owner stand up? If the PO is a fully committed PO, complete with daily co-location, does that PO recite during the Team’s daily stand-up?

Even with this, as ground rules go, Scrum shines in terms of BART, when compared to typical ways of organizing work, especially software development work, in a typical organization.

Group Relations (GR)

GR is concerned with the emergent behavior of groups, and group-level psychology of some depth. BART comes directly from GR work. GR conferences are concerned with the conscious and unconscious behavior of people who have membership in groups and organizations. Briefly, GR theory says that the unstated primary task of a group is to survive as a group. This under-the-surface task often motivates the group to seek leadership that can help the group with the unstated group-survival task. (see the links below for more info)

This unconscious and irrational leadership-seeking aspect is completely unrelated to the stated task, such as producing “working software”. It is usually in fact at odds with the stated task of the team.

Example: Consider the software project that has no end in sight.

As such, irrational GR effects have the potential to generate tremendous amounts of waste. GR and BART theory says that Scrum has well-formed BART which focuses attention on the stated task, leaving little or no opportunity for irrational team behavior.

Knowledge of GR effects can come in handy when participating in or observing group (team) life. Group Relations conferences are uniquely experiential and the learning can be unusual in form and content. The conferences explore boundary, authority, role and task in groups.

Links:

Book: Schwaber and Beedle on (canonical) Scrum

Scrum Guide from Scrum Alliance. Author: Ken Schwaber

The BART System of Organizational and Group Analysis

Group Relations FAQ

***

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.

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 [at] newtechusa [net]

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

Posted on

Group Relations Theory and Practice

This is a note regarding my strong interest in focusing the attention of the Agile/Scrum community towards Group Relations theory, practice and conferences.

I believe if enough agile/Scrum leaders simply do some preparation and actually attend a Group Relations conference, we can advance the agile/Scrum work. This is achieveable by raising awareness of how we act and react in often completely unconscious ways as we participate in group life.

Original date of note: 10/24/2009 by Dan Mezick

 

Application

Group relations work is mostly focused on issues of boundary, authority, role and task. My experience is that GR work in a GR conference setting is immediately applicable after you do it. GR work is concerned with depth psychology at the level of ‘group’ or ‘system’. GR work is not therapy but rather “here and now” experiential learning.

For example, I learn at a GR conference that people have an ‘orientation’ or ‘valence’ regarding authority. Some seek it …while others seek to assist the current authority. Still others have a ‘adversarial valence’ towards current authority.

At Agile2009, I meet Tobias Meyer and we discuss this. He reflects out loud and admits freely that he has a adversarial orientation towards authority. For him, questioning authority is comfortable and very natural.

Today I examine the blog post by Jean Tabaka entitled Escalation is Killing Agile. I notice Tobias Mayer makes a comment on this blog post. I notice also that previous to this, Tobias develops into a de facto authority, over time, in the Scrum community. Now the tables are turned– his noted authority in the Scrum community is now attractive as a big target for other individuals to shoot at.

Other examples abound, such as ….

“…What is it about discourse in the agile community? This year, I’ve encountered three examples of pushing back against incivility, blaming, and scornful, abusive language. -Diana Larsen, Agile Alliance newsletter, 10/19/2009

We can argue what precise factors or forces are at work. One thing is certain: we are at or near a defining moment. Old ways of thinking and doing as a community no longer apply.

Everyone Loses

We are rapidly reaching a state where a “lose-lose” outcome is a very real reality within our community. We are at a defining moment. We can choose to devolve into an unstable state where we spin out of control and implode. End of cohesive community: Everyone loses. This very real possibility is the result of a collectively held “zero-sum game” mental model that says “for me to win you must lose”. Do we all want to lose?? OK, let’s all keep doing that !!

A better result is to TRANSFORM into a new thing. That is what this community is trying to do, now.

To get there, we need a collectively held “win-win” mental model that says “I am invested in this community and if it self-destructs, I lose in a huge way. Therefore, for me to NOT lose, we ALL must win– by stabilizing this downward spiral right NOW.”

My current belief is that we all collectively do not YET realize that we need to slog though this defining moment to emerge on the other side as a new and different thing….a TRANSFORMED thing ….or self destruct at the level of “group”.

We can slog through this. There is a way.

I know this is Jean’s intention, as she says directly:

1. When everyone is trying to win, the system suffers. Anyone’s “win” is nobody’s win; and anyone’s “loss” is everyone’s loss.

2. I’m done with all the distractions that don’t feed my growth. I’ve lost the ability to abide behaviors that don’t give evidence of what was written with conviction in the Agile Manifesto.

3. My personal commitment is to seek those interested in creating more and more insights about how we can grow and learn.

Jean is a leader.

Enter Group Relations theory and practice

In the absence of clear ground rules, people in a situation must create or re-create ground rules. This occurs by testing the fuzzy and ill-defined Boundary, Authority, Role and Task definitions in a messy system. That is part of what is going on here and now and it is full of waste and more importantly, it is destabilizing.

For an example of how this works, think about Scrum. Scrum has clear BART definitions. This dramatically reduces ambiguity for all involved, and frees up precious team energy– energy that might be wasted by the testing and discovery of boundaries, authority, roies and tasks.

Scrum is a boundary-centric container for work– by virtue of clear ground rules. Energy and focus can now be focused on the work, rather than wasteful boundary-discovery tasks. The clarity of Scrum’s BART definitions are designed to honor production at the expense of waste.

We are at a defining moment. Most of what is going on– with any acrimony in our community now– is completely unconscious, and is operating at the level of ‘system’. We are ALL participating, now.

Group relations work brings this reality into very sharp focus. As such, knowledge of GR theory and practice can help– alot.

My Intentions

My intention is to bring GR work to the attention of the Agile and Scrum community, such that the agile and Scrum work can advance.

Below is an email with links that I send, earlier, to agile and Scrum leaders this week. Please consider studying the Tavistock primer listed below, and attending a GR conference– such that you can gain valuable new insight and experience in groups.

I am in contact with Group Relations community leaders, see below. My current belief is that raising the ambient level of mastery of GR concepts has the potential to help us reverse this very unstable state we are now developing as a community. Please consider learning more about Group Relations theory and practice. Links appear below.

Sincerely,

Dan Mezick (bio/profile)

(email sent to agile/Scrum community leaders 10/22/2009…)

Hello,

I am writing you to bring Group Relations (GR) and the GR community to your attention. I send it because you are a leader in the agile community and I am eager to bring this topic to the attention of the community-at-large.

As you may know, GR events are ‘conferences’ where the psychology of groups is explored.

Each conference and 100% experiential and unique. There are many dotted lines to agile thinking, including: empiricism, group collaborative process, systems thinking, retrospectives.

GR work is interesting if you are looking for answers to how and why groups behave as they do. GR conferences and present-moment, “here and now” focused. The Tavistock primer listed below is useful for understanding the conference format.

I am providing links to key documents and web pages to help familiarize you with GR work. I hope you might consider attending a GR conference. These conferences span 3-4 days, and usually residential and held at a retreat location. I hope you might consider attending a GR conference. My own experience of GR work is as follows: GR conference attendance is some of the best leadership/follow-ship training ever.

At Agile2008 and 2009 I speak on Group Relations and related work from the GR community called BART (Boundary, Authority, Role and Task).

My 2008 and 2009 sessions on these topics are here:

http://submissions.agile2008.org/node/3483

http://agile2009.agilealliance.org/node/2154

http://www.agile2009.org/node/2153

In 2009, I help out with the [Manifesting Agility] stage, incorporating‘ Psychology and Cognition’. Going forward, I am eager to see group-level psychology and cognition play a MUCH more central role in the development of agile practice and knowledge. I hope sincerely that the Agile2010 conference has a Stage for [Group psychology and Cognition].

Here are some links to familiarize you with Group Relations work:

BART: Boundary, Authority, Role and Task

http://akri.affiniscape.com/associations/8689/files/BART_Green_Molenkamp.pdf

Group Relations FAQ

http://akriceinstitute.org/displaycommon.cfm?an=1&subarticlenbr=34

Tavistock Primer

http://www.nycgrouprelations.org/pdf/TaviPrimer.pdf

For my part, I am busy evangelizing Boundary, Authority, Role and Task (BART) concepts inside our community. I am speaking on BART at local PMI meetings and also the GIVE THANKS FOR SCRUM event on 11/25 in Boston:

BART at the SNEC-PMI event

BART presentation link at SNEC-PMI

The GIVE THANKS FOR SCRUM event 11/25/2009 Boston

http://www.newtechusa.com/agileboston/gtfs

My session on BART and Scrum:

http://www.newtechusa.com/agileboston/gtfs#Dan

I hope you might consider learning about GR and attending a GR conference. I am eager to see group-level cognition and psychology get more attention from our community. In particular, I am eager to see these topics get a formally authorized Stage at next year’s conference.

If we want to create a conference event dedicated to agile community members, this is possible. I have experience speaking to leaders in the GR community about this. Leigh Estabrook is the President of the AK Rice Institute and she is willing to set this up for us, if we can get 25 or more to attend. It can be in any USA city. Other leaders in the GR community are willing to create private conferences and otherwise accommodate similar requests we may make.

Let me know if this is of interest to you. I am very interested in attending such an agile-only GR conference.

I am eager to answer your questions, and I hope you enjoy the provided GR links and subject matter. GR conference calendar links to conferences appears below. Shoot me a call or email if I may be of assistance to you as you explore the Group Relations domain. See the links listed below.

Please forward this email to colleagues and friends, as I am sure I miss many people who likely have an interest in this subject matter.

Please note the GR conference coming up in Chicago area in April listed below. I have experience attending events under the authority of this conference director, Kathleen Cain, and I attest to the quality of the conferences she runs. Chicago in April is a good choice if it fits your schedule.

I welcome your questions on GR work as applied to Agile.

Best Regards,
Dan Mezick
Cell 203 915 7248

Group relations conferences (near term)

NYC- 11/13

http://akri.affiniscape.com/cde.cfm?event=249887

India- 12/14

http://akri.affiniscape.com/cde.cfm?event=274178

Boston- 1/22

http://akri.affiniscape.com/cde.cfm?event=279880

Chicago- April 22-25

A Group Relations Conference
*Leading in an Environment of Complexity, Transparency and Conflict/
Kathleen Cain, LCSW, Director
Mark Kiel, Psych.D., Associate Director

Where: The Cenacle – A Retreat Center, Chicago, Illinois

When: April 22 – 25, 2010

Sponsored by the Chicago Center for the Study of Groups and
Organizations and The Midwest Group Relations Center of the A.K. Rice
Institute

Contact Diane Denes, dianedenes1@gmail.com <mailto:dianedenes1@gmail.com>

Baltimore- June 29 (Annual International Conference)

http://akri.affiniscape.com/cde.cfm?event=279911

Overall Group relations community calendar

http://akri.affiniscape.com/calendar.cfm

List of AK Rice affiliate organizations USA and worldwide:

http://www.nycgrouprelations.org/affiliates.html

***

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.

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.