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.


The Next Big Idea

Posted by ewok_bbq under transformation, Uncategorized

A few weeks ago I came across a story by Steve Hartman of a man who rowed his boat from Alberta, Canada to New Orleans, Louisiana.  Dominique Liboiron went from Medicine Hat, Alberta to New Orleans, Louisiana by canoe.  This eight month journey totaled over 3,300 miles.  Unbelievable right?

View Larger Map

Why would a rational man do this? It was his way of honoring his best uncle Mitch who had recently passed away unexpectedly at the young age of 42.  You see, Mitch loved New Orleans.  After only a single visit to the City in 1992 Mitch reshaped his life around the New Orleans culture.  Dominique wanted to honor the memory of Mitch and realized after his passing that he needed to seize the moment and make his ‘someday’ visit to New Orleans today.  So, he got into a boat and rowed 3,300+ miles to see for himself what New Orleans was all about and deliver some of Mitch’s ashes to the city.
Today, after reading this think about what you are doing to inspire others around you? Would others follow you on twitter or would they row a boat for eight months to get to a place where they thought you were happiest in life to share the moment again with your spirit?  When trouble comes in business will your network walk away from you or will they put you on their back and help you get through troubled times?

For more on this unbelievable story – click on the video from CBS below.

Interestingly enough many social commentators (e.g. Dan Pink, Tony Robbins) now believe that making progress against a goal that is bigger than you brings happiness.
Tags: , ,


On Being Available

Posted by ewok_bbq under transformation, Uncategorized

One of the things I am thinking about and working on is the concept of being more available.

Over dinner, in Tokyo at the regional Scrum Gathering Cope,Julia, Kotaro and I had a great conversation. The premise was on the old saying, “you are either cheap or available.”   Basically, the concept is that if you or your services are cheap, then you are never available.  If however, you are available, then indeed you are expensive and valuable.
Emmanuel Lévinas[1] (French pronunciation: ​[emanɥɛl levinas];[2] 12 January 1906 – 25 December 1995) was a French philosopher and Talmudic commentator of Lithuanian Jewish origin.

Emmanuel Lévinas[1] (French pronunciation: ​[emanɥɛl levinas];[2] 12 January 1906 – 25 December 1995) was a French philosopher and Talmudic commentator of Lithuanian Jewish origin.

When I brought up to Cope that we need to be available he said that when he was with customers he was more than available.  Probably going back to some Emmanuel Lévinas theory of “the responsibility to the Other” Copewants to become one with his customers, to eliminate the a priori  instinct to separate the ‘us vs. them’ and to take on the being of his customers.  He can only do that when he assumes their organizational identity.  And once assumed he is totally emerged into being more than available.  I am sure his customers have benefited greatly from that.  More so then a conf. call from 5,000 miles away trying to spit advise into an unknown situation.
All to often over the past few years I haven’t prioritized my own work life around being available to those that matter most.  Looking back on it, I have, unfortunately, lived an interruption driven work life.  While running Danube, I was usually being interrupted by the crisis of the day or I was under the daily financial stresses.  It didn’t feel great.  Today – I probably take too many phone calls and am in too many conversations that don’t matter that much.  In addition, it’s easy to fool myself into thinking that I am adding value to meetings and conversation threads where my opinions are neither valued or innovative.   For an alternative, maybe I should try what Jurgen Apello does (could any one else get away with this?)
The side effect of being less available is that I can’t do what I want or need to do (e.g. being in a state of flow) or that I push off meaningful, yet less urgent conversations or thoughts, to tomorrow knowing that very well tomorrow may never come.
This year I think I am going to make a promise to myself to do less, but be more available to the customers, employees and friends that matter most. I will give more of myself to less things in an effort.
Is this just wishful thinking? What do you think? I would love to hear from you.
Tags: ,


Should Scrum Always Require the Product Owner to Attend the Sprint Retrospective Meeting?

Posted by under Agile and Scrum, Scrum Discussion, Scrum Transitions, transformation

[Editor’s note: this is a guest post from Michael James, not the owner of this blog.  The owner of this blog does not necessarily agree with any or all of the content herein.]


I’ve been talking with some Scrum trainers who’ve been working on a new definition of Scrum.  While Scrum already has a few simple non-prescriptive rules, the trainers are falling into the trap of converting their usual preferences into overly prescriptive rules.  For example, it is often beneficial for the team to include the Product Owner in the Sprint Retrospective Meeting.  There are also several circumstances (particularly when we’re first switching from traditional command management to Scrum) where this might not be the best thing to do.  After nearly 100 posts in the discussion, one esteemed fellow stated the root misconception:

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.

  1. 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.
  2. 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.)
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

It seems inevitable that the new Scrum definition will include a rule requiring the Product Owner to attend the Sprint Retrospective, and maybe this will turn out to be a good thing on balance.  The new definition should warn about the downsides of requiring the Product Owner in all circumstances, and offer suggestions to mitigate them.  For example, it should mention safety check procedures and breakout groups.




To learn more about invisible guns and safety checks, see the free Sprint Retrospective Meeting e-learning module:
Invisible Gun in the Sprint Retrospective Meeting




Comfort Zone

Posted by ewok_bbq under transformation

What can this picture tell us about getting outside of our comfort zone?

This picture is of Todd Carmichael.  According to the source of all that is true in this world [] Todd is the first American to cross the Antarctic to the South Pole unassisted, unaided and solo and is now the world recorded holder in terms of speed by an America. The picture above was taken of him shortly after he finished.  #LikeaBoss his official finishing time is now grained in ink across his bicep.  According to his own video journal the distance was 700 miles.  Why would he do this?  According to the documentary that filmed him he did this to emulate his adventure seeking hero’s of yesteryear.
In reading about Todd, and watching his new TV program I  can only think that this man doesn’t live inside his comfort zone.  Its clear that he’s really pushing the envelope everyday and driving himself to be better.
So as you think about getting going in 2013, take time to think about something really really big.  What will you build? How can you transform yourself? How will you innovate a new solution to delight a customer? What will drive you to be the best you can be?
I love to follow folks like Todd.  Anytime I feel like slacking off or giving up, I just think – what would Todd do? 🙂
Interested in learning more about Todd’s trip to the South Pole?  Check out the video previews below from Nat Geo.

Upwards and Onwards…. Go! Fight! Win!
Tags: ,


The Scrum Master Role

Posted by admin under Scrum Basics, transformation

ScrumMaster Checklist

The Example Scrum Master’s Checklist

Scrum has only three roles: 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. Likewise, the Scrum Master also is not a co-ordinator, because (by definition) self-organizing teams should co-ordinate directly with other teams, departments, and other external entities.

The best Scrum Masters are the types of people 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. Traditional project managers don’t always make great Scrum Masters, especially if they’ve previously managed the same team members. One problem I hear about from recovering project managers is that the teams still look to them for direct instructions rather than stepping up to team self organization. “Self organize, dammit!” But there are exceptions; some amazing Scrum Masters were once project managers. Perhaps it’s best to let the team and Product Owner decide who should be their Scrum Master.

What does a Scrum Master do? The Scrum Master removes any impediments that obstruct a team’s pursuit of its sprint goals. If developers don’t have a good sense of what each other are doing, the Scrum Master helps them set up a physical taskboard and shows the team how to use it. If developers aren’t colocated, the Scrum Master ensures that they have team room. If outsiders interrupt the team, the Scrum Master redirects them to the Product Owner. If the team has not learned how to develop a potentially shippable product increment every Sprint, the Scrum Master teaches them Test Driven Development (TDD), or finds people who can teach them. If the existing code is so bad that it slows down new development, the Scrum Master helps the team learn how to pay off technical debt incrementally.

As the team grows into a self-managing entity, the Scrum Master’s role shifts toward the organizational impediments, issues caused by the outer organization. If the company still has a “business side” and an “IT side”, the Scrum Master works to make each team cross-functional. If the team depends on outsiders, the Scrum Master must help transform the organization to use cross-component 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”).

Scrum Masters are full-time transformation agents, but they do not push for change. What do people do when you push them? They push back. Instead, effective Scrum Masters promote transformation through illumination and invitation. Conversations with executives don’t work without a background of relatedness. In established organizations, improvements come in fits and starts. Sometimes it seems like nothing is changing, then the organization has a breakthrough right when we were about to give up. This can be emotionally taxing, so I advise Scrum Masters to connect with a community of Agilists. Product development is mostly about knowledge creation and collaboration, but most large organizations would require fundamental changes before they could be called learning organizations. Skilled Scrum Masters read books about facilitation, persuasion, mindfulness, and what Marshall Rosenberg called “Nonviolent Communication.”

To understand the full scope of the Scrum Master role, see the Scrum Master checklist, which is referenced by several bestselling Agile books. The Scrum Master Checklist examines four questions effective Scrum Masters consider each day: How is my Team doing? How is my Product Owner doing? How are our technical practices? How is the larger organization doing?

In Large Scale Scrum, the Scrum Master role shifts over time from focus on the team to focus on the larger organization.

About The Author

This article was rewritten by Michael James, an Agile coach and Certified Scrum Trainer based in Seattle (but often found in other cities). Follow MJ on Twitter or LinkedIn.


The Scrum Training Series uses the voice of a real life Scrum Master to re-enact the kinds of scenarios Scrum Masters encounter, such as this Sprint Retrospective Meeting scenario.

Scrum Master facilitates the Sprint Retrospective Meeting