One question that seems to come up again and again, with unfortunately greater frequency given the realities of lay offs in the current business climate, is: "How do we use Scrum to measure individual performance?" The short, and admittedly unsatisfying, answer is: "We don't!" The team is a single unit in Scrum that succeeds or fails as a unit.

While the U.S. military has historically relied on size and strength, a small book issued by Marine General A.M. Gray advocated an alternative approach relying on speed and skill as force multipliers. Effective Scrum teams, with business-savvy Product Owners, have also learned to outmaneuver larger competitors.

Note that Marine doctrine is constantly revised, and people continue to debate which nails maneuver warfare is the right screwdriver for.
--mj

Attrition vs. Maneuver

"In contrast [to warfare by attrition --mj], warfare by maneuver stems from a desire to circumvent a problem and attack it from a position of advantage rather than meet it straight on. The goal is the application of strength against selected enemy weakness. By definition, maneuver relies on speed and surprise, for without either we cannot concentrate strength against enemy weakness. Tempo is itself a weapon, often the most important. The need for speed in turn requires decentralized control....

I've been using and studying scrum ever since I heard about it from Linda Rising 12 or so years ago. At it's core Scrum is a pattern language, and it's been evolving as people find better ways of doing things, and the patterns have changed. This post will give a very quick overview of what I've seen change.

On my Danube blog, I really try to stick to Scrum-specific topics that will help our clients, the software community, and other interested folks navigate the challenging process of Scrum transformations.

In an email intercepted by the Associated Press last week, GM North America President Troy Clarke said "In these unprecedented times, GM is reinventing every aspect of our business, including our organizational size and structure, to create a lean and agile company." I immediately started wondering what Clarke meant by "lean and agile." Ultimately, everybody wants a lean and agile company (and p

Everyone who was at Agile 2008 last year in Toronto probably remembers a dinner speech which poked equal fun at XP and Scrum enthusiasts with a punchline I don't remember about XP and one I do remember about Scrum. The punchline was "certification!" Yes, it's true - we Scrum professionals love our CSM, CSP, CSC, CSPO, and CSTs.

Genchi genbutsu sounds vaguely like "getcher boots on" and means "go and see for yourself." My Japanese fiance is currently translating Taiichi Ohno's original words in the book Toyota Production System for me, as the published English translation has some issues. But there's nothing like actually seeing it, as I did this week at Toyota's Takoaka manufacturing plant in Japan.

This plant makes about 500 cars per shift, two shifts per day. My first impression of the plant was that it looked nothing like a Toyota automobile! I was surprised to see a typical factory exterior with rust spots that clearly hadn't been painted in a few years. (Taiichi Ohno wrote "If you are not careful, seisou and seiketsu can just make you use up a lot of paint.") Also, could someone tell me why factories always have those slanted roofs?

Ambling Madly — the travels of a Certified Scrum Trainer
#5: Helsinki, February 2009

To my shame, on this trip I never left the hotel in the heart of (yes, very cold) Helsinki. Get there, eat, sleep, teach, write... go home. With no external input from the culture my mind stagnated, and I struggled to think of anything to write for this blog entry.

At Danube, we've long espoused the value of using relative, story point estimates over estimates based on strict chronology. We've written papers on why macro metrics are better than granular task based estimates due to the inherent uncertainty latent at the task level. And we eat our own dog food; the ScrumWorks team uses relative estimation units (labeled "headaches", for fun) in estimating stories/backlog items.

Recently though, a new team member (we'll call "Ed") was baffled by the team's estimation scale. Ed had trouble acclimatizing to our estimation scale, and at a recent retrospective he pointed out some major problems with the way our team seemed to be estimating backlog items.

I recently received the following question from one of my students:

"I manage a project using Scrum but the team is limited to 40 hours/week, not a minute more, due to contractual obligations. According to Ken Schwaber, Scrum relies on personal commitment - folks
will do what it takes to succeed. How do I best use Scrum in this environment?"

Situations like this are less than optimal, but not really rare, either. Contract programmers love to do what it takes to finish the job, but they will rarely do so without filling out that time-sheet with all the extra hours, either. That works OK if you're in a situation where more revenue is generated the earlier the work is finished. However, if the revenue is fixed and the time frames are variable, the additional expense is no one's friend.