The Scrum approach to agile software development marks a dramatic departure from waterfall management. Scrum and other agile methods were inspired by its shortcomings. Scrum emphasizes collaboration, functioning software, team self management, and the flexibility to adapt to emerging business realities.
For more on this unbelievable story – click on the video from CBS below.
One of the things I am thinking about and working on is the concept of being more available.
All the objections that have been brought up seem to me to be trying to work around the rather obvious impediment of someone acting badly.
No, that’s not it at all. I agree if the Product Owner (or anyone) is being a jerk, this is an obvious thing for the Scrum Master (and others) to fix. My concern is something much less obvious, and (in my experience) more powerful. As I’ve written it out below, I realize it’s also more complicated to explain than I first thought.
- It is normal human nature to overestimate what we are able to perceive about a situation. We never grasp the full extent of this because we lie to ourselves about the fact we lie to ourselves.
- As Keith Johnstone (the father of theater improv) also observes, there are no status-free transactions among humans. None. (By the way, learning theater improv is an exciting way to learn how true collaboration really works.)
- 99.9% of organizations designate material power to some individuals over others. I’ll call them “bosses” and “subordinates” instead of the various euphemisms. While most bosses don’t enjoy this, they are burdened with deciding which subordinates will be retained in the event of a layoff, which subordinates get promoted, who gets to work on the new sexy projects vs. maintaining the turkeys, etc. (Some bosses tell me they really hate doing performance appraisals.) The 0.1% exceptions (maybe Valve?) are probably past the point they need Scrum rules anyway.
- The people with the vision, authority, business acumen, and maturity to be good Product Owners are also often burdened by the organization with some boss responsibilities.
- It is human nature to assume others are feeling the way we are. For example, once before I ran a retrospective, a team member told me it was not necessary to waste time on a safety check because they were all very comfortable with each other. I did one anyway (anonymously, using a hat), which revealed some team members felt quite unsafe. Confident people overestimate the comfort of others.
- Combine all the above and you get the “invisible gun effect.” THE INVISIBLE GUN EFFECT HAPPENS EVEN WITH THE NICEST BOSS IN THE WORLD. It’s not caused by the boss’s actual actions, it’s caused by the way subordinate behavior is naturally distorted around bosses. It’s normal human nature, not something Scrum Masters can “fix” any more than they can fix gravity. It’s most visible to the lower-status people (which might include newhires, people with less impressive job titles, etc.), less visible to higher-status people (perhaps including senior developers, socially confident people, people with better technical skills than social perception skills, and Scrum consultants), and practically invisible to bosses who haven’t done an A/B test yet. Nearly everyone in the discussion had reduced awareness of the invisible gun effect due to spending the past few years in relatively high-status occupations: trainers, expert consultants, senior developers, Product Owners, business owners, authors, etc. The fact that all 104 messages in the thread were written by men might also suggest some blind spots.
- There is also what my wife calls the “chirping bird effect.” I once read that when a male bird is around, a female bird will feign incompetence at something she’d normally be able to do. My wife brought this up when I asked her how she was able to solve a problem with her computer — something she’d been bugging me to fix — while I was on a business trip. This effect is gender neutral: when she’s gone I have no problem with things I seem less able to do unassisted when she’s home, such as finding my car keys or preparing food for our kids. In class we sometimes get groups that keep asking the trainer for more detailed instructions, or help manage another team member. That’s often a good time for the trainer to leave the room! We can talk about self organization until we’re blue in the face, and they won’t really get it until we leave them alone — temporarily — to let them do it. I heard a story of one Scrum coach taking a nap under the table to get a team to step up more, and of Ken Schwaber standing outside the door of the team room during a Daily Scrum. I’ve seen teams have breakthroughs in self management when the person traditionally responsible for managing them left the room. I am inspired by the breakthroughs Scrum led to, especially among the lower status team members who aren’t well represented in this discussion. Team expecting micromanagement? Try management by leaving the room — temporarily. Of course we always hold the team accountable at the Sprint Review Meeting.
- Facilitators need to learn that when safety is low, smaller breakout groups often work better. For example I’ve noticed some people in Finland aren’t inclined to talk in front of a larger group (especially in English), but liven up in small groups. Once they’ve discussed some things in their small groups they’re more comfortable sharing with the larger group. The paradox here is that appropriate and temporary boundaries can actually increase transparency.
Posted by ewok_bbq under transformation
What can this picture tell us about getting outside of our comfort zone?
There are three fundamental roles in the Scrum method of agile software development: the Product Owner, the Scrum Master, and the team. The Scrum Master serves as a facilitator for both the Product Owner and the team. The Scrum Master has no authority within the team (thus couldn’t also be the Product Owner!) and may never commit to work on behalf of the team.
In Scrum, the Scrum Master demands a distinct personality type to succeed. The best Scrum Masters are real team players, who feel as much satisfaction from facilitating others’ success as their own. They must also be comfortable surrendering control to the Product Owner and team. For those reasons, traditional project managers don’t always make great Scrum Masters, especially if they’ve previously managed the same team members. But there are exceptions. Perhaps it’s best to let the team and Product Owner decide who should be their Scrum Master.
So what does a Scrum Master do? The Scrum Master remove any impediments that obstruct a team’s pursuit of its sprint goals. If developers are complaining about the high temperature in the team room, the Scrum Master must find a way to cool it down. If outsiders interrupt and distract the team, the Scrum Master must redirect them to the Product Owner.
As the team turns into a self-managing entity, the Scrum Master’s role shifts toward the impediments caused by the outer organization. If the team depends on outsiders, the Scrum Master must help transform the organization to use cross-component, cross-functional feature teams. If “Human Resources” policies (e.g. performance appraisals and job titles) interfere with intrinsic motivation and teamwork, the Scrum Master must educate the business about the harm caused by those policies (incidentally, agile advocates don’t refer to humans as resources).
To understand the full scope of the Scrum Master role, see the Scrum Master checklist.
posted by: scrum methodologyTags: The ScrumMaster Role
Scrum Training Series
- Scrum based funding model – 20 percent May 9, 2013
- The Next Big Idea March 5, 2013
- On Being Available February 17, 2013
- Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting? February 5, 2013
- Happiness Metrics January 23, 2013