Agile2016 Wrap-up

August 8, 2016

HotelImage

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.

Advertisements

Strategies for Managing Interruptions…for Reluctant Scrum Teams

August 3, 2016

summer-sunshine-alcohol-drink

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.


Agile2016 is Coming!

July 9, 2016

hands-people-woman-meeting-large

“This is where the Agile tribes meet.”

Agile2016 is swiftly approaching. I’ll be there in Atlanta doing a couple of talks this year. If you are going to be there you should definitely come check them out:

The Self-experimentation workshop is something that I originally developed a few years ago for XP2013. It is very hands-on, each attendee contributing their own experience to the workshop. To date it has been very popular. Some attendees have described it as one of the most invigorating talks they have ever attended. That’s pretty high praise – it’s probably my all-time favorite workshop.

If you are interested in getting a bit of a sneak preview of what this self experimentation stuff is all about, you can check out the experiments that I have run on the onestandardman blog. There is also background material here and here.

On the impediments front, there is a lot of material that you will find right here in this blog. For example there is this, and this and this. And then of course there is The Little Book of Impediments. There will be copies of the book at the bookstore for purchase at the conference. Catch me and I’ll be happy to sign one.

There will also be an Agile Management Conference meetup that will be held in the Open Jam area (time & date at the conference is TBD – check the Open Jam Board) so please join us for that if you are interested.


Testing the Agile MBA

March 27, 2016

man-person-hand-lens

“Research is formalized curiosity. It is poking and prying with a purpose.”

-Zora Neale Hurston

So as I thought about my earlier post on the idea of an Agile MBA, I realized that there is a whole lot that goes into putting together something like that. So before heading down that path, a guy might be well advised to check and see if there is any real interest in the idea before wasting a lot of energy on pursuing it further. So with that thought in mind, I created openagilemba.com.

The idea is simple, taken from the lean startup world. If you have an idea, put it out there and test whether or not there is a market for it. So I’m doing exactly that. Go check it out. I named it the “Open” Agile MBA because I’m not trying to sell anyone anything. What I have in mind is more of an open source MBA model. If we can assemble the resources, then anyone can use them. That’s kind of an exciting idea. It’s not new, there’s a NoPay MBA out there that is really cool and does something similar for a standard MBA.

So I’m starting with small, agile steps. Simply put up a web page and ask people if they are interested. If I get a few responses (feedback!), then I pursue it further, if it’s just crickets, then perhaps I tweak the idea and try again. I can’t wait to find out!


The Agile MBA

January 27, 2016

people-coffee-notes-tea-large

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


The Agile Gymnasium

January 12, 2016

IMG_0271

I used to be a weightlifter. All through college, and for much of my adult life I have been in gyms exercising in one form or another. I’ve had some modest success. The experience of joining a gym goes along some standard lines. You’ve probably done it yourself. You show up and they take you around the facility and orient you to the equipment. They may even go so far as to give you some very basic training. You get an introduction to circuit training and then they slap you on the butt and tell you to “go be awesome!” You can record your exercise sessions on this little card over here…

That’s pretty much it.

As you might imagine, the success rate with that sort of system is fairly low. A lot of people never come back (although many continue to pay their monthly dues). Those who do come back typically have no idea what modern exercise programming looks like and simply go through the motions: they ride the stair master, do a few sit-ups, and maybe do some curls. That sort of exercise has some marginal utility – you get some small amount of aerobic benefit, but it’s a far cry from exercising a meaningful percentage of most people’s potential.

Most people stop there, but there are a few who have a more ambitious goal in mind. They may be trying to improve their tennis game with better conditioning. They may be looking to build massive pectoral muscles (like most teenage boys). They may be trying to maintain their conditioning in the off season of their sport, perhaps like cycling in the winter. In other words, the purpose of their exercise is to improve their performance in some sort of real world scenario.

I’d like to pause for a moment here. I was listening to a discussion with some folks who owned their own gym and they had an interesting model. It had three tiers to it:

  1. Gym Work: Work in the gym is not like the real world at all. It is where you go to prepare for the real world. The gym is a safe place to work to the point of failure (that’s important) and to learn.
  2. Expeditions: Expeditions are adventures in the real world that are guided by a coach. So it is real world experience, but with someone there to guide you and help if you fail.
  3. The Real World: This is where it all comes together. Ultimately, this is where the training in the Gym and the experience in the expeditions pays off in terms of improved performance.

As a model for the role of training for high performance, I thought this made a lot of sense. There was one more thing that they added to this: They were capturing data on the entire group’s performance and analyzing it in order to provide better training for individuals in the future!

So when you join the gym, you use a training program that is similar to what others in the gym are using. Your performance of that program is measured and metrics across the entire population training in the gym are measured. Then experimental changes are made to the training program and their benefit (or lack thereof) is measured across the group. Gradually their training program improves over time. But the training isn’t just tested in the gym. They also track the performance of their members when they go on expeditions. This measures the effectiveness of their training program in the real world.

OK, enough about this gym. What if we could use the same metaphor for the way we train our development teams? Training would be a weekly thing. Something where you go in for training on a periodic basis to firm up your skills. There might be repetitions (pair programming, mob programming, etc.) and there might be coaching (coaching circles, etc.) and there might be someone who is coordinating the training program and measuring the performance across the entire group of trainees.

There could be expeditions from time to time. Hackathons where people get to try out what they have learned in the gym out in the real world. You know: build a real project, maybe deliver something over a weekend. Test out your mastery of your skills in the real world – with a coach there if you need it.

Then there is game day – the real world. You take what you have learned and join a team. You get to flex your massive coding and collaboration muscles and help build something challenging – something amazing. What a great model for development! But I’m not done yet…

Let’s take this model, we’ll call it the “gymnasium model”, and apply it to something like Certified Scrum Master Training. Right now, there is two days of class time and exercises and then they slap the CSM on you and send the newly minted CSM out into the world. It’s a hauntingly similar scenario to the average person’s experience at the Gym: welcome to scrum, now “go be awesome!” Maybe you do a few sprints, do a few standups and off you go. That’s about as agile as most people get. Seriously. You get some marginal benefit, but that’s about it. It could be so much more.

But what if we did things differently? What if instead of signing up for a 2 day class, you were to join an Agile gym. Maybe twice each week you go into the gym to “work out”. A coach would give you a workout, perhaps something like this:

1. Dysfunctional Standup
2. 3 Reps in the coaching dojo
3. 2 Sets of mob programming
4. 2 reps of code katas
5. 1 cool down with a retrospective

That’s just a sample workout. The Agile Gym is a safe place to try out new skills and to push ourselves. The coach would be responsible for measuring the effectiveness of the workout and modifying it over time. Experimenting with new techniques and combinations of methods and evaluating the outcomes. Of course, this is just training in the gym. From time to time we are going to need to test our our competence in the real world. The coach would provide some guided expeditions (perhaps twice a month). For example:

1. Participating in a Hackathon
2. Participating in a Startup Weekend
3. Participating in a Maker Fair

These are events in the real world that are important places to evaluate the effectiveness of our training in the gym. If our coding skills have improved, then we should do well at these events and build confidence in our ability to use our newfound skills in the real world. Speaking of the real world, hopefully now we would see the agile behaviors that we have practiced being manifested in useful ways in the actual projects that we are running from day to day. Our collaboration skills should be tight, our planning impeccable, our retrospectives revealing. And if we find any weak areas, then it is back to the gym for more training.

In this model, the gym is always open. You actually practice your skills and see improvement. What an amazing way to learn about agile!

It’s not a bad model really. Actually, it’s a really darn good one. Who wants to start a gym?