Sunday, October 18, 2009

Agile Adoption: Coping with the Speed of the Game

It's week seven of the college football season, the Buckeyes are on the road and so am I. Although I missed yet another Saturday class of Aikido, I'm not too bummed about it. I met my newly-born nephew yesterday, my sister's and her husband's first child. It's been a while since I've held a baby in my arms and holding Mateo Natan, all six pounds and two ounces of him, felt really good.

After spending the morning at the hospital, we headed out to my sister's apartment to help get things ready for their coming home. Ben and Marvi just moved from uptown Manhattan into a much bigger place in Brooklyn. They got a really sweet deal on an apartment with three bedrooms and a huge living/dining area. They have the baby's room all ready, complete with day bed and a mobile, bassinet, diaper disposal system, baby books, stuffed toys, a dresser full of baby clothes, pictures, posters, alphabet stickers on the wall, a baby floor mat, name it, it's ready. Everything looks good to go.

Just One Thing to Screw It All Up

Of course, anyone who has had a baby will tell you that no matter how ready you think you are, one thing can mess it all up: the baby.

Marvi and Ben, you guys are in for the ride of your lives and it ain't all going to be smooth sailing, no matter how much  you try to prepare. Don't get me wrong, there's absolutely nothing wrong with a little preparation. But there comes a point when you just have to go and do it. For Ben and Marvi, that point in time was when Marvi's water broke in the middle of a routine checkup with her Ob/Gyn.

This, of course, got me thinking about Agile, Aikido, and football again.

Just as the baby's arrival does with parenthood, in football, one thing can really screw up all your careful planning and preparation: the game. And what, you might ask, is it that screws up our carefully-laid plans in software development, including Agile?  Why, it's the problem you're trying to solve, of course.  No matter how well you try to prepare and lay out plans for creating a solution to the problem at hand, the certainty of those plans never really extends far beyond the first line of code written to solve it.  From the moment you start actually tackling the problem and trying to create a solution, your plans become subject to change for a myriad of different reasons.

According to this entry in Wikipedia , it was Helmuth von Moltke the Elder who wrote, "No plan of operations extends with certainty beyond the first encounter with the enemy's main strength," which is sometimes mistakenly simplified to "No plan survives contact with the enemy."

So Much To Do, So Little Time...

You've probably heard football players talk about the "speed" of the game when they go to the next level of play. Whether it's from high school to college or college to pro, players often talk about how much faster the next level is from the last. It's as though they felt like Lucille Ball in the classic assembly line bit: overwhelmed, helpless, and hopeless.

I'm sure many people trying to go Agile feel much the same way. Because just when you think you've got Agile-Scrum down, you realize there's a bunch of engineering practices from Agile-XP (Extreme Programming) that complement it.  And then you hear that there's a bunch of things from Agile-Lean that you can do to scale Agile to the enterprise level.  And so on. Have you ever seen that poster of a gorilla sitting down, looking really tired and dejected?  The caption says "Just when I thought I knew all the answers, they go and change all the questions."  Yeah, like that.

So what do you do when, just as you thought you had all your ducks in a row and were ready to take your organization to the promised land of Agile, a bunch of people start asking a hundred different things about what exactly is in store for them in the land of flow and quality and how are you all going to get there? What do you do when, as my colleague Michael so succinctly put it, "The horse is already out of the barn,"  and you realize that there are still a million different things to do that you didn't put down in your plan?

Too Much On Your Mind

When I started learning Aikido, my partners would often tell me that I was too tense. They could feel me tense up my arms and body whenever they grabbed me or attacked me or whenever they tried to perform a technique on me. In Aikido, tension keeps you from executing techniques properly and it changes the way your partner applies a technique on you.  It also makes for a less than enjoyable learning experience for both you and your partner.

What makes you tense up?  In Aikido, you tend to tense up when you think too much about what you need to do.  When you first learn a technique, you naturally want to do it exactly right.  You tend to break it down into all the little things you have to do: watch your footwork, your body position, how you break balance, how you control your partner, etc.  Then there's the technique itself.

In football, the players have to deal with lots of things all at once too: the game clock, the play clock, where the line of scrimmage is, where the first down marker is, where the sideline is, where the goal line is, the count, how the other team is lining up, how your team is lining up, etc.  And then there's the play itself.

In Agile, well, you already know how much there is to think about in Agile. How can you not tense up with all these things to watch for? What can you do to keep from freezing in your tracks like a deer in headlights in the face of the barrage of concerns people bring up when you tell them you're going to go Agile with them?

First of all, relax. Empty your mind.

My Aikido partners would always tell me one thing whenever they felt me start to tense up in practice: "Relax. I won't hurt you." After a while, I learned to trust my partner and myself.  I learned that relaxing made it easier for me to receive the technique when it was performed on me.  Relaxing also made it much easier for me to perform the technique. I found that when I didn't think too much about every single thing I needed to do, I could actually do everything better. In Aikido and many other martial arts, it's called "the empty mind." In football, it's that seemingly magical transformation in players that happens when they "settle in" and learn to "slow down" the speed of the game.

In Agile, it seems it's not that simple to just relax. Or is it?  Let's see, we have the prioritized backlog. We have the timeboxed iterations. We have the principles of "Doing The Simplest Thing That Could Possibly Work" and "You Ain't Gonna Need It."  We have the feedback loop from retrospectives, and sustained incremental delivery of working software, and frequent customer demos of working software. We have the daily standup meeting.  We have "Eliminate Waste" and "The Last Responsible Moment."  We have the "40-hour work week," and so on.

If we just pause long enough to catch our breath and look hard and understand the intent of the Agile techniques and practices, you'll see that they all add up to humbly accepting one simple truth: "You ain't always gonna get it right the very first time."

Second of all, don't stop.

The other thing I heard a lot during Aikido practice is "Don't stop. Keep going."  When you're learning a technique, there's a natural tendency to stop and start over when you realize you did something wrong like turning the wrong way, pointing your foot in the wrong direction, or not breaking your partner's balance correctly. After a while, you realize that making mistakes is a big part of the learning process. That's why you just have to keep going and finish the technique.

Sometimes, it's not what you do that changes the dynamics of execution. In Aikido, we practice with different partners of different ranks. Each one receives the technique differently. What may work for one does not necessarily work for another. But still, you keep going and finish the technique so you can learn to feel the difference.

In football, this is the same as getting YACs, yards after contact.  If you're not dragged to the turf on first contact, you keep moving, keep your legs pumping, keep the pile moving, try to break tackles, and fight for every extra yard you can get.

Software development and Agile are no different. No two projects are the same. Why do you think there are so many different accounting systems out there? And the business problem is always changing under you. There's always something that puts us back on our heels, tips us off balance, making us adjust to the new state of things.

The opponent doesn't stop the attack when you mess up a technique. The play doesn't end when that first tackle is made. The game doesn't stop when you turn the ball over. The need for a solution doesn't go away even when your understanding of the problem changes. The business doesn't cease operations just because you're not doing "pure Agile."

If, as apparently the Buckeyes did at Purdue today, you lose a game, you shake off your disappointment, go over the film and learn from your mistakes, and get ready for the next game.  If the software isn't doing quite what it's supposed to yet, you write another test, write more code, refactor, and schedule another demo.  If your development process isn't delivering all that Agile promises, you have a retrospective, put a process improvement story in your backlog, and get it done in another iteration.

It's all about improvement

There are no promises of a black belt, no promises of a championship title, no promises of development bliss and total customer satisfaction.  If, in the end, you do get all that, then that's just a lot of icing on the cake. The whole point really is just doing something and trying to get better at doing it. That's all we can really shoot for, right?

"The reality is that nobody is going to give you a little gold star for being agile. They might, however, reward you for becoming more effective at system delivery." -- Scott Ambler, Chief Methodologist / Agile & SOA, IBM Rational

As for Ben and Marvi, well, only time and Mateo Natan will tell you what you guys need to do next. Good luck and remember: relax and just keep doing what you gotta do. You'll be fine. Mazel Tov!

Wednesday, October 14, 2009

More Agile Analogies: Football

It's fall again and for me that means Saturdays are reserved for watching the Ohio State Buckeyes play for another Big Ten title and a shot at a Bowl Championship Series game in January. Three hours of watching college football gives me a lot of time to think about agile and lately, I've been thinking about analogies. Here are just a few that have come to mind these past few Saturdays.

Going agile is like switching from "three yards and a cloud of dust" to a "spread option" 

» Your players are going to need time to adjust to the new plays before they'll be effective.

» Some players will quickly take to the new scheme because it suits their style of play.

» Some players will quit the team because they just can't handle the new style of play.

For example, look at what happened to the Michigan Wolverines after Rich Rodriguez took over from Lloyd Carr. The Wolverines went 3-9 for that first season under Rich Rod, the worst in the program's history. This season, with a new quarterback and players who are more accustomed to the type of play, they are starting to get a lot better again. Hopefully, they get good enough to at least make the game against Ohio State interesting.

Successful agile teams are like good football teams

» They are good all around: offense, defense, special teams contribute to winning the game.
See Agile - What is it?

» You take the game one play at a time.

» You get to the goal by getting a bunch of first downs and moving the sticks.

» You have to finish a drive to score; you don't get points for punting.
See The Discipline of Regular Delivery (of working software)

» Don't blow your coverage.

» Play with a controlled rage.

» Take care of the ball at all times.

» Be prepared to call out an audible.

» You have to play the full sixty minutes.
See Sustainable Pace

» Miscommunication will get you in trouble.

» Sometimes, the best decision is to just throw the ball away.

» Eleven men on the field, at most.

» They recruit talented players.

» The best and most experienced, not necessarily the most talented, players are the starters.

» The "star" players always recognize that due credit must be given to the O- or D-line.

» When you make mistakes you go back to the film room and study what you did wrong so you can improve your play and avoid making the same mistakes in the future.

» When you make good plays, you go back to the film room and study what you did right so you can improve your play and do it better in the future.

» Huddle up before the play to make sure everyone knows what we're doing.

» Have players who can make good "reads" of what the opponent is going to do, who are able to make "adjustments" quickly, who can find a "seam" and gain good yardage, who can see the "holes" in the defense and capitalize on them, who can "feel" the pressure of a blitz coming.
See Four Stages of CompetenceRefactoringCode Smell

» If things are getting a little hairy, call a timeout to talk about the next play.

» Listen to what Coach says.

Sometimes you gotta wonder if some of these football coaches would do just as well coaching agile teams. Let me know if you have any other football-related agile-isms or agile-related football-isms and/or links to related articles.

Thanks and GO BUCKS!

Tuesday, October 13, 2009

Agile Analogies: Aiki Training

While going through the results of a self-googling search—no, I wasn't stroking my ego, I was simply trying to figure out if and when I had added my name to the list of signatories of the Agile Manifesto—I stumbled upon an old entry in Damon Poole's blog about Agile Analogies and was pleasantly surprised to see that he had actually quoted me. And yes, at this point my ego was getting somewhat tumescent. I vaguely recalled the text that was quoted so I kept going through the results and found more Aiki-related analogies I had made in comments about an article written by Martin Fowler posted on

Damon Poole's blog entry: Do It Yourself Agile: Top Ten Agile Analogies

Wednesday, September 30, 2009

Aiki and Agile Software Development

I know it may seem like a bit of a stretch to compare agile software development with the Japanese martial art of peace and harmony. But if I can draw parallels between software development and playing football, it really doesn't take that much to stretch the imagination a bit further and compare it to Aikido.

Take this for example: a person's natural instinct when threatened with bodily harm is to move away from the threat. In Aikido, students are taught something that goes against this natural instinct: irimi, or entering into an attack.  Turns out this can be a valid and very effective response, too, as long as you know what you're doing and you observe a few very basic principles.

For many programmers, their natural instinct when faced with a coding problem is to start writing code to solve the problem. Writing a unit test first to explore the problem and a possible solution is as counter-intuitive as moving in closer to the source of a physical threat.

However, with practice, both programmers and students of Aikido soon realize that sometimes the safest and most effective way to deal with a problem/threat is that which goes against their natural instincts, again with the caveat that some very basic principles must be followed. With even more practice, new habits are formed and moving in or writing a unit test first becomes the new natural instinct.

Some of the basic principles used when executing an irimi movement include tai sabaki or moving your body to a position that will render the attack harmless and from which you can begin to control the attacker, kuzushi or breaking the attacker's balance or otherwise gaining control of their center, and zanshin or "remaining mind" where you maintain a mindful connection with the attacker after executing a technique so that you can transition smoothly to the next action, if necessary.

For the agile programmer, irimi is making the decision to ignore your natural instinct to start writing code or reach for your debugger but instead write a unit test first.  Tai sabaki is finding that first condition to test that will isolate the problem or at least the most pressing part of the problem so that you can start identifying a solution to apply.  Kuzushi is running your test and seeing it fail, to demonstrate clearly that something is broken or out of whack.  Zanshin is going back over the code once your test passes, being mindful of other problems that may arise in the future because of the quick solution you just wrote and refactoring the code until the threat of bad code is mitigated or eliminated.

If you're still not seeing the parallels, I suggest you try finding a dojo and joining a class.  Most dojos will let you try out a class or two for free.  It's actually quite enjoyable since people who practice Aikido seldom really get hurt. And it's a great workout.  Actually, you can say the same thing about test-first development, too.

Tuesday, September 29, 2009

Square One Agile: Individuals and Interactions

Call it coincidence, serendipity, good vibes or just pure dumb luck, it seems like whenever I have something on my mind, I get something in my mailbox that relates to it.

This time it was something from about a new article by Scott Ambler:

Agility at Scale: Become as Agile as You Can Be

In my last post (also my first one), I wrote that to be truly agile, a team needs to have members who are themselves agile.  In his article, Scott Ambler talks about the Agile Process Maturity Model (APMM).  It's good to see that Ambler counts investing in your staff as one of the strategies for increasing your chances of success at improving your software process. It's also interesting to note that this particular strategy was the last one listed, although I don't know if the order necessarily implies importance. Nonetheless, to me it highlights the irony that despite the first belief in the Agile Manifesto favoring "Individuals and Interactions over Processes and Tools," the focus of most agile adoption efforts is mainly on the processes and tools.

If you look at the history of Agile, you can trace its roots back to the efforts of some developers to improve the way they wrote code and developed applications. Naturally, they focused mainly on coding and engineering practices. And while improved coding and engineering practices were good things, it soon became apparent that they weren't quite enough. Different management practices were needed that aligned with the new engineering practices. This led to agile practices evolving into agile processes and agile processes becoming agile methodologies. Now it's common to see organizations employing an amalgam of XP, Scrum, Lean, RUP, DSDM, FDD and others to have a holistic approach to Agile adoption.

All these different agile processes are good and training staff on them is absolutely necessary for success. I'm just worried that many organizations out there are assuming that as long as they train their staff, particularly the developers, on the agile processes, then everything should be hunkydory. Therein lies the rub. The fact that a fundamental change needs to happen with each individual on the team sometimes gets overlooked or taken for granted. After all, developers should know how to develop, right? But without agile developers, a team is going to struggle with the basic challenges that spawned agile in the first place.

You don't expect a tadpole to turn into a frog just because you put it on dry land, right?  Likewise, you can't expect non-agile developers to turn into agile developers just because they're given an agile process to follow. Just as you wouldn't man a destroyer with a crew from an oil tanker, it would be ill-advised at best and irresponsible at worst to expect a development team whose members know only "traditional" development techniques and expect them to become an agile team after training them on the agile processes. That's only a small part of the training these developers need.  They need to get back to the basics: they need to learn the habits and skills that will make them agile.

They need to know how to refactor code, how to write good automated unit tests, how to recognize code smells, know how to make appropriate design decisions, and develop new habits for working collaboratively and in a disciplined and self-organized manner.  It's like taking a football team from a traditional "three yards and a cloud of dust" playbook to the so-called "spread offense" playbook.  It's a whole new game, an entirely different scheme.

In my next few posts, I'll go over some of the basic skills and habits that the nouveau agile development team member needs to learn so they can play well on the agile gridiron.

Saturday, September 26, 2009

Seek Ye First to be Agile to be Truly Agile

No, that's not a typo. Seek first to be agile to be truly agile. In other words, agile teams need agile developers.

"Well, duh!" That's like saying "Race cars need race car drivers," isn't it? Exactly.

As agile adoption continues its inevitable and inexorable advancement into the mainstream, the ranks of "traditional" development organizations jumping on the agile bandwagon continues to swell. I suspect that not just a few of these organizations are going in practically blind, pushed into the vortex by the pressures of having to stay competitive and productive in these challenging times. These are the organizations that can no longer ignore the overwhelming evidence that agile methods are in fact effective after all.

So, they start retooling their processes. They abandon their MS-Project plans (good riddance!) in favor of Rally or Mingle and switch to regular timeboxed iterations as recommended by agile. They start retooling their people, too. Well, some of their people. Team leaders, senior developers, and project managers are sent to attend two-day workshops to get certified as Masters and Owners in the new agile process. If they're lucky enough to have the money, some teams will even do the smart thing and hire a Coach.

Yet for some, despite their best efforts to go agile, there will still be little or no joy of agility.

There are many reasons why teams fail with agile but common sense would tell you that one reason is simply that the team itself just isn't agile. But then again, as Murphy would say: Common sense isn't.

So how can you overlook or ignore the fact that your team just isn't agile enough to be agile? I don't really know for sure but my guess would be that it has a little to do with not knowing what you don't know, empathy, pride, and survival instinct.

Let's say you work at a pizza joint. Your boss just bought this new pizza delivery truck: the Jiffy. You've heard a lot of talk about it before and your boss even said once that it was just a crazy gimmick that would soon go away. But after hearing about the success that other pizza joints are having with the Jiffy, your boss realizes he might be losing out on something good and decides to take the plunge and get a Jiffy too.

The Jiffy is supposed to help you make pizza deliveries a lot faster. Your boss has a lot of expectations and so do you. Make and deliver pizzas faster, pizza sales go up, boss makes more money and you make more tips. Everybody will be happy. It will be great.

The Jiffy dealer recommended that for best results, there should be at least one Certified Jiffy Operator (CJO) who can oversee the use of the Jiffy and ensure safe and proper operation. Of course, you being the pizza crew chief and senior pizza delivery guy, your boss sends you to the CJO course to get certified.

During the course, the instructors teach you all about the Jiffy and how you and your pizza delivery team will use it to deliver great-tasting pizzas in thirty minutes or less. They take the class through a number of fun and thought-provoking exercises on the principles of Jiffy operation and efficient pizza delivery. You even get to drive a go-cart around a small closed course so you can get an idea of what it would feel like to make and deliver pizzas in a Jiffy. Of course, the go-cart is nothing like an actual Jiffy but you are made to understand that the principles you learned are pretty much the same. Fine, how different could the real Jiffy be, right?

So, with a crisp new Certified Jiffy Operator certificate in hand and the secret CJO handshake in mind, you go back to your motley crew of seasoned pizza makers and deliverers and tell them to get into the Jiffy so you can start making and delivering great-tasting pizzas in thirty minutes or less. Your guys don't know anything about the Jiffy but since you've just been certified, they climb in with you with full trust in your ability to handle the Jiffy and lead them through the new pizza-making process. With everyone strapped in, you get in the driver's seat and head out.

The going is slow on the first few deliveries. But that's understandable, you tell yourself and your crew. Things will get better as we all learn the ropes and get experience in the new Jiffy workspace, which by the way, is everything you all expected it to be and more.

You're all excited about the Jiffy and its potential but also a little overwhelmed because you start to see that there are so many different features of the Jiffy that you didn't get to really learn about in the CJO course. But it's fine since you're familiar with the basics and you're following most of the important instructions in the Jiffy Operator's manual.

After a while however, your crew's performance in the Jiffy starts to suffer. You start missing deliveries and pizzas are made that are not quite what the customer ordered. You wonder if there's something wrong with the Jiffy or with how you're using the gadgets. You start to doubt if that CJO certification course really meant anything. But you begin to realize that the reason you and your crew are falling short in the Jiffy is not because of the Jiffy itself. Rather, it's because your crew is not really equipped with the right skillset that will make them successful in the Jiffy.

You realize that the guys in your crew are still relying on their "traditional" pizza making skills and habits instead of the new pizza-making techniques they need to use in the Jiffy. They need to learn how to use the automatic crust roller instead of kneading and tossing the pizza crust by hand. They need to learn how to punch in the pizza quality checks into the PQ-Unit, the automated pizza quality checking device, before they even start putting the pizza ingredients together. And they have to add one ingredient at a time, running the pizza through the PQ-Unit every time a new topping is added to make sure the pizza they've made so far is still all good. And that's just for starters. There are many other "traditional" work habits they need to unlearn.

But the guys on your crew are just not used to other ways of making pizzas and you don't know how long it's going to take for them to learn how to make pizzas the Jiffy way. You do your best to teach them by showing them how to use the new gadgets and techniques but you kind of end up doing the bulk of the work they should have been doing. Meanwhile, you're getting behind on all the other things you're supposed to be doing as the CJO and it's getting more difficult to get the Jiffy to the next delivery stop in time. You like the guys in your crew because they're good pizza makers and you know they have skills; just not the skills you need to make the Jiffy run as efficiently as it could be.

Your boss asks you how things are working out with the Jiffy and you tell him things are going pretty good. You also tell him there's a bit of a learning curve and you''re going to need some time to get everybody on the crew retrained on all the new Jiffy techniques. Your crew is still delivering great-tasting pizzas although maybe not under thirty minutes all the time.

Get my drift? You can't really do it in a Jiffy if not everyone in the whole crew knows how to do it in a Jiffy.

I'm not much of a gambling man but I'd be willing to bet a buck that there are teams out there in the wild like my CJO and his pizza crew. If you've had similar experiences, I'd like to hear what you do to cope with a team that's just not as agile as it should be.

DISCLAIMER: The "Jiffy" and the people, events, and situations described above are fictional and are entirely the figments of the author's sleep-deprivation-driven imagination. Any similarity to actual pizza delivery trucks, people, events, and situations are purely coincidental.