Scrum: The Necessary Conditions

[Originally published on ThePeoplesForum 8/5/13]

The previous post Scrum: a 5-step guide for managers was (quite rightly) criticized for not describing Scrum. It was never intended to. In the text I describe the five steps as being for “managers and executives for starting a new Scrum process”. The title was intended to challenge, to have people ask, so what is Scrum?

Scrum, clearly, is the thing defined in The Scrum Guide, a lightweight document, laying out the process, roles and artifacts of Scrum, and describing the value it offers. It is—happily—very low on prescription, beyond prescribing the basic Scrum framework. There is little in there to take issue with, and actually little that has changed from original Scrum. The problem is, with this and most of the books on the subject, sparse attention is paid to the environment in which we try to implement Scrum. To me this is key to success.

I recently witnessed a team implement at least the first four of the five steps I recommend. They were not “doing Scrum” and yet were closer to the values we seek with Scrum than many teams I have witnessed struggling to make the process meaningful with members in different locations, no clear product vision, team members working on different projects, being driven (and driven crazy!) by the electronic tracking tool of (someone else’s) choice, with all its rules and limitations. Scrum can sometimes create more pain that it relieves.

Teams that are not supported—environmentally, humanely, systemically—to do Scrum, will do Scrum very poorly. Teams that are so supported may not actually end up doing Scrum at all, but will likely have better results. This is my experience from the past nine years.

So my “5 steps” are intended to have managers and executives understand the necessary conditions for inspiring an effective, engaging process, whether that’s Scrum or something else. With such conditions met, I would usually recommend something that looks very much like Scrum, with perhaps a more continuous flow model á la Kanban. As always, context will determine the detail.

And if anyone doubts my own definition of Scrum, or feels it is out of line with The Scrum Guide. Please read Simple Scrum, an essay written in 2009, which still accurately reflects my understanding of Scrum.

Original comments can be seen here

Scrum: a 5-step guide for managers

[Originally published on ThePeoplesForum 7/31/13]


Scrum is really very simple. Here’s a 5-step guide for managers and executives for starting a new Scrum process.

  1. Start with a clear product vision—and a visionary guide (PO).
  2. Establish a co-located, cross functional team whose members between them have all the skills necessary to build the product. [1]
  3. Create a space for the team to work in, with plenty of wall space, whiteboards, index cards, tape and sticky notes. 
  4. Introduce the team to their stakeholders and users.
  5. Get out of the way.

Even without any Scrum training, you’ll find that your team is 75% of the way to having a highly effective process. The continuous improvement part will emerge, because people working in an autonomous way, with clear purpose, want to be the best they can be.

Starting Scrum is really is as simple as this. Why do we make it so complicated. Why is each of these steps so hard—especially step 5? 

[1] Start with the smallest possible team. Let the team determine who/what skills they need to add as they progress


Original comments can be seen here

See also Scrum: the necessary conditions

World, I am not a project manager

I’m invariably surprised how often I get contacted by project management organizations, who want to guest post on my blog, or engage me in some other way to help promote their tools and techniques. Even after twenty years of Scrum in our industry, where the project manager role is noticeably missing, there is somehow a perception that a scrum master and a project manager are the same role. Or that there is still a place for project managers in an agile process. There isn’t. Here, verbatim, is a recent exchange with a tool vendor. Names have been changed to protect the misguided:

Read More

A Community Library

I haven’t written much on this blog recently. In those rare spare hours between my full-time job, working on my second book, contributing to my local community, building a studio extension to our tiny house, and raising our wonderful baby (now nine months old) I’ve been building AgileLib.Net as a community platform for sharing agile resources with your fellow travelers.

Read More

My (somewhat) interactive “Thought Citizen” keynote given at AgileEE, Kiev, Oct 2013. There are some three minute silences where conference participants are engaging in dialog. Unfortunately, we can’t hear what they say. You could skip over those bits, or use the time to ponder the questions for yourselves :)

My “Business Craftsmanship” keynote given at Agile Spain 2013, Bilbao. The slides are not visible in this video so I recommend just listening to the soundtrack and following along with the slides available here.

thepeoplesscrum:

Dymaxicon publisher, Hillary Johnson, has written about our collaborative process in creating The People’s Scrum.

Read her article, The Lost Art of Disagreement:

image

"…Don’t believe anyone who tells you there is an ‘art of compromise.’"

What is work?

"Work is of two kinds: first, altering the position of matter at or near the earth’s surface relatively to other such matter; second, telling other people to do so. The first kind is unpleasant and ill paid; the second is pleasant and highly paid." —Bertrand Russell, In Praise of Idleness

I was reminded of this quote recently [ref], from Russell’s 1932 essay. While it was likely spot-on at the time, referring as it did to manual laborers, office clerks, and factory workers, I’m wondering how it holds up in the knowledge era. I can think of many who move (virtual) matter and greatly enjoy it—and are well paid!. Likewise, I can think of many managers, still perhaps better-paid than their “first kind” counterparts, but not necessarily finding their work pleasant. Indeed, as the agile mindset penetrates our organizations this role can be a very baffling one, and often fraught with fear.

Does this shift indicate a business-cultural revolution? Is this the start, or are we deeply within it? And what is good and bad about what we see today, and what Russell saw 80 years ago? Just some food for thought—okay, snacks :)

The whole essay is well worth reading too. It’s a classic of its kind, and I was happy to discover it online. I can imagine it influenced the work of Tom deMarco, and even more likely that of Ricardo Semler.

Big, Upfront Conferences

I noticed there is a Scrum Gathering to be held in Paris at the end of September. As I plan to be in Europe at that time I decided to submit something, but it turned out I couldn’t. Submissions were closed in March.  I started to wonder what that meant—an Agile conference, closing submissions six months before the event. I was worried about submitting something in the next month or two, knowing my ideas would have moved on by September. What kind of conferences is the Agile community running these days? Certainly not Agile ones.

Read More

Dysfunctional Commitment is a Good Thing

This post is a response to the excellent Dysfunctional Commitment post, by George Dinwiddie. For context I recommend you read that post first, including the comments.

The term commitment has had a lot of attention again recently, especially in the context of Scrum’s “sprint commitment”. There is disagreement about whether or not commitment is a good thing in the context of software development where the environment is usually very complex, and there are so many unknowns. Part of the disagreement is a semantic one. Commitment can mean both “a pledge or promise” and “engagement; involvement” (dictionary.com). Those who decry commitment tend to focus on the first meaning, those, like me, who believe commitment is a valuable principle for building healthy organizations focus on the second. 

Read More