The Pillars of Agile Development

I was speaking to one of the guys on the team yesterday and discussing what I might propose for the Agile 2010 conference. (I gotta tell you, I’m somehow worried about what I might propose as I always feel that people who would be going to a conference, and paying good money to boot, won’t want to hear about my petty learning. He has convinced me that I am over thinking that one. I’m reserving the right to worry again based on how my proposal comes together.)

The basic concept is to talk about something I have experienced at each of the three major organizations I have proposed and led adoption of agile principles. This has happened in all three, even with hindsight being in my favor. What is it? It’s the feeling of hitting a productivity plateau somewhere around year 1 to 1 1/2 of our agile adoption. Over the span of leading these changes, I have realized that each organization seemed to be hyper focused in certain disciplines, and neglecting the others. Moreover, it seemed to follow a line dissecting Project Management methodologies from Engineering methodologies.

I know this concept isn’t new, but I call these the 2 pillars of agile. I think they are “pillars” because I feel none of the hyper productivity claims can truly be realized without both. If either is absent, you hit a productivity plateau. In my Agile 2010 proposal, I would like to discuss these pillars; the project and process management framework, and the engineering and development principles and practices. I might be oversimplifying this a bit, rolling lots of critical stuff together in one big package, but this is the way I have seen it unfold in all three major organizations.

Let me describe the adoption process and see if you see any similarities to your implementations. Typically, we have very focused, engaged teams in the initial adoption. Just meeting daily and retrospecting our work is a boon to efficiency. People love it. So much so, that the groundswell quickly spreads to other teams and eventually, management wants in. The promise of Scrum is typically alluring to IT managers. Who could blame management for thinking this way. “You mean to tell me I can see everything my teams are doing and have instant transparency!?…and the teams want to do that?” Why wouldn’t they push for that. (By the way, that’s not what is said, but I’m pretty sure that is what they “hear”).

What I am finding in my experiences is that, if Scrum or Project Management adoption is easy, then the 2nd pillar of engineering and software development principles comes extremely hard. If the opposite happens and the XP principles are first out of the gate and get the focus, then the adoption of a project management framework is hindered.

I truly cannot explain this with data, but have some theories. My current theory is that organizations that are willing to focus so much energy around project management and organizational “stuff” are typically ones that don’t truly value, or even understand, the artistic and complex nature of building software systems. If the inverse is true, then my theory is that engineers are the ones who’ve started the movement toward XP agility, and don’t have much sway over the teams that manage projects. When that happens, it’s difficult for engineers to get the necessary buy in from project managers or IT management.

So how do we fix this? Well, my strategy has been an evolutionary one. I happen to belong to the type of organization that has allowed Scrum to smash into it like a tsunami. It’s been good thus far. As my theory holds, our teams have struggled getting much traction in TDD and FIT test automation, pairing, continuous integration, etc. I do see pockets of adoption though. Some groups are great! The majority are hoping Scrum solves their problems. The goal is now to leverage those people who are trying to do both pillars effectively, along with some savvy project managers and make little additions to the culture over time. Like building a house, brick by brick.

I’m encouraged by some of the little wins we are getting so far, but moving ourselves off of this plateau will be difficult. That said, I think we can do it, and that means you probably can too.

2 thoughts on “The Pillars of Agile Development

  1. Pingback: Jason Montague
  2. Pingback: Jason Montague

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.