Story Mapping is for Software

Story mapping is a very useful method for visually organizing the development of a software product. When we develop anything physical, story mapping ceases to be applicable and useful in the same way. Story mapping succeeds with software because software is intangible and can be constructed in almost any order. Software is only information. Both physical and software products can be described succinctly in the aptly named “elevator pitch.” Such a brief story can be implemented in software in an abbreviated path. Some input creates some output. Once it exists, a logical point in the code can be “widened” so that the point contains more complexity. If the rudimentary path can be demonstrated, each addition to that path can also be demonstrated. Refinement is everything and can be witnessed all the way.

Physical objects do not behave in the same way. I cannot create a real path through a circuit until some prototype of the circuit is physically built. Mathematical modeling is very useful, but it is only an approximation of the behavior of the real thing. Writing software is not modeling, it is the real thing. I can write instructions for building a wall, but the wall does not exist until it is built.

Story mapping involves listing major features of the software in some logical order. Typically the features are written on cards placed above a horizontal line, perhaps in the order they sensibly take following a work-flow path. Below the line, each major feature is decomposed (and described on a card) just enough that, taken from the beginning to the end, they form a “walking skeleton” of the software product. The logical flow of the product can be described, coded in rudimentary form, and demonstrated on a computer. Each element of the walking skeleton may be further decomposed as desired and written on cards that are arranged below their parent story. Another description of a walking skeleton is sometimes described as a rifle shot. A “rifle shot” through a proposed software product is a narrow path of functionality that includes every major group.

The horizontal axis of a story map is usually functional order. The vertical axis can be ordered in many ways, which gives the method it's power. Horizontally, one row of detailed stories can be assigned to each of the major user personas who will deal with the software. Rows can be assigned to software releases where everything in that row enhances the skeleton in the same logical way. Mapping elaborated stories in this way allows them to be arranged and developed in some strategic order. Commanded to produce the most valuable additional increment of user functionality with each sprint, the story map helps order work by business value. Story mapping as discussed here follows Jeff Patton's original description published in Better Software, January 2005.

Because the development of physical products proceeds differently, story mapping often leaves Product Owners in the physical domain scratching their heads over how to usefully apply the idea. Product functionality can still be arranged along a horizontal axis, but the order is somewhat arbitrary. We cannot order up a “walking skeleton” of our product from the machine shop. Product owners must create a strategic development path for each technology, each major feature. The concept of arranging product elements on a suitable coordinate system must be a bit more artfully applied.

The same objection applies to the "layer cake" and "sashimi" metaphors. With a physical product, thin slices are only sections and have no functionality or "business value" in Scrum terminology.

Rip Van David

I am applying Scrum in non-software product development. I believe, together with a few others, that Scrum is applicable well beyond software. So I'm right on the cutting edge. This is a progress report on what I have learned so far. Although right on the edge, I am not bleeding yet. But I have just started.

I worked for nearly twenty years helping very dysfunctional entrepreneurial companies recover. Then, perhaps when I was ready, I was fortunate to run a very small, highly productive design and build operation for a few years. Work had never been so much fun for me and for most of the other people involved. We had plenty of what Daniel Pink now calls prime human motivators, autonomy, mastery and purpose. We had the autonomy to work without intrusive supervision, the ability to grow quickly towards mastering our jobs, and we felt purpose in what we were doing.

Then I went off and did something totally unrelated for ten years. I became an electrician fixing problems on recreational boats docked in several LA and OC harbors. Then I came back. I thought I knew something about high performance teams and understood even more now about working with people. Scrum actually found me. A framework for creating hyper-performing software teams, Scrum basically creates a small cell of knowledge workers. Special conditions are maintained within that working cell where people are encouraged to manage their own work, learn more about their craft, and build something of recognized value. Wow, that sounded a lot like what I had done 10 years earlier. Autonomy, mastery and purpose. After some due diligence and training I was hooked. I studied until I thought I understood why Scrum worked.

Understanding "why" was important because I became hooked up with some Scrum radicals who thought the basic values and principles in Scrum could be applied across many different kinds of knowledge work. Scrum was designed for software and is almost universally taught together with practices that usually work in software environments. Be careful what you wish for. I recently landed a job as ScrumMaster appling Scrum to designing small, complex machines. Almost immediately I had to start modifying things. The practices in Scrum work well in software, but can be comically inappropriate in other contexts. I believe the values and principles will hold up and are the source of the benefit anyway.

In Scrum, the entire set of known potential features for the software is called the backlog. The backlog can contain many more features than actually end up in the software product. This is fine, because developers can work on any feature in almost any order. If you order the set of features by business value and start from the highest value end, by the time you run out of money you have the best features working and can throw away the less important stuff or save it for later.

Building a physical product, you also have a set of features. But the set is much more bounded. The device will or will not have certain features. You may have more flexibility changing features with a Scrum-like process, but physical items are not nearly as plastic as software. There is a set of features the product must have right from the very beginning. A toaster is not a television. It matters very much which features are developed in what order. You may still have a backlog, but prioritization is much more complex than by "business value." Prioritization is much more about risk. You investigate the mystery features first, the stuff you do not know how to do, the things that can be solved several different ways. It makes a difference. Most of the final cost of a product is determined by design decisions made at the beginning of the process. So, I'm modifying one Scrum practice heavily, with an unknown number to go.

I said I would be the ScrumMaster in this new job. The ScrumMaster is not supposed to voice opinions. The team decides how to proceed with the work. Well, those of you who know me suspect I will violate this rule right away. Maybe and maybe not. This is new territory and I have had to make some quick calls. But I can operate with a very light touch. I promise not to dominate the team. I really believe their combined expertise in the product area exceeds mine. But control of the process is the ScrumMaster's job. I'm just going to have to redefine the process a bit too. If I have an opinion and they don't think of it independently, I have ways to suggest just by asking innocent questions. This is definitely a job for an old dog.

Perhaps you know the story "Rip Van Winkle," by Washington Irving. Rip falls into some sort of time warp and awakes from a good night's sleep twenty years later. Rip has aged 20 years in what seemed to be a night. Everything in his community has changed and he is astounded by the difference between what he knows and the world he finds. Which brings us to me, Rip Van David if you will. The business world I left is not the same business world I have re-entered only ten years later.

In some ways the new dysfunctional elements developed while I was away stand out in very stark contrast. Some things are very easy to spot. I don't know how to deal with them yet, but I see both new and old dysfunction very clearly. I also see some progress, some issues seem to be less disabling. To those around me things are just ordinary. They may complain, but people have always complained. To me, some of the complaints are new.

What most worries me is stumbling over something I don't recognize as a problem. But I am older and a bit wiser. I am forging alliances quickly with people in positions to warn me about problems new to me. Some are domain specific. Some are related to changes in how businesses run. Velocity seems to have increased. I'm starting to read more widely than just Scrumology. I know I'm going to fall down at some point, but I've also learned much more about getting up again. I have become much, much harder to kill politically. Kill me? So what, I'll go sail my boat. In case you wondered, I'm having a blast. This is absolutely as much fun as where I left off. I was determined to settle for no less.

Elephant Scrum

What are we doing when we put “Agile” ideas into practice? Let's limit the discussion to a subset of “work.” With Agile, we are employing limited human resources in ways that produce the most useful, valuable, new thing. We are taking advantage of one particular set of instinctive human behaviors for solving mutual problems. Whether this set of behaviors is more biologically or more culturally based is irrelevant. There are some patterns of interaction within small groups of people that are extremely effective. I speculate that such patterns of behavior repeatedly and reliably produce optimal results because they have been advantageous to the survival of our species. They work because they have been refined over millions of years. Our existence is testimony to their utility. Your narrative may differ.

The modern place where people assemble to work is organized by habit and custom. As proof of the existence of these customs I submit that admittedly dysfunctional working conditions and methods are much the same in many independent organizations. These organizational patterns developed for many reasons other than to create the best products. At worst they result in a group of people appearing to have a common purpose but spending most of their energy doing something else. Often that is fighting each other: Competing for limited rewards. Dominating and resisting. Passive and aggressive. Shifting alliances. Lying and betrayal. Illusion and misdirection. Smoke and mirrors.

For my purposes, “Agile” is about doing what really works to solve business problems based on fundamental small team dynamics. The team becomes an organism much more effective than all of it's members operating in parallel. The team can become “hyper-productive” with perfectly ordinary individuals. If you have never experienced hyper-productivity nothing I write will re-create the experience in your imagination. I ask that you suspend disbelief and resistance and ride with me for a while. Work does not get any better than hyper-productivity. Been there, done that, want to do it again. Want to teach you how to do it without me. Having done that before, having former associates create their own, I can say it's very satisfying.

Hyper-productive teams can be quite fragile if they are not knit together by kinship, religious, political, sporting or similar external ties. This is why we see them so seldom in modern life. Perhaps that is why we like observing team sports. Good teamwork beats all-stars. Clearly the dysfunctional behavior outlined above is utterly poisonous within a team. Good teams can be structured around a leader, but the best teams are collaborative and require no day-to-day leadership. This is partially because really effective leadership is harder to learn than collaborative teamwork. The most effective leader virtually disappears. The easiest way to disappear is never show up in the first place. In collaborative teams, everyone leads, everyone follows.

Work teams are rewarded for fulfilling someone else's vision. If the vision originates within the team, then it is not work, at least not the kind of work most of us do for our livelihood. Scrum is one approach to providing the structure and safeguards for hyper-productive teams to work fairly reliably on vision originating elsewhere. Since every team and every vision is different, Scrum is structured empirically. As the team works within the Scrum framework, they adapt their process (how they work together) to best fit their circumstances. The team periodically adapts it's work direction to best fit their customer's evolving vision. A role is established, Product Owner, to represent and focus the customer's vision. Another role is established, ScrumMaster, to keep the process on track, to be responsible for all the people stuff, and to keep the team thinking hard about what they are doing. The ScrumMaster role does not require being expert in solving these problems. It requires noticing “impediments” to hyper-productivity and mobilizing resources to remove them.

Scrum establishes a minimal framework necessary to protect the team from internal or external dysfunctional behavior. There are certainly other effective Agile frameworks. Scrum is simply what I know best. Nothing is included in Scrum that is unnecessary. Scrum is one complete idea. You cannot pick and choose the Scrum practices you are willing to do upfront. If you never get to hyper-productivity please do not ask me why. Are you actually doing Scrum or something equally complete and effective? Did you cobble something together and call it Agile? How are success, knowledge and courage coupled in your head?

Scrum as described within the past fifteen years is mostly about software development. Because Scrum is really about hyper-productive small teams in the workplace, it is much more widely applicable. Because it is empirical, Scrum will find a way to be useful implementing vision in more places than we can currently imagine.

You could successfully hunt elephant with a Scrum team using handmade tools the team creates, and that is not the least bit coincidental. If men hunted this way, you can bet the vision was from their mothers and wives.

Tobias Mayer

What a wild year for Tobias Mayer. Perhaps most are, but this is the year I came to know and appreciate Tobias. I sought out Tobias for my CSM training because my closest Scrum contact, Scott Dunn, did his training with Tobias. Lucky for me given my then state of unemployment, I was able to complete Tobias' signature Welfare CSM training in early February 2010. Since that time I have been close enough to Tobias' orbit to keep my special Tobias-tan. I saw him last at the Phoenix Scrum Gathering in October. I am just getting used to working within Conscires Agile Practices, the creation of Bachan Anand, another being in the Tobias Orbit. Bachan is executing on a vision that may be at least as outlandishly idealistic as Tobias'. I'm not certain because my comparison scale is being pushed well past my previous work and life experience. Gaining a new lease on youthful hope at my age is disconcerting.

There are times I thought Tobias' idealism pushed him a little over the edge compared to my version of common sense. Generally I was correct in this, and I benefited immensely by his example. Tobias is a moving beacon, one fixed point of principle against a shifting landscape of co-option and compromise. At their best, idealists are like this. Tobias must have "feet of clay" somewhere. It makes me just a little nervous I haven't spotted them in any area that really matters professionally. You may bring me the hemlock when Tobias sells out.

I don't really understand how either Tobias or Bachan believe what they apparently do, but I consider myself extremely fortunate to have an opportunity to execute a small part of their vision in the work I am just starting. Without them and the mentoring of Lyssa Adkins, I might not dare believe I could succeed in my own, more limited vision. I am going to extend my personal experience of collaborative, cross-technology, high performance humanistic work to the organisational level. I'm not nearly as idealistic, but I have a career's worth of relevant experience and only the Reaper is going to stop me. Since Welfare SCM 018, I have spent nine months training, reading, and adjusting my attitude. I am ready.

I have no idea where the entire package of issues regarding the Scrum Alliance, certification and the like will go. I would simply observe that we can now communicate and organise independently and we will. I'd like to see the SA funnel it's cash horde in more ambitious, idealistic directions, but it really does not matter. When some nexus of ideas creates positive business results directly from more humane, collaborative work environments, a stinking million here or there isn't going to make much difference.

I wrote a letter of recommendation for Tobias mid-April, 2010. With him backing away from the CST certification, this is what I thought of his skills in my training. This is piling on, really, as there must be as much praise and criticism of Tobias published as anyone needs. So I'm actually reproducing this for my pleasure as I thought it was a good letter. Ah, honesty.

Training: WelfareCSM-018, February 4-5, 2010.

To whom it may concern:

I highly recommend Tobias Mayer's CST work based on my experience as his student. The sessions were lively, interactive learning experiences for me and for every other participant I talked to. Tobias organized and conducted the entire class with sticky notes and a taskboard plus a number of flip chart illustrations he drew as required. Tobias clearly came from a place of intimate understanding rather than a slide deck.

Tobias intensely engaged in getting us to view potential workplace activity from a Scrum mind-set. We spent much time in games and exercises. The benefits of these exercises were not immediately clear to many in the class. Virtually all came to realize the exercises helped us instantiate productive collaboration. We experienced the power of jointly solving a shared problem.

Tobias presented Scrum as a set of ideas and behavior that apply well beyond software development. I was familiar with basic Scrum based on a close study of the readings. (Incidentally, he didn't leave anything out.) Tobias challenged me to think through how Scrum might apply in other contexts. That took work on my part, but it deepened my understanding beyond elements, artifacts and ceremonies. Tobias Mayer made me think Scrum rather than simply remember what it looks like."

The Spider in My Head

I've been trying to write all day. Two starts on what could become two posts are now filed away. Now I'm here at the computer and we'll see who wins. Win? Well, this debate has been going on in my head all day about something I felt passionate enough about to write about. I thought this was going to be about Julie, or it could be what it looks like being in my head. The second has lots of possibilities. But I will not know who is going to win for perhaps another hour. I'll just sit here writing and one of the stories will pop out nearly grown. No penalty for losing first place for publication. They'll keep coming out until they don't. I will go back and edit this beginning so it doesn't clash. The continuity thing. I'll invent stuff to tie the start and middle closer together.

Question: Is it better to stop and correct the finger mistakes at the time or roar along and catch them later? Answer: It depends. I usually correct things pretty quickly, which gives me an opportunity to take anything really clashing that's not supposed to be there, well, out. The truly obvious. On the other times, sometimes when I'm really typing so much slower than I'm thinking, I rush ahead, chase the idea to it's roots, typo's flying left and right. Then I go back and weed through the section again, correcting the finger fuckups, that's what they are 'cause I'm a very good speller. Sometime later, when one of the ideas has dominated, I'll start editing. Cutting and adding sections. Putting in the stuff I thought about later. Stuff that belongs here. Because this is the story. This is the story of what goes on in my head. Well, one of the ways it can be when I'm writing.

Stuff pops out and I write about it. But it's stuff that's been in there a long time. This is worked-on stuff. And sometimes not. Some of it just gets made up in the moment, improvisation with the words themselves. I don't mean "worked on" like the sentences just fly out word for word. But it feels like the pot is consistent enough to stand unaided. Well, deep enough. Deep enough to write out a non-trivial idea.

Anyway, this is a characteristic behavior pattern. My first answer is rarely the best. I do not talk precisely enough to satisfy some people, this is a huge clue. The depth of the ideas, like yours I'm sure, get better after a while. Usually I'll tell you that I've thought more about whatever.

Oh, now maybe this is the root idea. No, I mean the next one. I've noticed that it takes about a year to decide if someone is going to really work out in a new job. We're all on the same scale, but it's a scale in n dimensions. There are no tens, as Ken Cleveland used to say to me. (Yes, the Bo Derek movie.) Everyone has flaws, blind spots,

You do the best you can up front in hiring, but some people don't make it for reasons you were not aware of. I did an even worse thing, I hired a guy who failed a question when I interviewed him. Well, I didn't veto the hiring as I should have. It was a really fundamental technical question in our mutual area of expertise. He bullshitted me. I knew it Turns out the question was directly related to why he didn't get through his first crisis. He froze up. I thought, shit, a guy with a photographic memory. Someone who has moved along remembering all the rules but never learned to think things through. Probably he's learned how to think things through a long time ago and learned well. But he didn't have it then and I had spotted that during the initial interview and took no action. I figured it was an outlier, but even at the time it bothered me. He seemed really smart - knew a lot of stuff. He seemed to know how to think.

So one of the things you do in that first year is to get to see obvious holes in ability or skills that were not apparent earlier. A good manager looks hard for the holes and skills in everyone. If someone appears perfect to you, you have missed something so keep looking. Knowing people have weaknesses is one of life's lessons. Some people can hide for a long time, but usually you see it in the first year or much rarely after that. There is nothing wrong with having a part of you that does not work quite as well as others. You specialize in some things. You are really good at some things, and you pretty much suck at some things. But a good team or a good manager will make sure you work with someone good at that stuff. You hire towards your weak side. You hire complements, not supplements. You already here. Hire someone smarter that you. Strangely, it's a pretty rare risk for your own career. You did good by spotting the talent. We're all doing better because you recognized a weakness and compensated for it. So that's the whole thing with hiring. Get the best damn person you can find after a reasonable search or trial run.

I've hired people I knew weren't quite good enough. Got really burned in reputation for a while early on. Of course, hiring is such an inexact art and everyone will fail eventually. No one always hires or marries the right person. You get caught in new places. Good people appear solid or solid is the illusion.

So I had this BRILLIANT idea of writing about the weakness stuff, MY OWN STUFF, I'm working on. You will not be happy until you learn it anyway. So I might as well save us a lot of time and get it out there. Here is where I'm not happy with me in a business sense. Everyone is crazy at some level, but you probably will not encounter that area at work. So do I have a confessional weakness too? Forty years in business says NO. I'm just getting smarter. More connections between neurons or whatnot. Imagine if you could get two ends of the resume scale for everyone? What I'm good at and where you'd better have my back. Wow, so much less stuff to work through when you work together. Could be one or two missing, and we can always invent new ways to screw up. Given the negative consequences, however, people would much rather do the correct thing. Once you know what it is, a weakness is not hard to spot. Your friends, family and co-workers figure out as much as they have to to work with you.

So, why not get your own weaknesses out there? What am I, whatever looks out of David Sheriff's eyes, what are my weaknesses? Last place I hired on I just sent an email to the guy that I work with listing a few physical issues I deal with, Now don't get scared, I'm not going to get all icky on you. I propose to do even better. Get it ALL out there. Where do you need to make sure someone backstops me?

This is such an eminently rational way to apply for a job, list your weaknesses. Well, we covered the answer thing earlier. Unless we are both pretty sure, wait before acting on something I say before I have thought much about it. I can readily identify where those places are. I can rank the quality of my ideas. When I come across a new area I don't know enough about, I will generally say so and qualify the opinion.

Then, and this is the initial image that got this whole piece started. The problem sinks back from the present. Like a ruminant's cud, the problem situation keeps coming up at random moments. Well, that's not actually how I thought of it. I thought about where the ideas went to get processed and Eureka! answers occur to me. And do all of the ideas get thought about at the same time or do they time share the processor? I decided they mostly just get all slopped around at the same time. Whatever process it is that constitutes thinking in the background goes all the time and in parallel, far as I can tell. I will intentionally revisit areas that don't feel right yet. Lots of stuff goes on in the background. When I'm asleep, whenever. I can tell things are interesting in my life because I stop listening to music in the car for long stretches.

My consciousness is like a spider picking it's way through my thoughts. I just notice what pops up ripe. Some stuff needs more time in the kettle, some stuff is urgent and you do the best you can. Ken Cleveland taught me to think about plan b and whatever. If things go to shit at least you have thought about it and you will do a better job handling things. That's your job, to explore several moves ahead if you can. Like chess in infinite dimensions. You don't sometimes get very far in the plan you need now, but it's better than getting cold-cocked.

Startups and Scrum

Success can be an entrepreneur's most formidable enemy. Almost every successful, growing startup hits the point where it outruns the founder's managerial capability. In the usual case, the founders sell out just as the first whiff of trouble floats by. Alternately, the founder brings in a strong executive and continues playing on the Board. A third case I have witnessed, the founder swaps out nearly his entire management team for players who can operate at the new level of business. This is both painful and tricky, but I have seen it work, helped make it work. Scrum offers another path if the founder wants to keep spearheading his growing company. Nothing wrong with taking the money and moving on, mind you. Scrum just presents a new solution set to this old problem.

My entire four-decade career has been in startup companies. I often joined, somewhat coincidently, around the time they were having real difficulty scaling management systems. During the last 20 years I usually hired on with a high tech company to help fix some broken function like sales, marketing, quality, products or engineering. I materially participated in two successful turnarounds of roughly $25 million corporations. Most of the rest were sold off without my assistance. This gave me a season pass to a long run of the entrepreneurial startup show. I was late for the real money, but there before the final curtain. So I've been thinking about this problem for a while. How would I do it now if I wanted to? Now that I know about Scrum.

Scrum teams, not just Scrum software teams, can be amazingly creative and productive. They are not free of overhead, but they can really pay off on their investment, which is mostly in human capital. In addition to setting a few boundaries and standards, you must pay close attention to fixing stuff they say is broken. You must help each team improve their process with enough specialized coaching and give them direction with good Product Owners. Scrum teams are self-organizing complex systems. If you stay out of their way, rather than try to control what they do, the teams will surface and solve the issues in their chartered area. They will even solve problems no one knew about. Think about it. Product innovation, engineering, marketing, manufacturing management; Scrum teams can be designed for any kind of knowledge work. Point them in the right direction and things just get handled. Senior staff runs like a Scrum team, collaborating to devour problems, create solutions and focus the Product Owner teams. There's a lot of trivia you will not have to deal with. If you get the organization to this point where does that leave you as head honcho?

Well, you get to be something like Chief Product Owner. Your team helps you formulate a good vision and you communicate that vision everywhere. It is the same message, tailored a bit for employee teams, customers or suppliers. “This is where we are going. We all focus in the same direction, on the same business targets.” You defend this odd, new organizational system from the ignorant. You model the values and principles. Your team scouts the horizon and figures out exactly where to go. You just point. You are the office of final alignment and instigator of diversity.

Come to think of it, that is a pretty good description of what an entrepreneur spends a lot of time doing naturally. Scrum gets the organization aligned with you, not fighting you. You are leading, not commanding. A number of management functions will have to be re-conceived. Your team can solve most of those problems, many in ways that never occurred to you. If you do not understand Scrum, none of this will make sense to you. This will sound hopelessly naïve and idealistic. That is just fine. Enough people who do understand Scrum will try this and you can watch in your well-deserved ease.

Natural Law and Scrum

Scrum organizes people in classical ways to solve complicated modern problems. Humans have prevailed on this planet because they can work together in small groups to feed and shelter their families under extremely difficult conditions. Working together generates unexpected, useful solutions. Most of us no longer live and work in such collaborative groups. We don't have to. We forget, as a species, how we got to “now.” Current civilization is just fact, few of us question how it happened to be this way. "Natural Law" is a fairly disreputable concept in the sciences, but seems to fit in this context.

Scrum brings the small collaborative group into a modern context. We face complex problems at work that resist resolution given our quaint ideas about how work is naturally organized. Modern managers order employees around like so many tribal functionaries: build bricks, train warriors, distribute food, allocate irrigation water, collect temple offerings or levy tribute. This mode of business operation assumes most jobs are simple and the whip will motivate the lazy or enslaved.

Scrum works the really old fashioned way with a few defensive practices to keep enemies at bay. Scrum provides a structure that teaches and reinforces the classic values that humans employ to collaborate successfully. These are the identical values early men and women developed to collaborate because the survival of their kinfolk depended on it. All are necessary. You may not leave anything out. You will all know what I mean when I list the values. We, too, are people and we carry those instinctive ways of working within us. These core Scrum values are quite simple, but industrial management may consider one or more to be silly and naïve. This can put Scrum culture and "normal business culture" in conflict. That conflict is the source of resistance to Scrum. It is the reason many Scrum implementations fail to live up to expectations.

The Scrum (and small team) values are: Openness (aka honesty, transparency); Respect for others (meaning people) and their ideas; Commitment, accepting responsibility and then doing what we say we will; mutual Focus on achieving common goals. Finally Courage, that well-honed risk management tool that tilts a little toward sacrifice. If you are not going to be trampled by the Mastodon, you'd better have the courage to kill it. Even if you die in the attempt, your family will probably eat. That is where the behavioral parallel begins to break down. In life and death situations, your genes are very interested in the outcome, so to speak, and express their own values. We leave the elucidation and implementation of those values to others.

Cynicism, inertia and the trappings of power should not be underestimated. If we accept a paradigm of powerlessness, we can devalue or deny our most useful behavioral wiring. This is powerful stuff and we are conditioned to control it tightly. Mass rage is powerful. The utility of mass rage does not mean we are to pillage and burn. We are unlikely to align our interests perfectly with powerful instincts in the best cases. So we apply the classic principle of empiricism, inspect and adapt. We don't have to re-invent the method, just notice with discernment and act accordingly.

The small collaborative team pattern is neutral on a good-and-evil scale. You could run a criminal enterprise under the Scrum framework. How many examples of the good and the perverse utility of small teams can you think of? Many of us are wired to work collaboratively as surely as we find comfort gazing into a campfire or a television screen. Scrum is not the solution to every problem. If your group is lost and has a guide who knows the way, better to follow the guide than ramp up Scrum. Do only what makes sense.

“Scrum” was developed and first proved successful for managing software development. The best implementations of industrial theories were disasters managing software workers. Managers failed to realize they were dealing with something new: groups of knowledge workers, legions of software developers. When knowledge work was an individual game, say writing books, professional management ignored it. But now they were dealing with problems so complicated that it was impossible to think through the solution, write up a comprehensive plan and just turn the crank to produce whatever flavor sausage.

Complex problems throw off a continuous stream of questions and new ideas as you work them. You must continually incorporate new information and ideas into the emerging solution. The more carefully you plan up front and more rigorously you stick to the plan, the worse the outcome. Anyone who understands why centrally planned economies collapsed in the late 20^th century should get this and vice versa. Even the near future can unfold with almost infinite possibility.

Actually, the problem is even worse. Any process you can imagine for solving complex problems will become dysfunctional over time. The process itself must adapt to local conditions and the changing nature of the problems it solves. This was no problem for our hypothetical prehistoric team. They were not hung up on process. They looked at what worked and did more of that; noticed what foods made them sick and quit eating them.

So Scrum is less a method or process than a mindset which propels an adaptable framework. Scrum principles and values change the way individuals think and interact with one another at work. Scrum teams self-organize to do the work. They deliver a bit of the finished product regularly so anyone concerned can see if it's as useful as they expected and suggest improvements. The team works in regular cycles, called “Sprints” At the end of each Sprint, they meet to discuss their process. What worked? What made us feel sick? They decide how to modify the process so it might work a little better in the next sprint. Notice that the people who actually do the work decide how to adapt the process, not their managers trying to figure out what really happened and factoring their own bias in.

This illustrates a curious and central bit in Scrum. The Team have to work their way out of their own problems. They have to get collaboratively creative to eliminate some common irritation. They can ask for help. But if they can do the project work, which is challenging and creative, they are smart enough to fix their process itches. If you help them too quickly, the never learn how good they can be.

Sprints repeat in whatever seems like an appropriate cycle. They tend to range from two to four weeks. After a short time, the process develops a rhythm or cadence. If new work is demonstrated every other Thursday, it's easy to make that a recurring item on the VP's calendar. Other structural rhythms are built into Scrum, like the festival seasons of the year. We plan at the Vernal Equinox and take stock at the Autumnal Equinox. The festivals and holy days remind us to do all the necessary things in the right order.

Two individuals playing different roles keep the team on the tracks. You want the team to be as outrageous as possible, but you'd like all that creativity channeled in the right direction. These two are the Product Owner and the ScrumMaster. I'm sure both are personifications of ancient gods, but I'll let you work out which ones.

A Product Owner makes sure the team has a vision of what they are bringing to life so they can all move the same direction. The PO is the single point of control for what gets built and what does not. The PO tends to win when the team is maximally productive.

The Product Owner keeps a list of all plausible product features and organizes it so the ones that should be done first actually get done first. Business judgment is required here, not just quantitative data. Remember that lies sometimes come with statistical reinforcement.

The ScrumMaster guards the process and the team. The ScrumMaster either teams with the PO or opposes her, depending on the issue. The ScrumMaster is responsible for group dynamics, for modeling and teaching the values and key practices. Above all else, the ScrumMaster keeps the inspect-adapt loop working well. Both the ScrumMaster and the PO find it in their interest to shield the team from outside interference. The relative contribution of each role to the result varies. Be careful not to skimp on either one. Future not predictable, right?

The new thing in Scrum, to the extent there is one, is the suspension of this selection of classical cycles, teams, principles, characters and holidays within the Scrum framework. The combination is encircling, reinforcing, conflicting and supporting. It all hangs together; it all works as a system. This is why neglecting some practice might make the values fade or fail to germinate at all. Scrum, it has been observed, is how we used to do things when our backs were up against the wall. More true than you might first suspect. Just once more: the values make Scrum work. More precisely, people imbued with the values do all that astounding work. The practices, principles, ceremonies and artifacts just manage space where humans can practice the values while working. It's just how nature works.