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 SearchQualitySoftware.com about a new article by Scott Ambler:

Agility at Scale: Become as Agile as You Can Be
http://go.techtarget.com/r/9342644/8794862/1

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.