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?


You Can’t Break it Down Until…

December 7, 2015

12002042_10206982935269284_2763177572426614749_n

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.


Driving Self-Organization

July 8, 2015

Bangalore Traffic

“Too bad the only people who know how to run the country are busy driving cabs and cutting hair.”

-George Burns

I learned to drive in Southern California. I’ve always been kind of proud of that fact. Driving in the southern land of pavement and potholes requires a special kind of aggressive driving in order to survive the freeway melee. You have to learn to barge into a lane when there isn’t any room, to turn left on a light after it turns red, to tailgate in order to keep others from cutting you off. That’s quite a litany of questionable driving practices. All in a typical day of driving in Cali. Don’t mess with me, I’m an expert.

That’s what I thought before I went to India.

Driving in a taxi in India was an eye opening experience. Silly little conventions like lanes are completely ignored. The entire road, from sidewalk to sidewalk, is your vehicular playground. Driving the wrong way into oncoming traffic is a matter of habit – how else would you get where you are going? I tried to count the number of times I was nearly in a head on collision, but I gave up – partly because I lost count, and (maybe) because I was distracted by my own screaming.

Don’t get me wrong: I was in complete and utter admiration. The level of self-organization and complexity was breathtaking! With what appeared to be a complete absence of rules, people managed to get to and from work every day amidst what appeared to be complete chaos. I very quickly resolved to never lecture anyone on the merits of self-organization ever again! Why? Because apparently I’m an amateur. If you want a lesson in professional level self-organization, don’t talk to me. Talk to a taxi driver in Bangalore.

Someone asked me if I thought I could drive in that traffic. My answer was yes, but not because I think I’m good. Quite the opposite in fact. The Indian driving system appeared to be remarkably tolerant of incompetence. The traffic ebbed and flowed around complete bumbling dolts with apparent ease. Contrast that with where I live in Seattle: one idiot in the left lane can shut down an entire freeway for hours.

Each day in India, I took a one hour commute to and from the office through complete chaos. We circumvented obstacles that would have shut down a US freeway for hours. The creativity on display was dazzling. And as an added bonus, I was thankful to be alive when I arrived at my destination!

Compare that to my commute in the US. Everyone lines up uniformly. We stay in our lanes. Creativity is discouraged. It’s not very exciting. My commute at home also takes an hour. It made me wonder: which system is more efficient?

Under what conditions is a system with fewer rules faster than a system with relatively rigid rules? It was tempting to look at the Bangalore traffic and speculate that perhaps it was faster in some ways. It was certainly more exciting (especially after a few beers late at night in an auto-rickshaw). However, a certain level of orderliness also has its benefits.

I find myself on my own humble commute now, cars stacked up in nice, orderly lines behind an endless parade of red tail lights – and I wonder, “What if we had fewer rules?”


Follow

Get every new post delivered to your Inbox.

Join 624 other followers