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?