In my previous blog post, I talked about how I believe a Scrum Master should be trying to put him or herself out of a job. Put another way, we should master the art of actively doing nothing. Some agreed; some didn’t. Some thought the language was too strong. Others thought it was just right. However, let’s put the debate aside for the moment and discuss what it means. How can a Scrum Master hand his or her responsibilities to the team? What responsibilities? When should this begin? First, let’s start with why. Why should a Scrum Master want to hand responsibility for the team to the team:
- To allow additional time to address organizational impediments.
- To cultivate an environment where team members are responsible and accountable to one another.
- To minimize the bus factor and create T-shaped people within the team.
As far as when, I think LeSS illustrates it best in this graph. At first, a Scrum Master spends a great deal of time with the team and Product Owner. However, as the team matures, he or she peels away to assist the organization in other ways. To read more about how LeSS views the Scrum Master role, click here and here.
However, more interesting to me is what. What duties can we hand off to the team? I’ve enumerated them below, and I’ve grouped responsibilities by ceremony for clarity. Once you’ve read through, feel free to print this checklist to share within your organization. It’s worth mentioning that I’ve never been successful at handing over all responsibilities listed below so consider this checklist a journey, not a destination.
Before we begin, a special thanks goes to David Novick for teaching me the phrase “actively doing nothing” to describe how we teach our teams a valuable skill and then observe and assist as they practice the skill themselves. Also, thanks goes to Bruce Nix for the idea of creating this checklist. I appreciate the inspiration.
Sprint Planning
- The commitment made is done so entirely by the team without coercion from the PO.
- The team can defend any work added to the sprint after sprint planning.
- Through discussion and experimentation, the team has identified a means to reliably predict the amount of work they can complete. Examples include commitment-driven planning and yesterday’s weather.
- The team facilitates itself by ensuring all members maintain the spirit of the agenda without Scrum Master assistance.
Stand Up
- Team members can reliably tell the team what others are up to.
- The team consistently talks about only the last and next 24 hours.
- More discussions occur after the event than during the event.
- Team members consistently update the task board before the event.
- Team members proactively engage with others in the organization to remove impediments.
- The team facilitates itself by ensuring all members maintain the spirit of the agenda without Scrum Master assistance.
Backlog Refinement
- Product Owner and the team work collaboratively to decompose stories and epics.
- Team members value the conversation over the estimate itself.
- Team members appreciate that an estimate is not an actual and embraces the idea that not all details are known at the time of estimation.
- All team members are actively engaged in estimating all stories.
- Stories consistently model all attributes of INVEST and contain acceptance criteria.
- The team exercises the last responsible moment when estimating and decomposing work.
- The team facilitates itself by ensuring all members maintain the spirit of the agenda without Scrum Master assistance.
- (Relative estimation only) Stories are compared against other comparable stories to determine an estimate without the need to convert story points to hours.
Sprint Review
- Team members answer more of our guests’ questions than the PO.
- Team members only show work that meets their Definition of Done.
- Team members can politely but effectively ensure guests stay true to the review’s agenda.
- Team members are delivering working software at least once a sprint (ideally, more frequently).
Retrospective
- Discussions are messy but constructive.
- All team members have facilitated the event.
- The team consistently leaves the event with at least one actionable item to address for next sprint.
- The team has embraced a culture of continuous learning and experimentation.
- The team has created metrics that important to them. The team reviews and discusses these metrics frequently as they experiment with new ways of working. Such metrics could include predictability, quality, happiness, among many others. (Read more.)
Again, I’ve provided a printable version of this checklist at this link. Feel free to share within your organization, and if it’s useful, I’d love to hear about it. Thanks for stopping by, and feel free to share your thoughts and experiences in the comments below.
Do you want to get notified when new posts are published? Leave your email below.
In theory, I agree that the ideal is that a team should work autonomously. However, as behaviorism suggests, all we do is based on carrots and sticks. That is, some reward or penalty controls what we chose to do or not to do. Behaviorism suggests that even behavior we label as “intrinsic” is controlled by external factors. For instance, we don’t take off our clothes in public because of the social penalty. Also, we generally smile and say nice things to people close to us, because it makes them do the same back to you and that makes us feel good.
In this context, it means that a team will eventually stop using Scrum ceremonies if it does not give the team a carrot or a stick. The Scrum Master is by definition the carrot and the stick, and in effect a team will stop doing what the scrum master did when the reinforcers are taken away when “handing over responsibility”.
If the goal is planning, standup, retro or review itself, chances are the team will not understand why they are doing it and potentially not understand the value. The goal is not do a stand-up, but (potentially) to meet frequently to inform, share and discover impediments. The outcome can be something different than stand-up – perhaps just turning the chairs against each other for 5 minutes two times a day. If that turns out not to work, they try something else.
The point is: When the team discusses what they want to achieve, the positive and negative reinforcements will be the necessary carrot and stick.
This means that the last principle in the agile manifesto is the most important:
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
If a company is truly interested in autonomy, they should invest their time in how teams work to constantly improve. This expecation is the first reinforcer that will drive team autonomy. Customer delight is the second.
I’ll borrow some thoughts from a few sources:
* McGregor’s Theory X and Theory Y (https://en.wikipedia.org/wiki/Theory_X_and_Theory_Y)
* Drive by Dan Pink (https://www.youtube.com/watch?v=u6XAPnuFjJc)
* Givers, Takers, and Matchers by Adam Grant (https://www.ted.com/talks/adam_grant_are_you_a_giver_or_a_taker)
I sense a great deal of Theory X in this sentiment:
“However, as behaviorism suggests, all we do is based on carrots and sticks. That is, some reward or penalty controls what we chose to do or not to do.”
Theory X works great in traditional shops who believe that a Scientific Management approach is most beneficial, but it falls apart in an agile domain. Agilists, by nature, assume a Theory Y mindset. They believe people want to work hard, and if that’s not happening, it’s because they lack the tools, skillsets, or the system encourages other behaviors. (I do concede that there are some lazy terds in the world, but we can weed those out there effective hiring.)
As to carrots and sticks, I think we may disagree what constitutes carrots and what constitutes sticks. Let’s assume what you say here is true:
“For instance, we don’t take off our clothes in public because of the social penalty. Also, we generally smile and say nice things to people close to us, because it makes them do the same back to you and that makes us feel good.”
If true, I’m curious as to your explanation of Wikipedia, a source of information used by millions but crafted by volunteers who contribute their thoughts and expertise at no charge and with little gain. How about Linux, an open source OS and utlized to power many of the world’s most powerful computers? As Dan Pinks video suggests, it’s mastery, automony, and purpose that motivates us. Carrots and sticks have their place but not in the creative space where free thinking and creativity is necessary.
I do believe that a team would operated more effectively with a Scrum Master there to guide them, but if a Scrum Master is fostering an environment of learning within the team (as we all should), the team members will eventually learn more from one another than from the Scrum Master. In other words, we’re the catalyst, not the reason.
I also agree with your sentiment around continuous improvement. I draw a great deal of inspiration from Lean in that respect. I also agree that sometimes teams lose sight of delighting the customer, and while the customer isn’t always right, it’s the customer who always matters. They don’t care what we call a story or if we’re using Scrum. They simply care that the product they’re using improves their quality of life.
I support my theory on behavioral psychology. I like Dan Pink’s book, but his view on “intrinsic motivation” is flawed. However, I understand the nature of why it appears that motivation is intinsic. But, we need to understand that no behavior (except reflexes) is automatic. Every single thing we do is by choice and require some type of thinking.
The names “mastery, automony, and purpose” are just names for behaviors we observe. Mastery is fulfilling the expectations of a task and autonomy is one or a group of people starting and finishing one or a series of tasks. Once we start to look behind the words, we realize what they truly are. Personality, for instance, is nothing. It is just a name for a set of behaviors. It is just convenient for us to categorize behavior in these names. The problem however, is when we make a categorical mistake.
Intrinsic motivation for instance, does not exist. Motivation is motivation. You can’t give motivation to someone and you can’t find motivation. There is nothing automatic here, you just make a choice and do it, that’s all.
When some people make more decisions and do more than others, we say they have “drive” and “motivation”. But in reality, it is just a behavior based on reasoning.
This is of course the type of behavior we look for in an interview, so it doesn’t really change anything. But whether you are a coach or a manager, it is important to understand the mechanisms behind behavior and avoid categorical mistakes.
Let me provide a couple of examples: Two siblings grow up with the same pair of parents, thereby the same gene pool and are brought up very much in a similar fashion. Yet they appear to have two very different personalities (or behave in different ways): one is outgoing and smart, the other is shy and take longer to develop language and physique. We have already categorized the siblings in different types of personalities. However, the categorical mistake is to assume that this is intrinsic and that they are born that way.
We learn that the first child slept 11 hours a day during pregnancy, while the second slept 20 hours. Already at birth, the first child has been exposed for almost twice as much stimulus as the second child. Also, we know that the first child is brought up without a sibling in his first years. These are potentially extremely important factors in explaining why a child behaves in a certain way, and not necesserily relevant to genealogy. The genes we inherit is only a starting point – all else is determined by external factors.
The second example is from a school class attending a visit to the local university. They visited the lobby, the library, the canteen, and lecture halls. At the end of the tour on of the students asked: “Now i have seen everything, but where is the university?”
The point is, we conveniently label behavior into categories. It will simply take too much time for us to list everything you find at a university or with someone we recoqnize with “drive”. But, you have to avoid the misuse of these categories and this is what behaviorism can teach us.
About your question on Wikipedia or Linus: There is of course, a gratification behind being the creators of this. They obviously had a problem and consequently an idea behind this, that gave them a positive reinforcer. The first users would quickly give them the gratification they needed. If you learned one thing from Dan Pink, it should be that we are not all driven by money.
Regarding theory Y and the “agile mindset”, you must first realize that people are different (you are already making a categorial mistake by saying X or Y by the way). Some people will want to work hard no matter what and some people don’t, but some of these might work hard on other things than the tasks they are assigned to at work. It is never a DO or DON’T in this, but we still draw up a convenient border line. There are always a number of reasons why someone does not work hard on a task list and you listed three of them. Also, remember that although Pink found that a statistically significant number of people perform worse with monetary enforcement, there is still quite a large group of people that are actually motivated by money, like in sales.
I was surprised by Espen Sjoevoll’s claim: “as behaviorism suggests, all we do is based on carrots and sticks.” This doesn’t describe me, or most of the software developers I know … not the ones I’d hire anyway. I got into programming 40 years ago because it was fun. Being on an effective team is fun also. So we naturally do what we’ve learned makes our team more effective.
I’ve never heard any psychologist claim that behaviorism describes the full range of human activity.
In theory, your list is ideal. However in the real world developing complex projects, it’s important for the scrum team do what they do best (the work) and the scrum master manages the flow, continuity and progress. I am a scrum master on a mission critical software development project and there are many facets involved in the success of the SDLC so it works more effectively for me to facilitate each ceremony and manage any outside interactions and needs. For anyone on the scrum team to step out to address an issue with an operations request for example, need a SFTP account set up, impacts them greatly from getting development work completed. Sometimes these requests take hours of discussing, making decisions, and defining and assigning action items to resources outside of the scrum team.
I know that world, Claire. I’ve operated in it myself for over a decade now. There was a time I’d agree with you, and in some contexts, I still believe you’re right. My blog post doesn’t suggest that we hand over *all* responsibilities to the team. As you point out, that would be ideal, sure. But is it realistic in all circumstances? No. Instead, it says hand over as much as you can to the team.
I wonder though. If you handed over the facilitation of some of your ceremonies, could you use that time to having conversations, making allies, and ultimately modifying the system so those arduous requests that take hours take less and less time until it’s feasible that the team make them? I’m sure it won’t be easy but would it be time well spent?