Saturday, November 13, 2010

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.

1 comment:

  1. It lasted 60 days. Our contract ran out. They no longer needed us. We went away.

    I discovered two things. First, software pros have a reputation for low social skills. Rather than helping them work better, I'd just rather do something else, thanks. No insults to my outstanding friends in the business.

    Second, I no longer care to run amped up all the time. Did my share, thanks, Not willing to live on the knifepoint. Operating at some low level of terror that propels you forward. Moves you along in the game. Can you handle the next level of stress? Screw it. I could get out and I did. Quit while I was ahead. Spent the next ten years sweating on the docs. Good choice. And there was just enough left to retire in Nampa. Life restarts one more time.

    In business, you never get back in at the level you left, so whatever you do will be a little boring. It's retirement, dude. You just don't see it yet.

    The reading and experience I gained studying and talking about scrum changed me into a happier person. A more effective person, I hope. Seeking ways to be really engaged. Change lives. . . .

    ReplyDelete