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.