Scrum, BART, Group Relations, Agile Boston, Boundary, Authority, Role, Task

This is a note providing 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.

BART Checkup

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

***

Click here to examine MORE AGILE NOTES like this

Click here to return to the Agile Boston home page

Click here to return to the Agile CT home page

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.