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....

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?

The ScrumWorks Pro team taskboard is a wonderful ways to keep a whole team apprised of where we stand towards achieving Sprint Goals.

My friend Tobias has a requirements analysis exercise called "Planning a Party." I've used it twice this year already.

From the mailbag:
Michael,

User Stories seem to serve the same purpose as the user goal statements of use case analysis as implemented by Alistair Cockburn. As I'm sure you know this approach captures requirements at a high (sky), implementation (sea level) and sub process (sea floor).


The impressive thing about self deception is the way it covers its own tracks. That is, we deceive ourselves about how much we deceive ourselves. If I have amazing powers of observation, I might catch a fleeting glimpse out of the corner of my eye. Did you know only two percent of college students think they are below average in leadership ability?

One of our favorite self deceptions is denying how concerned we are with looking good.

There's a fun science experiment involving a cup of water, a sprinkle of pepper, and a bar of soap. You can try this at home, or at your local pub (if you normally bring soap to pubs...). Sprinkle pepper on the surface of the water, spreading it evenly. Then touch the soap to the surface, and watch the pepper zip out to the outer edge of the cup. The pepper's organization changes radically because of something barely visible, but quite influential -- the soap altering the surface tension of the water.

Improvisational theater guru Keith Johnstone and animal behaviorists have observed there are no status free transactions. (There are also no gender-free transactions.) Status is always there, often just below the threshold of awareness.

From time to time we see people complaining about Scrum and Agile being sold as a magic painless solution to all your problems. We can't seem to catch anyone in the act of making these claims.

So who's going around saying Scrum is a silver bullet, and that it's all you need? Ken Schwaber's not saying this; Danube isn't saying this; other Scrum trainers and coaches aren't saying this ... at least not when I'm around. We're all saying quite the opposite. I see more complaints about hype than actual hype.

Starting April 1, 2009, you will need to pass a multiple-choice test, in addition to taking a CSM class, to become a Certified ScrumMaster.

This step was debated in the Scrum training community. I was initially skeptical whether a multiple choice question could add any value. But I've become convinced this is a positive step after being involved with the process of writing test questions, doing peer evaluations of test questions, working with the ScrumAlliance's testing company (including a "psychometrician"), and actually taking the beta test in Stockholm (tying for the top score of 89 -- which isn't really fair since I'd seen a third of the questions beforehand).

A number of CSTs, including two from Danube, were involved in creating and reviewing test questions. Most of the questions that made the Stockholm beta are pretty good. Some should be discarded or reworked.

If only it were as easy as rocket science!

Writing fast reliable multithreaded software is a harder problem than rocket science.

A famous example of this was Therac-25, an X-Ray machine that occasionally killed people due to multithreading issues.

It's even harder now that we usually have multiple processors/cores running the same program.

Ken Schwaber and the rest of us advocate paying attention to what "done" means for a Product Backlog Item (PBIs, or "stories"). For a lot of programmers (like me), "done" often means "It works on my workstation!" The ScrumMaster is charged with advocating a "done" that includes everything else needed to build a potentially-shippable product increment.