Great Teams | New Technology Solutions

December 16, 2012

Culture Hacking, Organizational Permaculture & Kanban

I explained to you in a previous post how Kanban supports 12 of the 16 Tribal (team) Learning Patterns [1] found in The Culture Game Book [2]. That post also contains a link to an interesting post that connects Kanban to the Agile Manifesto’s 12 Principles.

Culture Hacking, Permaculture and Kanban

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

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

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

Kanban

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

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

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

Which brings us to the fascinating topic of permaculture.

Permaculture

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

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

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

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

Permaculture Principles

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

Source: Wikipedia Permaculture Design Principles [6]

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

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

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

The Organizational Permaculture Approach

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

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

You don’t lecture management on how they are old fashioned in their thinking, instead you put them into situations and give them tools where old ways of thinking are not sustainable and they have to act differently. If they work it out for themselves its sustainable.

You pick off areas where the pain threshold is the highest, for example (to pick up Agile themes) the interaction between approaches such as Agile and the measurement and management practices of the HR function.

You then create approaches that change the measurement and feedback mechanisms that work in parallel with existing methods.

Implications of Organizational Permaculture

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

Summary

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

Footnotes:

[1] Kanban and Tribal Learning (link)

[2] The Culture Game Book (link)

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

[4] Permaculture (Wikipedia entry) (link)

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

[6] Wikipedia: Permaculture Design Principles (link)

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

January 30, 2012

Story and Language: Why Do You Care?

Language is the code of culture.

Stories and narratives are core, platform applications that execute the cultural operating system. Repeat: The culture is the operating system, composed of the stories— the core applications. The language is the code used to create these core ‘applications’. If you have no stories, you do not have a culture.

Got that?

Dave Logan has all this covered in TRIBAL LEADERSHIP. You listen to the language- the code— of the stories you hear. That tells you the level of the culture. The level dictates what the culture can aspire to. What it can do.

What it is capable of doing. And being.

Example. You show up. People are talking in ‘We’ language and telling ‘We’ stories. That’s a tribe that can dominate their market space. That’s a tribe that can get to Stage 5 in the TRIBAL LEADERSHIP stage development model of culture. This Stage 4 tribe has the capacity to reach Stage 5 and be world-changing.

Another example. You show up and people are speaking ‘I’ language. The stories are all heroic in nature. He did this, she did that. I think this; I do that. Hear it? That’s Stage 3 culture. “I am great. (You are not.)”

This culture can function in a minimal way. It cannot change the world.

To change the culture, change the stories people are telling. There are many ways to do this. It’s not a trivial task. I explain some specific techniques in THE CULTURE GAME book. When you change culture, you change the stories. This is an axiom that does not change.

The culture is the operating system.

The stories are the core components and core applications that make up the operating system. They encapsulate what the culture means. This operating system is composed of stories.

The language is the high-level (story) programming medium.

Last thing: recall that the best computer programmer is up to 10X better than the average. This is ALSO TRUE for those who ‘code’ stories.

Interested in culture? Wise up about story. There is no better place to start than the web site www.GetStoried.com. That site has a boatload of tips, techniques and specific guidance on how to leverage narrative. The individual responsible for that site has PLENTY to teach you.

Michael Margolis is a brilliant man who knows more about narrative than ANYONE I know.

Tell him Dan sent you, and that you want to know how to get a bigger story.

December 15, 2011

What Kind of World Are You Building?

Jim and Michele McCarthy are the authors of SOFTWARE FOR YOUR HEAD, a book about structuring essential interactions inside great teams. There is one piece of this book, the chapter on the FarVision Protocol, which is very interesting.

It is as follows:

You work hard, burn out, and wonder why you bother.

You always play a role in creating the future, whether you choose to manage that role or not. Perhaps it is true of you that you can see no greater purpose to your work than supplying your own material needs and those of your company. Without purpose, you have a random effect on the future. That is, the world that results from your efforts is an accidental world.

Your team’s FarVision must answer this question:

What kind of world are you building?

The initial answers to this question are not always satisfying, because you don’t usually think of your daily activities as world building. When suddenly faced with such a question, you feel unprepared. You might avoid a direct answer. You might ask for clarification of the question. You might try to talk away the emptiness of your preliminary answer. Regardless of the response triggered by this query, there is real value in asking and answering the question, because it focuses the mind on the larger opportunities available.

If you are unable to directly and unself-consciously answer this question, you may want to examine why you don’t see the significance of your daily grind. Of course, the question of what kind of world you are building makes no sense at all unless you accept the implication that you are, in fact, building a world. Most of the time, of course, you may not consciously engage in the task of world building.

Nevertheless, your engagement in world building is a simple truth. You have beliefs. Every day you act on those beliefs. Your actions have external effects, and ultimately they cause your beliefs to materialize in the world. In essence, you change the world to look more like your beliefs. You build a world.

If you really are building a world, and if you are doing so unconsciously, you literally don’t know what you are doing. While you might not identify your purpose as the creation of a world, having a larger motivating purpose gives you a frame of reference for choosing alternatives. It is difficult to see how you can truly meet your daily challenges unless you bring a sense of purpose to each moment. Maintaining a broader purpose seems a necessary precondition of enjoying the highest levels of personal integrity.

To have integrity, your intention, your words, and your actions must be aligned. If you know what kind of world someone is building, and you are building the same kind of world, then you can work together on this goal, with much less noise and wasted effort cluttering the environment between you.

Like other team qualities, team integrity is the aggregate of the personal integrities of each team member, enhanced or diminished however much by the effects of the interpersonal synergy. The aggregate level of integrity has a positive correlation with desirable results.

Without a central purpose, an individual or team finds it impossible to make enlightened choices. Each day you make many choices. Before doing so, you check the alternatives against your larger purpose and envision how the alternatives might play out in the world you want to create. Wise choices, those that promote your world’s completion at reduced cost or in nearer time frames, are maximally useful to your purpose.

Even without the context of a larger purpose, you still must select from alternatives. Without an organizing purpose, however, your choices will be made according to whim and spontaneous, sometimes bizarre, and usually inconsistent motives. Inefficiency, apathy, premature cynicism, and failure result when individuals or teams make product design decisions in this way. The Core, on the other hand, provides you with a purpose template: to build a world.

Individuals, teams, and institutions have found that the most challenging, useful, and satisfying task is world building.

Many worlds and many kinds of worlds are possible.

CLOSING NOTE:

SOFTWARE FOR YOUR HEAD is a book. It’s available as a free PDF via the this link: Free PDF Book. The aim of the book is to focus your attention on techniques for structuring great interactions…in pursuit of creating great teams.

November 15, 2011

Kanban and Scrum are Verbs, Not Nouns

Is it just me? The Kanban community folks appear to encourage and be fond of bashing Scrum. This is unfortunate since the Kanban and the Scrum are so closely related. These are not distant cousins but rather, brothers. They both encourage a generative flow of We.

Positioning Kanban as superior to Scrum and vice-versa is contributing to a sense of meaningless around the word Agile. Agile is beginning to mean “whoever had the biggest ego and yells loudest. Whoever can grab the socio-apparatus of the Agile community (The Scrum Alliance, Agile Alliance, the conferences etc) to steer them. Whoever can advocate their position even louder and more convincingly.”

Exhibit A is the artificial debate between which is better for Agile teams: Kanban or Scrum. Yes, Scrum fails in some organizations and does not create much improvement in results. Kanban also suffers from these failures, typically in the same organizations.

In general, any failures of either are related to the culture in the implementing organization. In either case, Scrum and/or Kanban, the organizations doing the implementation need pain-killing drugs (commonly called a prescription) and a doctor (commonly called a coach). If they do not need a prescription or a doctor (to help them heal) they’d already be healthy, right?

Language is the Key

In the post The Flow of We I discuss nominalization, the act of changing verbs and adverbs (and other kinds of words) into nouns. Click the link to learn about it. We all do it all the time. It creates space to compare, contrast, disagree, and debate. Naming people, places and things is the primary way we make sense of the world we live in.

Scrum and Kanban are most useful to us in the English language when referred to as verbs, not nouns. We Scrum, and we Kanban. When we Kanban, We pay attention to the flow of work items through our group. We work with upstream and downstream partners to increase the flow of value. When We Kanban we increase the flow of We, by paying attention, as a group, to things that matter, like work items, classes of service, cycle times etc.

Likewise, we Scrum. When we Scrum, we first agree to some basic understandings, about roles and meetings and rules. Then We Scrum. When We Scrum, We open conversational space to discuss the actual details of requirements. We time-box most of these discussions. After We do some work, We reflect formally during a meeting We call “the Retrospective”. We also timebox this meeting.

Scrum is a verb. We Scrum. Kanban is a verb. We Kanban.

The Kanban community already realizes this, well below the level of collective awareness. What, you disagree, and do not think so? Guess again.

Check out this poster and slogan again, it says:

[Yes] … we Kanban. THAT is using the word Kanban as a VERB.

Post Script: 3 hours later, I already got three emails on this from folks out there. Moral of story: language matters.

November 15, 2011

The Flow of We

The goal of a good team is continuous flow. Continuous Flow of what? Some say, “value”. Not so fast. Value is a function of We.

There is a “state of flow”. We think of this flow as an individual state, where personal productivity soars as time passes very quickly for a single person, where that person enters a slightly altered state of consciousness. That is an individual concept.

Some are talking about how, in the industrial revolution, We measured productivity by the widgets-per-day count, and how We are now 100% out of the industrial revolution. So far so good. Now, these same folks argue that the new widget, the thing to measure, is something called flow. I totally disagree with using flow as the unit of measure of productivity, because flow as defined in pop-culture is an individual concept, not a collective concept.

In the modern world of work, productivity is a macro-property of teams, not individuals.

What really needs to be measured is the group-level flow of We or We-flow.

The Flow… of We

We is the collective sense that all of us (in the group) have substantial alignment, and that we all know what we are collectively doing. Alignment is the sense that We agree on some specific ideas, such as core values, that guide our collective and individual actions. So, flow is a pop-culture concept that applies to individuals. We is a collective sense. Flow of We is that flow of a collectively held sense of alignment.

Still with me? Flow of We is that exact same pop-culture individual-flow concept, experienced as a team. The flow of We has several subsidiary flows, or constituent parts:

We-Communication. This is the flow of Sending and Receiving at the level of We. It is verbal, and non-verbal. Think serendipitous interactions.
We-Knowledge. Knowledge flow requires We-Communication flow. This flow includes knowledge of the work, and each other.
We-Feelings. The flow of this social substance increases and can substantially accelerate flow of We-Knowledge.
We-Awareness. The flow of this social substance raises the level of consciousness of the group, resulting in more flow of We overall.

These elements manifest the overall flow of We. When one of these subsidiary flows gets clogged, the We-flow can suddenly stop. Reduced flows of the 4 elements above can literally stop the flow of We.

When it stops, it is a symptom that We have some fundamental problems with our team. Our sense of shared vision is diminished. This is what happens when Scrum and Kanban break down as devices. Scrum, Kanban and all the rest offer the possibility but not the promise of a flow of We. From the flow of We comes a nearly-guaranteed flow of insanely great products and services.

In the modern world of work, being great means being great with others. Greatness is being in the flow of We.

When the flow of We is continuous, you have a genius team. Jim and Michele McCarthy argue that average people can form a collective We-genius, at will, in the form of a team. I tend to agree. When you get there, you get flow at the level of team: time passes quickly, productivity soars, there is collective immersion.

The McCarthys often talk about how We no longer have to wait 30-35 years for individual geniuses like Einstein, Mozart, Freud or Jobs to show up and make a dent in the universe for us. Instead, We can make that dent in that universe right now, by building genius teams with currently available and well-understood socio-technologies like Core Protocols, Triads, Kanban, etc.

There are specific socio-technologies that can be used to increase the flow of We. These include Kanban, Scrum, Lean, Core Protocols and other practices with specific names.

Note that Kanban “Classes of Service” are a key device for generating both flow of We and the derivative flow of value so often discussed in Kanban circles. Likewise Scrum can help teams create insanely great products, by the same method: creating a steady flow of We on the team. Scrum encourages the flow of We through its mechanisms of the Daily Scrum, Retrospective etc.

This is somewhat stilted since Scrum has a start/stop nature by virtue of iterations. Thus Scrum is training wheels to help begin generating a flow of We in teams. Both Scrum and Kanban are used in teams and organizations with alignment problems. If they have good alignment, the We is flowing and in theory, there is no need for Scrum or Kanban. Since these flows are almost nonexistent on most teams, we must use these devices. When we do, we get some good results right away, but not because these are great technologies. Rather it is because our We-flow is nonexistent. The subsidiary flows of Communication, Knowledge, Feelings and Awareness are low or otherwise not working well.

Scrum, Kanban and other social/team technology is just the starting point. Remember, team learning is not random. You have to intend it. If you have no intent to learn together, you literally have no shot at doing so. Teams that want to be great find the coaches and technologies and techniques they require to achieve their aims. And often, the great coaches find them.

That’s just the way it works.

Related Post: Team Learning is Not Random

June 30, 2010

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.

October 25, 2009

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

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.