Posted on

The Global Scrum Gathering Keynote: Paris 2013

I am grateful to have been invited into (and have accepted) the opportunity to deliver a plenary (keynote) address at the Global Scrum Gathering in Paris, France. The event runs from September 23-25 and the keynote is scheduled for Tuesday, September 24. I am honored to be part of this event with Henrik Kniberg and Dario Nardi, who also are delivering keynote addresses on Sept 23 and Sept 25 respectively.

You can learn about the 2013 Global Scrum Gathering in Paris here. If you click the [Keynotes] tab and then the right-arrow, you can examine the three keynotes, including the description of my talk.

I also list it here, for your convenience:

Open Agile Adoption 
The Agile journey may be best characterized as a rite of passage. Those who are taking the next step always do so as a group. During the journey, all the participants share the same basic status. Successful participants find themselves in a new and very unfamiliar place. And lastly, anyone who wants to complete the journey must also be willing to leave many things behind.

  • In tribal societies, passage rites from start to finish are facilitated and in fact led, by a “master of ceremonies.” What has changed?
  • Is the modern journey into agile actually a passage rite… for modern tribes?
  • Is the Scrum Master in fact the master of ceremonies in a modern rite of passage for teams and organizations?

In this session, together we explore the surprising answer. We also explore how to specifically leverage Open Space as a tool for helping to create authentic and lasting Agile adoptions.

I plan to explain Open Agile Adoption, an approach to implementing Agile that I have developed over a three-year period during which I have coached inside over 20 organizations. I have coached Agile since late 2007 and began experimenting with new approaches in 2009. At that time I noticed how some very intelligent people became disengaged during Agile adoptions. I began to ask why.

I began experimenting with the use of Open Space to help encourage more engagement, in service to rapid and lasting Agile adoptions. These Open Space experiments  generated some very surprising results. I’m grateful to the many organizations in and around Boston that have allowed me to experiment with sociological approaches to solving the Agile adoption puzzle.

Sociology First, THEN Practices

For my part, I value practices…because sound practices are very important. Yet solid, sound practices implemented with disregard to what people want, what they think and what they feel is, at best, misguided. It tends to generate disengagement.

I have learned the hard way, through experience, that the people who do the work are telling themselves a story. And that story is:

  • I get paid for thinking, and
  • I get paid for solving problems, and
  • I get paid for being creative.

That’s the story. This is one reason why it is essential to value sociological factors: if we mandate specific practices, the thinking and the problem-solving and the creativity that people bring to work is suddenly dampened. Squelched. Discouraged. Even killed off. Further, and more importantly, any sense of control is diminished. A sense of perceived control is essential for any sense of well-being.

Result: The prescription of specific practices becomes a topic for resentment…and eventually, disengagement. In my experience, it doesn’t take too long for people to “check out” on mandates and prescriptions. This disengagement is death to any honest attempt to bring improvement to an organization.

In Paris, I plan to tell you the wider story of Open Agile Adoption. The story includes many interesting people…and more than one courageous leader who took a legitimate shot of greatness with their Agile adoptions. I’ll tell the stories, and present several case studies. I’ll also provide a toolkit, free to the world… that anyone, anywhere can use to repeat the Agile adoption results I am getting.

I hope to see you in Paris. If you cannot attend, you can follow the Open Agile Adoption story on Twitter and here on my blog. As we head into September, I’ll explain more and more about the concepts and facilities of Open Agile Adoption. I’ll also explain the specific components, which are firmly rooted in sociology and cultural anthropology. On September 24 in Paris, I’ll present the actual case data and experience reports, and numerous testimonials on video.

More importantly, on September 24 2013, the date of the Paris keynote, I will make available to you and everyone, worldwide, a free, comprehensive, open-source toolkit for implementing a rapid and lasting Open Agile Adoption.

Frank Zappa, the offbeat musical genius, once said: “Without deviation from the norm, progress is not possible.” I believe he is correct.

I hope you will join me in learning more and more about the details of the Open Agile Adoption technique, incorporating Open Space Technology, as we head into September. You can stay up-to-date on my writing about it by bookmarking this link.

Posted on

Tribal Leadership and Scrum

In genuine and authentic Scrum, the three roles form a triad.

A triad is a super-small social structure with just 3 participants. These 3, aligned on values, commit to executing a very small strategy with intent to get results inside a very short time horizon.

Tribal Leadership is the book that introduces triads. It is a New York Times bestselling business book on business, leadership and culture. I’ve outlined this in an earlier post. The book is brilliant. The triad, is a 3-person social structure that is very small– and very robust. A well-formed triad is a powerhouse. Triads are capable of accomplishing absolutely tremendous results with just 3 participants, across very small time horizons.

If you know Scrum, this is sure to sound familiar….

My latest book, The Culture Game, describes in A-B-C terms exactly how to use triads to spread transformative learning across an entire enterprise. If Tribal Leadership is a cultural operating system, The Culture Game is an application. It provides a small strategy (a “microstrategy”) and leverages triads to spread it virally throughout the entire organization. I believe The Culture Game is the first of many such books that will be built upon the Tribal Leadership platform.

Triads are a key to the business agility problem. Genuine Scrum teams with the 3 roles of Product Owner, Scrum Master and Team exhibit a key aspect of Tribal Leadership’s triads: each role takes responsibility for maintaining the quality of the connection between the other two. This is the very picture of a healthy and well team.

In 2010, I met Dave Logan at Zappos. (Zappos Insights is one of my clients. Actually, one of my favorite clients. That is a truly great and amazing story for a detailed telling … at a later time.) Dave and I have many friends in common, and we became good friends ourselves.

In early 2012, I traveled to the Los Angeles offices of CultureSync, Dave’s management consultancy. I brought the 16 learning practices described in my book. We spent two days with the CultureSync team, doing work while using all the techniques in the book. The result was a delightful, laughing-out-loud kind of astonishment on the part of the CultureSync team. They loved it. My account of the details of the coaching experience at CultureSync are located here.

As a result of that meeting, we made serious headway in blending a very strong brew consisting of Scrum and Tribal Leadership. We kicked off a project composing elements of Tribal Leadership’s 5-stage culture model, the 3-person triad structure, and the 16 Tribal Learning practices described in The Culture Game. (The 16 practices are all derived from Scrum). I gathered these techniques over several years, by watching the very best Scrum teams I was coaching, and carefully noting exactly what the heck they were actually doing. From that, I developed a list…the sixteen things…

…I call them Tribal Learning practices. If you do them, you create automatic team-learning and a generate a genius team. All of these techniques are related, and conspire together to create team genius: in truth, a small learning organization. The Tribal Learning practices, derived from Scrum, are the ‘secret sauce’ in the recipe for creating a learning organization.

We can thank Scrum’s creators, Jeff Sutherland and Ken Schwaber,  for pointing the way.

Over a 2-day period Dave, the CultureSync team and I executed on brainstorming and planning around the re-mix: Tribal Scrum.  Incorporating essential aspects of both Tribal Leadership and Scrum, Tribal Scrum has the potential to transform organizations, one triad at a time. It’s all described in my book, The Culture Game, which you can purchase today.

Intrigued? The Tribal Learning practices described in my book provide the ingredients and the recipe for creating more learning, more fun, and a greater capacity to respond to change.

Tribal Scrum is a re-mix of practices distilled from Scrum and Tribal Leadership. Please join us as we embark on this adventure.

Join us in creating tools that managers and executives can use– right out of the box– to create effective learning tribes in organizations of all sizes throughout the world.

 

Background Links on Tribal Scrum:

Make Your Meeting Hyper-Productive and Fun article at CBSNEWS.COM

Tribal Leadership Book

The Culture Game Book

Tribal Leadership and The Culture Game blog post

Design Thinking: Composing the Tribal Learning Practices blog post

How Tribal Leadership and Scrum will change the world blog post

Posted on

Trans-Agile and the Learning Organization

The organizations that LEARN FAST are the new winners in game of business. They have more fun and make much more money doing it … by learning faster that their competitors, and then eating their lunch.

Let me explain.

Recently, I went out to LA to work with my friend Dave Logan at the offices of CultureSync, Dave’s management consultancy. Dave is  the lead-author of the book TRIBAL LEADERSHIP. This book introduces the triad, a very robust 3-person structure for getting amazing amounts of work done. This book also enumerates a stage-development model of culture in organizations. The book is brilliant– and so is Dave. My book THE CULTURE GAME is based in part on Dave’s TRIBAL LEADERSHIP concepts.

We did work over 2 days using all the tools in the framework outlined in my book, THE CULTURE GAME. In this book I lay out the 16 specific practices that create nearly-automatic organizational learning. These practices are derived from agile, mostly from Scrum. These are the “trans-agile” practices. I call them Tribal Learning practices. If you commit to do them, your group learns fast, and almost automatically.

The Scrum framework is actually an amazing learning lab for teams. Teams literally “learn how to learn” when the framework is implemented in a genuine and authentic way… that is, in alignment with the spirit of Scrum, as described in the Scrum Guide.

My book is an enumeration of the practices I see the very best Scrum teams doing consistently inside my Agile coaching practice. Part 3 of THE CULTURE GAME details how use Dave’s triads to socialize the 16 trans-agile practices described in THE CULTURE GAME  book.

 

Playing the Culture Game at CultureSync

There were 5 of us present. We spent two days together. We ended up using all 16 of the practices described in my book, across those two days.

We got LOADS of work done.

The CultureSync team made these comments during the daily retrospectives:

“What just happened is amazing”

“I cannot believe how much we got done in one day!”

“It’s shocking how much fun this was. How much fun this IS!”

“Normally, after a full-day meeting, I’m glazed over. The day is over and I actually feel super-energized right now.”

“I’m in shock about how these simple practices completely change the tone and tempo of our meetings.”

“Some of these practices seem uncomfortable at first, and then it’s like: why weren’t we working this way years ago?”

I want you to notice that CultureSync has NOTHING to do with information technology and does not develop software.  CultureSync sells management consulting services, and training that supports leadership development.

Also, keep in mind that Dave Logan is the co-author of THE THREE LAWS OF PERFORMANCE and is tight with David Allen, the celebrated author of GETTING THINGS DONE.

The CultureSync folks are a tribe of over-achievers, much like Dave himself.

That made the feedback especially sweet !

 

The Coming Revolution in Work

It’s ten years since the Agile Manifesto. In my book, I explain how the high failure rates in software projects actually spawned a solution, and a revolution: agile, and Scrum.

In the book, I explain what Scrum is: a framework for creating shared knowledge, also known as team learning. Scrum itself creates small, team-sized learning organizations as described by Peter Senge and others. The habits of good Scrum teams are group learning practices. Being punctual, facilitating your meetings, opening the space, structuring your interactions … as described in the book, each of these (and the other 12) encourage and support absolutely massive levels of organizational learning.

The time has come to say it like it is: Scrum and related practices create a learning organization. We call it a Team. When that Team gets really good, it exhibits 16 specific habits I call Tribal Learning practices. When these practices are socialized using triads as described in TRIBAL LEADERSHIP, the results are truly amazing. Your organization gets smarter, adapts faster, has loads more fun, and makes loads more money, often at the direct expense of all your competitors.

The trans-agile revolution has arrived. Enterprise agile is here. It’s called the learning organization, powered by the Tribal Learning practices described in THE CULTURE GAME book.

Looking to ways for your organization to learn faster? Be more adaptive? Interested in how this works? THE CULTURE GAME books ships in February. You can learn more and pre-order the book, by following this link:

Learn more, and PRE-ORDER The Culture Game Book

Posted on

Introverts and the Daily Scrum

Scrum is a framework optimized on greatness for teams, mostly software teams. Other complex, engineered product teams can also do well with Scrum. Most engineering teams are populated with introverted people. You can quickly identify the introverts: they say little or nothing when attending meetings.

These types of engineering-oriented teams are typically populated with left-brained, problem-solving introverts who get paid for right answers. I think Scrum actually adjusts for this via the second Scrum ceremony: The Daily Scrum.

Introverts find extended socializing to be sub-optimal for their personality type. Introverts do not like extended ‘blending’ and prefer away-time. Meanwhile, software and other complex products simply refuse to ship until and unless the people making the products get the teamwork figured out.

So, on the one hand, great engineers are often quite introverted. On the other hand, we all need to be working together and communicating effectively. Scrum handles this with the Daily Scrum meeting.

Notice:

1. The Daily Scrum is 15 minutes long. Yes, this encourages smaller team size. I also think is is kept short so even introverts can be comfortable with it.

2. The Daily Scrum encourages (introverted) team members to disclose essential info about the work. Introverts (and most other types) do NOT do this automatically.

3. The Daily Scrum repeats, is predictable, and not random or ad-hoc. This makes it easier for introverts to agree to participate in it.

The Daily Scrum makes it easy for introverts to show up, and tell the truth about the work…in 15 minutes or less. Brilliant!

A great article on the dynamics of creativity, collaboration overload and introverts is available below  from the NYT if you might like to do a deep dive on introverts and the Scrum connection. I believe Scrum is optimized for easy participation by left-brained, problem solving introverts.

This post is over. Way too much blending; I need my away-time. Nothing personal you understand. Talk to you later.

See:

http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-new-groupthink.html?_r=2&ref=opinion&pagewanted=all

Posted on

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.

 

 

 

 

 

 

Posted on

Scrum Values

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

Respect

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

Commitment

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

Focus

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

Courage

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

Openness

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

 

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

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

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

 

Summary

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

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

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

 

Posted on

Agile is a Game: Make it a Good One

A good game has 100% opt-in participation, a clear goal, a clear set of rules, and a clear way to track progress. Scrum has the potential to be a very good game.

The Scrum goal is “excellent results”. The Scrum framework rules are well defined, and are available in the current version of the Scrum Guide. And keeping score in Scrum is simple. We inspect the results at the end of each iteration, during the Sprint demo.

So, what is the missing ingredient to the good game recipe?

It is: opt-in participation.

We typically just hatch Agile on the very people who do the work. Is it any wonder we get push-back?

Agile and Scrum in the typical company is just hatched on the participants without any airing of what they want, what they think and what they feel. This leads to all sorts of problems. No one likes being compelled to do anything.

People Need to Be Heard

At NewTech, when we help a company adopt Agile, we sell and follow this plan: we do some training, and then we describe the use of Scrum as an experiment.

We do some iterations, saying, “we are trying Scrum as an experiment… so, let’s try it and see” .

Scrum as Mandate

You say you want self-organizing teams, yet you diminish any sense of control (and related happiness) with these absurd mandates-of-practices. You are telling people  “…we are going Agile. Scrum actually. Concerned? Confused? Let’s not go there. See you at 10AM at the stand-up.” Ugh.

Scrum is a un-satifying, not-fun game when you hatch it on people. You create automatic resistance because you kill any sense of control. People have to get heard. That hearing tends to make your Agile adoption a lasting one.

Don’t hatch Agile on people without a hearing. Doing so diminishes happiness by reducing sense of control.

We typically just go along, and proceed to literally hatch Agile on the people who do the work. This creates resistance. The result:  difficult, half-baked and yes, failed Agile adoptions.

Posted on

Scrum Language: the term Scrum “Master”

Here is something I get a lot when doing Agile coaching: I hear comments about Scrum terms and words. One of them is ‘Scrum Master’.

‘Master’ associates with acquisition of complete knowledge or skill. However, ‘master’ also associates with:

 

 

  • One having authority over another
  • One that conquers
  • One having control, especially over a slave or animal, also the employer of a servant

People who know Scrum know that the Scrum Master is supposed to be a servant, a servant-leader.

And that is the problem. Language frames reality.

Here is a term that refers to a servant as a ‘master’. I understand that Jeff and Ken mean the other kind of master, the master of a skill called Scrum. However, not everyone hears it that way. I know because I get comments on this matter and questions, all the time from Agile coaching clients new to Scrum. They are hearing “authority over”, “control over a servant”, etc.

Language matters !

Are you getting these comments and questions about the term ‘Scrum Master’?

Let me know.

 

 

 

 

 

Posted on

Punctuality and Scrum Values

Ken Schwaber’s book Agile Software Development Using Scrum has a section on Scrum values and explicitly lists five. They are Focus, Commitment, Courage, Openness and Respect. If you poke around on this blog you can find some writing I have done on these in the past.

Many organizations cannot do genuine and authentic Scrum. Why? Often, the reasons are the same reasons these organizations in general cannot execute on genuine punctuality. I notice that genuine and authentic punctuality instantly supports 3 of the 5 Scrum values: Focus, Commitment and Respect.

At a company where I am currently coaching, a VP-level leader implemented a voluntary opt-in Punctuality policy. You opt-in to the commitment. The policy is that if you are late, you pay $1 as a symbol of the culture valuing punctuality. Paying the $1 is an act that de-values tardiness;  it de-values “being late”.

An interesting set of dynamics immediately kicked in. There were many questions about ‘edge’ cases. First the definition of ‘late’ needed to be clarified. We discovered that the clocks throughout the building were all depicting incorrect times. These were synchronized. It was discovered that some clocks were slow and drifted to incorrect times after a few days. So a policy of using the time as depicted by the corporate network was used as the reference time.

Next the question of 1 second late came up, is this really ‘late’. 2 seconds etc. It was discussed and decided, yes, 1-2 seconds late is really, really late. being a bit early is the best policy, and encouraged.

Next the issue of ‘commuting’ from meeting to meeting came up. The operation spans several floors and each floor has like 20,000 square feet. So a policy of shortening meetings from 60 to 55 minutes was discussed.

But, since not everyone opted-in to valuing punctuality, this policy change was not simple to socialize throughout the organization and remains a problem to this day.

Next, the issue of meeting invites via Outlook scheduling was addressed. If you are invited to an Outlook meeting, the options are [Accept], [Decline] and [Tentative]. If you do not [Decline], are you obligated ?  This is an example of a fuzzy boundary and status. The issue was discussed.

A policy was defined that if you are invited, and do not explicitly decline, you are obligated to attend– on time. A policy about using [Tentative] was then defined.

As you can see, explicit examination is required for clarity in even the simplest policy definition for entire groups of people. It turns out that ‘simple’ punctuality is really not so simple after all.

Punctuality supports 3 of the 5 Scrum values: Focus, Commitment and Respect. These values associate with greatness in organizations. To be great, be great at being punctual.

It ain’t as easy as it looks. If your organization is not Punctual, you probably cannot do genuine and authentic Scrum. If on the other hand your culture strongly values Focus, Commitment and Respect, both Punctuality and Scrum are probably very simple to implement. At issue is “alignment” …..on “values”. These are very important concepts to grasp, for all organizations that intend to be great.

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.