Mark Gilbert's Blog

Science and technology, served light and fluffy.

The Agile Path: Agile as a Journey (Part 2 of 2)

“The Agile Path” is a semi-regular update on the “agile” state at BlueGranite – what we’ve done, lessons we’ve learned, and where we’re going.

In the first installment of “The Agile Path: Agile as a Journey”, I had alluded to several reasons why there was a 3 year gap between my first exposure to agile methodologies, and actually doing something with it on a “real” project.  The short answer was – developer inertia (only some of which belonged to those around me).

At the time (2002), BlueGranite was very much a waterfall development shop.  I knew I needed the commitment of the full team (other developers, project managers, and executive team) to really make this work.  Looking back at that 2 ½ years I now realize that I wanted “team commitment” to mean more than simply “doing it because Mark-the-tech-lead mandated it on this project”.  I wanted people to see the value in it, and be active participants in helping to incorporate the techniques into our daily development lives – not just adhere to yet another standard.  I still believe that.

While “willing adopters” was probably the single biggest reason that kept this process moving at less than ludicrous speeds, there were others:

  1. I was learning this stuff from scratch.
  2. Researching these new techniques WASN’T my full time job (or even my part-time job), so time spent reading and tinkering had to be worked in around my day to day work.
  3. I was having problems finding a good way to introduce the techniques into the company.

Of these three, the last one was really the primary driver.  If I had recognized earlier how to apply some of the techniques I was reading about on a real-life project, I would have carved out more time for the other two, or even baked it into the project itself as “startup costs”.

As a result, the Phase 1 project that I started in early 2005 (please see my first installment of “The Agile Path: Agile as a Journey”) seemed like as good a place to start as I was ever going to get.  It was a relatively small project (originally planned for 3 months), it had a small development team (two full time developers on the project), and I was a major part of that team, and it was a greenfield development project.  This project was small enough that I could realistically touch every part of it, but large enough to give agile a good work out.  Even given all of those advantages, I still opted to start very conservatively, and only suggested changing when we post builds for QA to review (instead of one or two builds at the end of a milestone, we would post nightly builds into QA).

Sometime during Phase 1, it occurred to me that I could introduce a new technique (or a small number of techniques) into every new development project I was assigned to.  That realization led to some actionable items:

  1. I could look at the techniques that I hadn’t tried in a new light – what would the next most logical step be, now that I have techniques 1, 2, and 3 under my belt?
  2. If done well, the perceived risks in trying technique 4 would be mitigated by the fact that 1, 2, and 3 delivered a lot of value to the project. Past performance might not be an indicator of future results, but I believe they do lend some credibility to at least trying the techniques out. If a new technique doesn’t work, we can always change course – that’s agile, right?

So with those basic thoughts in mind, I planned Phase 2 to have a more agile structure: 2-week iterations where each consisted of talking about functionality at the beginning, building and testing it in the middle, and deploying it at the end.  Internally, I also made use of a project tack board where the functionality planned for a given iteration was shown on user story cards.  The board itself was segregated into several areas (“This Week”, “This release”, “DONE”, etc.), and we would move items around the board as things got done, or priorities changed.  It made it really nice to be able to get the team together every so often, look at the entire iteration at a glance, and evaluate what needed to be done next.

I say “cards”, but they were really pieces of paper.  I didn’t like the idea of keeping the plan for the current (or future) iterations ONLY on pieces of paper (hardcopy = not backed up at night), so I created an Excel spreadsheet to store the information, and a Word document that I could merge the Excel data into to create the small user stories on.  Then, I just print out the Word file, cut the stories apart, and mount them.  I ended up really only needing to do this once every iteration (at the beginning, when we had settled on what we were doing that iteration), so the time involved was minimal.  The warm fuzzies I had in knowing that that Excel spreadsheet with all of our plans and past performance was being safely backed up every night more than made up for the time spent.

Phase 2 officially came to a close at the end of the first quarter in 2006, and since then I haven’t been involved in any major new development projects.  I am on the verge of starting one right now, so I will be able to pick up some speed in my journey, and try some new things.  I expect to have an edition of “The Agile Path” that describes this new project of mine sometime towards the middle of 2007.

Activities, not necessarily methodologies

Something else that has occurred to me in the last few months is that I’m not necessarily going after a specific methodology like XP, Scrum, or Crystal.  I’m looking at the specific practices that agile methodologies pull together, see how they work, see how they bolster each other, and see which ones would be appropriate  to include in our own efforts.  Along the way I fully expect to find some that just don’t work here for one reason or another.  For example, I have read a lot of the benefits and downfalls of pair programming.  Of all of the agile techniques that I’ve read about, I don’t think any get more attention in- and outside of development circles as this one, and for good reason.  There is shift in approach needed to make pair programming work, and I’m not convinced that every developer is willing to make it.

I read a blog posting by Mike Arace recently (“I Am not a Robot”, from that described some problems he encountered when pair programming was introduced at his place of employment.  If you take away only one thing from his post, it should be the point that an organization’s culture can make or break any initiative, whether it’s trying to introduce pair programming, trying to get the team to shift from one source control system to another, or trying to change the brand of caffeine to stock.  If the people on the ground aren’t interested in trying X, there’s nothing you can do to make it work.

Sure, you can try to sell activities like this to the team (“but CocaDew tastes better”), you can try to mandate it (“you WILL switch to CocaDew”), or even tie rewards to it (“everyone who switched to “CocaDew” in the last quarter is up for a raise”).  I think approaches like these will in general fail spectacularly, cause the majority of the development team to leave, or both.

No silver bullets

I think it’s also important to realize the agile techniques are not silver bullets.  They’re probably not even shiny.  This is true from two different, closely related, aspects:

First, everyone rags on the waterfall method of development, and usually it’s because it’s “not agile”.  Something isn’t good or bad because it’s blue and not red; it’s good or bad because of the job that it was intended for, and how well it performs that job.  I think the waterfall method can work well for projects when you don’t have requirements changing every week, or can mandate that they don’t change after a certain point.  As it turns out, my company doesn’t have this luxury on the majority of the projects it takes on.  We’ve tried the waterfall approach, and we’ve had problems with our projects.  So, we needed to do a better job of matching the tool to the task.  We’ve realized that everything is not, in fact, a nail.

Second, the ability of the team to work together and actually wield the tool selected is a huge contributor to success of failure.  I studied judo for a few years, and one of my most memorable lessons was that “there are no superior martial arts, only superior martial artists”.  A black belt in karate will be much more likely to beat someone a beginning to kung-fu, not because kung-fu is inferior to karate in some fundamental way, but because the black belt will tend to be faster, more flexible, and more adept at reading their opponent, defending against their attacks, and responding with well-placed and well-timed attacks of their own.  These skills don’t magically manifest themselves overnight – they can take years to develop.  Likewise, it’s not enough for us as developers to read about agile, do it on a couple of projects, and then claim that we can deliver EVERY project on time, on budget, and to the client’s complete and utter satisfaction – purely because we’re “doing agile”.  Development will ALWAYS be hard work; agile just gives us a new toolset to better address the problems that the majority of us face the majority of the time.  We need to be honest with ourselves that mastering that tool may take a while.

The journey

So, if we can’t just “be agile” 100% out of the gate, and there’s no guarantee that it will solve all of our problems by lunchtime, where do we really stand?  We stand at the beginning of a journey, one that doesn’t have a destination, but instead a lot of cool sights and mile-markers.  Along the way, we will be able to look back at our progress, and say things like “we are more agile now than 6 months ago because we can better respond to problem X”.  As long as we can continually improve the process, delight customers, and deliver high-quality solutions, then we can say we’re on the right path.  If we can’t say these things, then we need to change directions – that’s agile, right?


January 15, 2007 - Posted by | Agile

Sorry, the comment form is closed at this time.

%d bloggers like this: