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


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,, and 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

Reach Dan at:

dan.mezick [at] newtechusa [dotcom]

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

Scrum Structure for Distributed, non-IT, Volunteer Efforts

Copyright (c) 2009-2010 Dan Mezick. All Rights Reserved.


Work is increasing distributed; Scrum can be adapted to fit. Some projects have these characteristics:

1. Distributed globally; it is unrealistic to assume that the people involved can get face-to-face time
2. Volunteers populate the leadership and teams
3. The work may not be related to IT or Software
4. The work has fuzzy requirements that are ever-changing and based on events
5. The work has the potential to dramatically scale up or down, meaning the total number of people involved must shift quickly to match

Projects like this need a flexible Scrum structure. The following Scrum structure can adapt and be flexible as the project scales up and down. The structure can contain the current workload and scale—up and down. We do not want to change Scrum structure all the time as the project shrinks and grows. We need a durable and lasting and effective structure. It must handle distributed, global, all time zones, non-IT project, fuzzy ever-changing requirements, and no known end date, all done with volunteers.

Proposed Scrum structure
The following diagram and text describes a candidate structure that addresses the challenges of a distributed volunteer project while remaining true to the Scrum values. This diagram depicts the largest scale and is fractal; that is, it can be repeated to any arbitrary size and scope.

Projects with the characteristics above need a flexible Scrum structure. The following Scrum structure can adapt and be flexible as the project scales up and down. The structure can contain the current workload and scale—up and down. We do not want to change Scrum structure all the time as the project shrinks and grows. We need a durable and lasting and effective structure. It must handle distributed, global, all time zones, non-IT project, fuzzy ever-changing requirements, and no known end date, all done with volunteers.

Please note that a more compact form of this structure is described at the end of this document. That more compact structure can be used as a starting point. As the project grows, it can grow in this direction. Click the link to see this more compact form, based on the Bioteams model.

This is a flexible Scrum form, that is durable at any size, from very small to very big. Thus this structure encourages shared understanding at all phases. This eliminates the waste inherent in having to negotiate a new structure every time the project changes in size, scope, up or down, etc.

Diagram notes:

a. Team Count. Topmost structure is bounded by green perimeter. It includes PO, SM and team of 7 or less members. This 7 is a rule to keep complexity low for the topmost PO.
b. Roles. The 3 Scrum roles serve to reduce complexity. Many roles, much complexity. Fewer (3 Scrum) roles, dramatically reduced complexity.
c. Top PO. The Topmost PO’s primary role is to a)see the big picture, b)make adjustments to direction based on that, and c) to at all times encourage and enforce values via positive and negative reinforcement of same. The top-level PO is/must be the key influencer of Culture across the entire project.


a. Culture. Culture is a collection of Values which inform the behavior of a group. Beliefs inform Values. Therefore Culture and Beliefs are linked via Values. The [Beliefs-Values-Behavior] needs to be constantly reiterated to the entire community of project participants. This is what makes the distributed worldwide effort cohesive and effective. Therefore, the Scrum values are key, as is reiteration, repetition and reinforcement of those values. The top level PO must embody these ideas.


a. Structure: Topmost Backlog is 7 Epics, each Team member owns one Epic. The red border depicts how each Team member is also a (sub)PO for a (sub) project, 1 per Epic.

4. 1:1 TEAM MEMBER:EPIC relationship, 1-to-1.

a. Each Team member is in turn a (sub)PO for a (sub)Backlog. The (sub)Backlog deconstructs the Epic into many Stories.
b. Topmost Team members play a two roles at two levels: Team member and PO for an Epic-based (sub)Project.


a. Iterations are two weeks long.
b. The topmost PO and SM run a weekly concall. This concall is in the daily Scrum format. The primary purpose of the concall is to track progress since the last call and to detect any “values events” since last call, to be addressed.
6. 1:M SM:TEAMS.
a. Each (sub)Project that addresses a single Epic is managed via a Scrum PO and SM. One SM can Scrum 2 or more projects. The area bounded in blue depicts one person occupying multiple SM roles across 2 or more projects. Thus, only 3 or 4 SMs are needed at the top.
a. (sub)PO’s are free to run the project as they see fit, consistent with Scrum values. Each PO has a SM and a Team.


a. Current items. Each iteration, PO prioritizes the 7 items. If backlog item X is topmost for current iteration, then PO says that. If X and Y need to be priority #1 and #2 on backlog for this iteration, with a 60-40 split, PO says that.
i. From there Team members figure it out, AFTER the call.
b. New Items. If a new item appears, PO places on backlog. Team figures out where it fall ‘under’. If it is a top-most item, one of the existing 7 must be folded-under-another to keep the count at 7.
i. The team figures all of this out during call but likely (and probably more effectively) the next day after thinking hard about it.
c. Item completion. When one of the 7 items is complete, it can be deleted to make room for another new item to add in to form the 7-max. As a top-most item becomes done or less important or nearly done, it can be subsumed by the existing remaining 6, opening up a new spot for a new item.
d. Summary. The topmost 7 items are adaptive yet highly structured with intent to dramatically reduce complexity for PO, who can now focus on the horizon and near-term effects without being overwhelmed.


a. (sub)Projects that become large may further subdivide, by taking on the adapted yet authentic Scrum PO/SM/Team structure, where each item on the backlog is an Epic, there are never more than 7 items, and each Team member owns an Epic and develops a (sub)Backlog. This is done as needed, as the project evolves in scope, magnitude and volume of work.
a. Not depicted in the diagram are the stakeholders related to each PO in the structure. Stakeholders may advise any any PO on any matter at any time.


a. Add Item
i. Items are held to 7, when a new item is added, it as appended to become 8. The team figures out how to incorporate the item to bring the count down to 7. How this is accomplished can take many forms. The team decides the form of incorporation of the new element in to the 7.
b. Change Item
i. PO communicates to team about the changed item. Team figures out how to incorporate the change to maintain stability of the 7 items while incorporating the change.
c. Remove Item
i. Done. Items may be removed as the backlog item gets done. A backlog item’s remaining few elements may be placed elsewhere, such that the backlog item is nullified. Takes the count down to 6 and makes room for a new 7th item. PO’s job as backlog owner is to notice the done-ness and communicate to team the perception that this backlog item is done. Team decides how to clean it up.
ii. Obsolete. Items may become obsolete. Events and situation may render an item so unimportant that does not just have a low priority, but in fact needs to be removed from the backlog to make room for a more pressing set of concerns. PO communicates the fact that the backlog item is obsolete; team decides how to close it down in a timely manner.
iii. Items may need to be split due to growth. In this case PO communicates to team the perception that a Epic is too big, and needs to be split. If there are now 6 items, this is easy since there is room for a 7th. If there are now 7 items, some items need to be collapsed elsewhere to make room. In all cases team works with PO to accomplish the split and related delete(s) that may be needed.
d. Prioritize Item
i. At the start of each iteration, PO prioritizes backlog. PO orders the 7 items and communicates to team the percentage of focus on each item for this iteration. Team figures out how to accomplish this during the iteration.
1. Typically, the iteration focuses on the top 2 or 3 backlog items. Each of these is assigned a percentage of the total effort, for example 60-40 or 50-30-20.
2. Top-level team members (1 of the 7) who have bottom-most backlog items for this iteration volunteer to the extent they are willing, to enlist as sub-backlog team members. The team figures this out.
3. Note that the entire focus of the team of 7 is on the topmost prioritized backlog items as communicated by the PO. This is pure Scrum, adapted to a distributed, all-volunteer, non-IT project.
a. Seven backlog Items, seven people: The team is always 7 or less people, each tied to an Epic on the topmost backlog.
b. Selection of the 7. Initially there are 7, selected according to some criteria. Once the 7 are formed and linked to the 7 backlog Epics, some process for rotating people out and selecting new people in to the team is needed.
i. Fluidity. The team of 7 work as a fluid team, working where they need to work per iteration,. This is based on PO’s prioritization. If my Epic is low-priority, I enlist as a member of the sub-team that is addressing the work for this iteration. Thus, I work with you (as a peer), I work for you (as a member of your team) , and sometimes you work for me as a member of my team when my Epic is the focus of the iteration. Note that this requires an advanced skills in teamwork and a real sense of team overall.
ii. Term limits. The top-level 7 team members probably need to have some kind of term limit, such that new candidates are constantly being groomed. This encourages a healthy, robust system of team development and a farm system based on accountability, mentoring and trust. The 3-rings of Accountability inherent in the Bioteams model is the preferred way of pulling this off. However each individual in the team of 7 may organize their teams in the way they prefer. Over time best practices emerge and everyone gains experience on each other’s teams, on a per-iteration basis. See 12.b.i.
iii. Core team, Extended team, Ancillary team. The bioteams model has 3 rings.
1. Core team. The Core team is the center and has the most authority and information and connection to sub-PO. The Core team takes direction from the PO.

a. Core team members are candidates for ‘team of 7’ membership on the top-most backlog.
2. Extended team. The Extended team has a little less authority, less information, and less direct contact with PO. The extended team executes on work that is largely prepared by the Core Team.
3. Ancillary team. This Ancillary Team has little authority, and little information beyond the detail found in pullable backlog items. This is the entry point for anyone that wants to come into the project.


3: Core team; 2: Extended team; 1: Ancillary team

a. Overview. The project can start smaller, with a team that has a bioteam structure, with the same max 7 Core team members, and an Extended and Ancillary team as outer concentric rings. In this compact form, there is one huge backlog, one top-level PO, one top-level SM, and one Team with 7 Core members. This structure can later scale up as needed.
b. Detail.
i. The bioteams structure provides an entry point, a “farm system”, and a progression of Commitment.
1. Entry point. The outermost Ancillary team is the porous entry point where anyone can probe the project by pulling backlog items. These items available to Ancillary team members are NEVER on the critical path.

2. Farm system. One of the 3 rings is the Extended team. This non-Core team layer provides the candidates for Core team membership and allows a rotation of Core team members.
3. Progression of Commitment. People who join the project can enter at the Ancillary Team level, prove they can do work, and then move into the Extended team, where they get closer to the Core, get more access to more responsibility, authority and information, and develop as candidates for Core team membership

BioTeams References:


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.


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?

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.


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?


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,, and 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

Reach Dan at:

dan.mezick [at] newtechusa [dotcom]

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

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


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 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.


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,, and 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

Reach Dan at:

dan [at] newtechusa [net]

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

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



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.


Dan Mezick (bio/profile)

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


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:

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

Group Relations FAQ

Tavistock Primer

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

My session on BART and Scrum:

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

India- 12/14

Boston- 1/22

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

Contact Diane Denes, <>

Baltimore- June 29 (Annual International Conference)

Overall Group relations community calendar

List of AK Rice affiliate organizations USA and worldwide:


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,, and 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

Reach Dan at:

dan.mezick [at] newtechusa [dotcom]

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