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