My colleague and co-worker Lee wrote a bare-soul post recently about missing the boat as a developer, and it prompted me to do my own version about Agile development. Lee impressed me with his candor about his experience in software development. He laid his "code" soul bare for everyone to examine. That takes guts and thus the inspiration for this post.
I had a similar experience with Agile software development, albeit was a bit shorter time frame. Like many developers, I was well into my professional software development career before I was exposed to Agile. But even after I was exposed to Agile, I kept it at arms-length for some time, not really sure what to make of the new approach.
My introduction to Agile came at an organization that was in the process of converting from a rigid waterfall/phase-based methodology to Agile. We were learning as a group with the help of a few Agile consulting firms. Our organization had a few green, inexperienced, Agile advocates to provide a start. But for better or worse, we had to mostly stumble our way through the Agile learning curve.
I am a natural skeptic. I probably get that trait from my father who is the skeptic of skeptics. So when faced with these new ideas from the burgeoning Agile community, my natural skepticism kicked in. Abandon big up-front design in favor of emergent and incremental design? Crazy! Software requirements on a note card? Nuts! Writing unit tests before the code? Heresy!
As my organization explored Agile principles and practices, I thought about all the software engineering conventional wisdom that I relied on so heavily in the past. And everything about this new Agile approach just seemed so counter to my professional understanding. But as we experienced Agile development first-hand, it became clear that this movement had substance.
Soon we considered ourselves an Agile shop. It seemed that everything should be perfect. We left our dysfunctional waterfall days behind. We had the support of IT and senior management. We were doing Agile!
But through that experience, it felt like we still were battling a form of Agile low self-esteem. We seemed to continually question if we were doing it right. Were we Agile enough? Oh, there were plenty of helpers along the way. For any organization with a few thousand dollars to spend, there was an endless supply of Agile consultants willing to tell us that being Agile means doing “x.” Or to measure your Agile-ness, you could take an assessment to determine exactly how Agile you really are.
Eventually, I made an important observation about what it meant to be Agile. I found that Agile was just a means to the end, and not the end itself. It is futile to try to pump up your Agile self-esteem by convincing yourself and your team that you are indeed “Agile.” That you have arrived somehow in Agile land. Agile is not a state. Agile is not an end. Agile is just a vehicle, just a means to a goal.
I found my boat. Have you found yours?
