August 10, 2016


I discovered an amazing new concept the other day. A radical re-combination of things I thought were fixed and immutable. Two ideas that I loved by themselves, things complete without any addition. Things so familiar to me that I never dreamt of change. Frankly, I never saw the need. These ideas when put together created something greater than the sum of the two. Something so shocking that my first reaction was blank incomprehension. That’s right, I’m talking about: Fried Chicken and Waffles

I’ll give you a minute to sit down and let it sink in. Dinner and breakfast in the same meal! Two memes that complement each other so completely they create a larger meme! Sweet and savory, fried and…baked? Fried? Oh I don’t care. I love them both. So finding a restaurant that serves two of my favorite foods on the same plate, well, that’s pretty special.

That’s the way it is sometimes. Ideas that by themselves are great, but that are somehow magnified when combined with another idea. Somehow by repackaging them together we create something greater. Something that works much better as a whole. Of course there are plenty of culinary examples: french fries and poutine, caramel and salt, bacon and…um…well…anything.

Of course we have similar concepts in the software world. There are folks that maintain that the combination of some development practices yields disproportionate benefits as well. For example, combining agile and DevOps. Rapid development techniques and tightly integrated operations. The two make a potent one-two punch that provides powerful benefits to companies bold enough to adopt them. It’s like fried chicken and waffles.

Agile2016 Wrap-up

August 8, 2016


Well Agile2016 is in the bag.

This years conference was the largest one yet. There were nearly 2500 attendees. That’s double what it was a few years ago. Day-to-day at the conference, there definitely felt like there were a lot more bodies. Of course that could have been the location too. This was the first conference in while that wasn’t held at a Gaylord “biodome” monster hotel. Instead it was held at the Atlanta Hyatt which is considerably smaller.

Getting into talks was a real hassle this year. Often the rooms were too small and filled up more than half an hour before the talk. People were queueing up outside the door more than an hour beforehand. It was kind of nuts. Other talks were in monster halls that were barely a quarter full. There were a lot of frustrated people.

There weren’t a lot of options for getting around the hotel either. There was a bank of elevators in the lobby that was regularly overwhelmed by the thousands of people trying to get to and from their rooms. It was kind of a mess. The rooms themselves were small and quite dark. All things considered, people were not very happy with the location for this year’s event.

As quickly became apparent, there is no lack of newbies on the bootcamp track this year. The room for my talk on impediments was packed. I heard the same for other bootcamp speakers. So the number of folks who are new to Agile is still strong. That’s encouraging.

I heard all the usual grumbling about how the various “scaling” efforts were boilerplate solutions that only enable the status quo. In the meantime, one of the most popular sessions I attended focused on creating a roadmap for transformation. In my opinion, the scaling conversation is a natural evolution of the adoption of Agile as it moves into the mainstream. It’s just not trusted by established Agile practitioners who’ve only seen healthy agile in smaller contexts (true). But that doesn’t change the fact that the big guys are feeling pain and want to get there. So like it or not, I think scaling frameworks are here to stay. And I for one, welcome our new corporate overlords…

I participated in one of the memorials to Jean Tabaka. It was very moving and it was apparent how many lives she had touched both directly and indirectly. I was there largely to support my colleagues who had worked directly with her. I found myself reflecting on what it means to be the kind of person who can share themselves that authentically with others. It’s not something that comes naturally to me. I found it instructive to ask myself how to be more genuine and authentic with people as I moved through the conference. I found myself doing battle with my natural tendency toward introversion – it takes a lot energy for me to put myself forward, to take an interest in others and try to engage.

The Impediments talk was a complete riot! I had a blast. The crowd was fun and the material, much to my surprise, continues to evolve in interesting ways that I never would have anticipated. More on that to come.

The self-experimentation talk was very challenging. Overall, it went pretty well, but I was challenged with doing a very interactive workshop in a gigantic space, I was also challenged with some of the ideas from folks who participated (thank you!), and I was challenged to consider if there are better ways to talk about experimentation. This was arguably the session where I learned the most as the presenter.

Strategies for Managing Interruptions…for Reluctant Scrum Teams

August 3, 2016


Stop me if you have heard this before. No, really, please stop me. So there I am working to get a team launched using Scrum. They’re good folks, but frankly, they’re just doing what the boss said.

“We’re using Scrum. Tom is going to show you the ropes and get you started.”
“Right boss.”
“Training room down the hall on the right. 9:00AM sharp.”
“Got it boss.”

And so a rather wary-eyed crew shows up the next morning. As they sidle into the room we eye each other cautiously from across the conference table. I’ll admit it: I’m not feeling so hot. Combine all the glories of travel with a night in a Motel 6 and it makes a mean recipe for a mean trainer. I’m trying to guess if they are feeling as lousy as I am. Hard to tell. Maybe they always breathe through their mouths like that. I can already tell this is going to be a challenge.

So this is the part of the morning where I introduce them to ‘Satan’. No, it’s not what you think. Satan is what I call my trusty 300 page powerpoint deck that I use to break the will of my students and introduce them to the glories of Agile development. Here, have some pipe cleaners to play with while I’m talking. You can make a tiny little gun out of them and try to blow your own brains out before I finish these slides. Don’t say I don’t know how to have a good time in a meeting. Now where were we? Oh yes, here we go, slide 1…

Fifty shaky, sweaty minutes later (Dammit, where’s the coffee?), and the room full of 9 adult men is starting to look like something out of Glen Gary Glen Ross: The best thing these guys are going to get is a set of steak knives. The mood is getting ugly. We’ve just gotten to the part where I tell them that they are now part of a committed team. I can see their eyebrows shoot toward their hairlines when I say it. That’s right Judith, you only work for THIS team now. Nobody else.

The place immediately lit up like someone spitting cheap vodka on a campfire. In hindsight, I really should have seen this coming: a lot of these guys are from the operations team (for those of you new to software, operations is the software equivalent of the galley where we keep our slaves). Those guys work hard. Like breaking rocks hard. They’re interrupted so frequently, they’ll eventually get a new variety of Attention Deficit Disorder named after them. It’s merciless. If you don’t like it, no problem, we’ll find a replacement just like you.

So there I was telling them they have nothing to worry about, just tell the old boss that they’re Agile now. Yeah, tell ‘em Tom sent you. Agile teams are dedicated and can’t be pulled apart just for firefighting. Here I was, telling them that the nightmare was going to end. You’d think they’d thank me! Perhaps it was the hangover, but I just wasn’t picking up on the mood in the room with my usually alacrity. Note to self: next time stick with tequila.

So I was told, in no uncertain terms, that they fully expected to get pulled off of their work during the sprint for any number of unanticipated reasons. That was just the way things worked at this company. Managers felt perfectly entitled to pull you off a team any time they liked (after all, you were still “theirs”). This was the status quo here. It wasn’t unusual to have people who were over allocated by several hundred percent!

That’s right, it’s not just my poor alcohol addled recollection failing. These folks were expected to work simultaneously on 5 or more projects at any given time. Ouch! As I tried to tell them that was crazy, I could hear an all-too-familiar edge of hysteria creeping into their voices. Right then, it hit me like a pole axe between the eyes: I was explaining this to the wrong people! Finally sensing the disaster I was in danger of perpetuating, I did the only the only sensible thing one can do in a situation like this and beat a hasty retreat. That’s right, I needed to run away. Time for a distraction.

“Hey! I Know what to do! Let’s play a game!”
You see, when you need to distract a class and bail yourself out of a tight spot, nothing works quite as well as a game. As the team struggled to comprehend the arcane rules I’d just arbitrarily made up (I swear to God there was a beer game just like this in college) I racked my brains for ways to help these poor bastards out.

I was only confident of two things:

1) Talking to the managers would serve little or no useful purpose. Besides, I’d done that already. Just between you, me, and Machiavelli: it’s a total waste of breath. Most managers (and I speak here from experience) are normal, perfectly well meaning people, who have had the learning centers of their brains completely erased by the non-stop firefighting, infighting, and general chaos of their jobs. The average manager’s brain is like the surface of a cheap George Foreman grill: nothing sticks. But don’t despair quite yet, because there is a ray of hope…

2) Managers can be trained. I know: I used to train rats.

You see if they won’t willingly change their behavior, you can always change your own behavior. This is key to understanding change and cultures. Something has to change if you are going successfully introduce a new process (wow, that’s so utterly obvious I just got a sharp pain between the eyes). The bad news is change is hard – wicked hard. I think need a drink just contemplating change sometimes (I guess that makes me either a change agent or an alcoholic). But rather than obsessing on how to change the other guy, focus on changing yourself. Then you let them figure out how to react.

Re-energized, I finished the “Intro to Satan” for the day, kicked them out of the office, and went to do some thinking. I needed some inspiration.

Fortunately the bar wasn’t far away. Using that little epiphany as a starting point, I sat down and started writing a list of all the things that the team could do to help deal with their interrupting managers on the back of a beer coaster. It went a little bit like this (I started with the hardest one first):

  1. Say ‘No’: Yeah, I can’t say it either. It takes some practice. Repeat after me: NNNNnnn…uh,nnnuhhhhh, Nuuh, Nuuuoooo, Noo! Come on now, I know you can do it!
  2. Use Buffers: Use a time honored way of protecting schedules and buffer the heck out of yours. As soon as they figure out what you are doing, they’ll leave you alone. Well, if they are smart they will. Your mileage may vary.
  3. Use your Sheepdog: You have this wonderful creature armed with a mouthful of sharp teeth that lives to protect you from outside influence: the scrum master. Use ‘em.
  4. Cover your Buddies: If your team mate is in danger of getting nabbed, stick up for them! A chorus of “No!” is much more powerful than a piteous lone ‘no…’
  5. Escalate: Hey, use the bureaucracy for what its really good for: aggravating others.
  6. Abnormal Sprint Termination: this is a curious bit of scrum geekery that you don’t see very often, but it could work. Threaten sprint termination. Better yet, let the scrum master do it. They LOVE that kind of thing. Makes their whole day.
  7. Automate, Automate, Automate: Did I mention automate?
  8. “Tom said…” That’s right – blame it on me! It’s my fault. I admit it. I told you to say “No.” So go ahead, fire me.
  9. Working Agreement: OK, admittedly this is the most tepid offering of the bunch. But it could work, right? Put together some sort of working agreement with the managers in question. Of course that would involve communication and cooperation, and I hate the idea already. But it might work.
  10. illegible…note to self: never rest your beer on your work.

So here’s the bottom line:
Sometimes if your managers won’t change their behavior (and frankly, why should they?) then you may need to change your own behavior. You’ve got to give ‘em a reason to change. That’s what these suggestions provide – small changes in your behavior that will require changes in the organizational response.

The Agile MBA

January 27, 2016


“Education is a progressive discovery of our own ignorance.”

Will Durant (1885 – 1981)


I’ve thought about getting an MBA from time to time throughout my professional career. It was always a hard thing for me to justify for a few reasons. First, an MBA is very expensive and you never know if you will get that money back in terms of earnings afterward. The graduate schools certainly want you to think so, but when I look around, there are a disturbing number of MBA’s that aren’t working in management. It seems P.T. Barnum may have been right, there’s one born every minute. Second, getting another degree, MBA or not, requires an enormous expenditure of energy. This is energy that I could be applying to improving my existing career, or perhaps starting my own business, or drinking beer – I just can’t decide. Why go to school to burn energy that might be better spent elsewhere? Finally, an MBA is boring. I mean really boring. I’ve seen the curriculum and thought to myself, “Why would I do that to myself?” Honestly, I’m really not a very good student. I know myself well enough to recognize that if I’m not terribly passionate about something, odds are that I will get bored and then perform poorly. When I look at the average business school curriculum, it’s really hard to give a damn.So getting an MBA has been something I’ve personally found hard to approach.

Of course, these reasons are easily and reasonably countered. I certainly don’t discount that there is value in an MBA, but the question is, “is there value for me?” Everyone has to answer that question for themselves. I can afford the expense, so while the costs are daunting, they aren’t prohibitive. And as far as energy expenditure is concerned, that probably isn’t a problem either. If you can build a boat, you can probably manage an MBA. But what about the boring curriculum? What can I do about that? With existing programs, probably not much. But what if I could make my own curriculum? What if I could customize an MBA to focus on areas that I’m really passionate about? What about an Agile MBA?

It’s probably a silly idea. I’m quite sure that it’s not an original idea either, but I’ve yet to find anything like it. I’ve found this: https://leanmba.wordpress.com and it’s certainly a lot of what I was thinking about (it’s really good), but I think there is more to an MBA. It makes me wonder, what would an Agile MBA be like? What would the curriculum be like? What would the classroom interactions be like? What would the overall experience be like? How could we build this program?

These are all good questions. Let’s start with the curriculum. Let’s take a peek at a few traditional MBA curriculum’s and see what we need to cover (from an agile perspective):

1. Finance
2. Microeconomics
3. Statistics/Data Analysis
2. Leadership
3. Marketing
4. Technology & Operations Management
5. Strategy
6. Communication
7. Problem Solving
8. Ethics
9. Economics
10. Innovation/Entrepeneurship

…or something like that. That’s what I came up with after a brief survey of a few MBA programs. They all look pretty much the same. Yawn.

So I guess this is a starting point. Looking at the list above, I have to wonder, what would an Agile version of this curriculum look like? What books would I recommend? What courses, classes, or certifications would I require? Looking at this list, I think I just might be able to do that. We’ll take these one at a time over the next few weeks.

Planning in Circles

January 25, 2016

round-spiral-cardboard-tube-roll-large“When you make a mistake, there are only three things you should ever do about it: admit it, learn from it, and don’t repeat it.”

Paul “Bear” Bryant


Recently we moved from an annual planning process to a quarterly large scale release planning event. There was a lot going for the idea of the new quarterly planning process:

1. Smaller batches of projects to plan
2. Less wasted time on projects that would never get worked on
3. More collaboration between teams and stakeholders, because we held the planning event in a big room with everyone invited
4. It only lasted 2 days, so the amount of preparation was dramatically reduced

What’s not to love? Our previous annual planning process started in February or March and continued non-stop until late September or even further (once it went through Christmas). The amount of waste in the process was truly astonishing. There were multiple reviews by executives, red-lining exercises, requests for more estimates. It was interminable.

So anything that offered us a way out of that madness was OK with me. We modeled the planning event on the SAFe style large scale planning events. It seemed like a slam dunk. Get everyone in the room, facilitate like hell for two days, and out pops a bouncing baby quarterly plan. Easy.

We held the event and it went pretty well. There were a lot of missing requirements and people had to get used to participating in a high intensity collaborative event, but in the end, we got the job done and walked out of the room after day 2 with a relatively stable set of commitments for the upcoming quarter. So we did a retrospective and started planning for the next event in 3 months. Just like it says on the bottle: re-apply, rinse and repeat.

And this is where things started to go wrong. Some folks were concerned that they hadn’t been prepared enough for the first event, and they decided that they should begin their planning for the next event earlier. While this is not a bad idea on the face of it, there were some consequences that we didn’t see coming. Soon, everyone was screaming that they needed to start planning – in as much detail as possible. All of this happened within about 2 weeks of finishing the first planning event. So the end result was there were a lot more meetings and planning done before we had our second large scale planning event.

So we do the second event, and yes, things were improved. There were more requirements, the teams came to consensus faster, and in general things looked pretty good. However, there was one rather alarming development: executives added a bunch of projects to the backlog the day before the planning event. They were “must do” projects, but they didn’t have any requirements behind them. So we sucked it up, put on our big boy pants, and dealt with it. By the way, I’m not recommending that as a coping strategy.

So of course, product management and others were even more panicked this time to get started on requirements early. So now there was literally no pause in the planning between events. After we finished our second planning event, then we immediately began work for our next planning event.

Did you see what we did there? That’s right, we started off with a brief but effective planning event that replaced our year round nightmare. Then for the next event we added more preparation. And for the next event we added even more…until our quarterly planning process has become virtually indistinguishable from our disastrous old year round planning process. We’ve come full circle!

So what went wrong? I have my suspicions, and I’d like to point out that’s all they are, so take them for what they are worth. I think that in order for changes like this to be effective, there needs to be corresponding changes in the expectations for what you get out of the event. If you change the planning process, but the expectations for detail, control, and commitment/accountability don’t change, then you are going to run into problems. In other words, if the process changes, but the outputs and the expectations around them don’t change, then it’s very likely that sooner or later you will end up right back where you started.

I think you see this most commonly in organizations that implement a change (adopting agile, kanban, or anything else) and the top level management aren’t bought into the change. They are going to be looking for the same outputs that they’ve always had. They aren’t going to accept anything else. That puts pressure on the system to return to the status quo. Eventually, the change may still be there in name (as in our case), but effectively you have returned to the original system.

You Can’t Break it Down Until…

December 7, 2015


One of the first things that agile or iterative development demands of us is that we should break down our work into very small chunks. This challenge is one of the first hurdles faced by teams that are adopting sprints and trying to make all of their work fit into a tiny little 2 week time box. I’ve seen it over and over again. The first question folks ask is, “How can I break this down into pieces small enough to fit in the sprint?” I often get reactions that range anywhere from frank denial to outright disbelief. It just can’t be done!

I know. I get it. I really get it. The first time you deal with breaking down a big project is like running into a cognitive wall. I remember the first iterative project that I did. I understood the model. The concepts made sense: break things down into small chunks and then iterate. Easy. Only it wasn’t. I remember sitting in front of my monitor thinking, “What meaningful piece of functionality could we do in a sprint?”

Nothing came to mind.

It was dreadful. We were working on a new product, something completely new to the market. I had no idea what I was doing. That’s not to say that I was incompetent. Far from it. I knew that I didn’t know much. In the end, we overcame the challenges on the project and I conveniently forgot most of those lessons and moved on. Typical.

I had another reminder the other day. Recently I finished building a boat. Truth be told, this was one of the largest personal projects I’ve ever accomplished. It took me nearly three years to build the boat from boards-on-the-floor to sailing off the boat ramp. That’s a long time, but it’s a big boat. I’m quite proud of my accomplishment, but there is one thing that sort of bothers me: building a boat wasn’t a very agile process.

What I mean is there wasn’t much opportunity to iterate or deliver in an incremental fashion. Boats are funny like that – if you take to the water before the boat is ready, you run the very real risk of sinking your ship. Three years is a long time to go without honestly knowing if a boat will float.

There are some very good reasons it took so long:

1) This was not a team effort. It was just one guy. I’m good, but I’m not a team. It’s harder to iterate quickly on complicated work without a team. We can put this under the heading of “Obvious.”

2) I didn’t know how to break the problem down into smaller, meaningful pieces. Fundamentally, I didn’t understand the problem well. I didn’t have much experience with boat-building or woodworking. It’s hard to iterate when you don’t understand the problem domain well.

3) The plans and design were not arranged with iteration in mind. There were no intermediate steps that would allow incremental delivery. There was not even a halfway point to check and see if the boat just floats. It’s hard to iterate if the design and plans don’t allow for it.

4) There wasn’t enough experimentation. Good boat-building and construction usually incorporates frequent re-measurement and “test fittings”. The old saw, “Measure twice, cut once” certainly applies here. I made a lot of mistakes and they cost me time. It’s harder to go fast when you aren’t testing and experimenting.

I attribute much of the difficulty with breaking big projects down to these four key reasons above. You can overcome these issues with time and experience (your own or someone else’s). In my case, it took me a while.

However, after 3 years of working on that boat in my garage, I now find myself doing something completely different. Now I can wander out and create a long list of tiny tasks quite quickly and spontaneously. I know much more now. I can see hundreds of little tasks that need to be done. Little stuff, literally just a few minutes of work. I spent most of my time measuring and trial fitting. Lots of little experiments and more than a few failures. I’m much more successful that way. So I guess there is an agile way to build a boat – it just took building a boat to discover it.

You Can’t Break it Down Until You Understand it

July 7, 2015


“Furious activity is no substitute for understanding”

– H. H. Williams

One of the first things that agile or iterative development demands of us is that we should break down our work into very small chunks. This challenge is one of the first hurdles faced by teams that are adopting sprints and trying to make all of their work fit into a tiny little 2 week time box. I’ve seen it over and over again. The first question folks ask is, “How can I break this down into pieces small enough to fit in the sprint?” My response, inadequate though it may be, is some variation on, “It’s not hard. People do it every day.” I know – not the best answer. I often get reactions that range anywhere from frank denial to outright disbelief. It just can’t be done!

I know. I get it. I really get it. If you aren’t used to it, the first time you deal with breaking work down into tiny chunks is like running into a cognitive wall. I remember the first iterative project that I did. I understood the model. The concepts made sense: break things down into small chunks and then iterate. Easy.

Only it wasn’t easy at all.

I remember sitting in front of my monitor thinking, “What meaningful piece of functionality could we do in a sprint?”

Nothing came to mind. I drew a total blank.

It was dreadful. We were working on a new product, something completely new to the market…and I had no idea what I was doing. We had no clue. That’s not to say that we were incompetent. Far from it. We all knew that we didn’t know much, and that was a big problem. Fortunately, we overcame those challenges. Unfortunately, like many people, I conveniently forgot most of those lessons and moved on.

I had another reminder the other day. I was working on the boat I’ve been building. So much of building a boat early on was big intimidating chunks of work. I had no idea what I was getting into. Everything seemed daunting. Weeks of effort. However, after 3 years of working on it in my garage, I now find myself doing something completely different. Now I can wander out and create a long list of tiny tasks quickly and spontaneously. I know much more now. I can see hundreds of little tasks that need to be done. Little stuff, literally just a few minutes of work.

So I didn’t know what I was doing when I started, but I learned, and as I learned I was able to break things down. So how did I learn? By getting started and making mistakes. Lots of mistakes. Sometimes I think mistakes are the only thing I’m good at. So now when people ask how to break things down, maybe my answer is, “Just get started, the answer will come to you as you learn the problem domain.”

Of course, if that fails, you can always take up boat building.