My Agile Lightbulb Moment
Yesterday, Michele Sliger asked me if I would do a little writeup on my agile “lightbulb” moment… that point in time when I got it… when I was able to cast off the chains of traditional project management and accept agile as the one true way to salvation.
Okay, okay… Michele just asked me to write my “lightbulb” moment… I added all that other crap.
I find these kinds of stories fascinating… what makes one person able to see the benefits of agile when others cannot? What series of events could lead one person to look for a better way, and furthermore, be able to recognize that better way once it when it presents itself?
The switch to agile requires us to see the world in a new way…. to use a different map… to look through a new lens. Many folks who practice traditional project management fundamentally see the world through a lens of predictability. Traditionalists believe that with enough planning we can create a stable project baseline and manage the project into a successful outcome.
Agilists tend to see the world through a lens of unpredictability… they are more willing to embrace uncertainty. Agile project managers still want to manage the project into a successful outcome but they are more willing to allow the definition of success to emerge through the life of the project. The interesting question to ask is what leads someone to hold one world view over the other?
When you have been brought up in a business environment where projects are relatively predictable, the idea of predictability is reinforced. When projects go wrong, you try to track the failure back to some failed process… or some piece of missing information. The fundamental assumption is that with more planning we could have prevented the failure.
Our project management education teaches us that solutions come in the way of process, documentation, and control.
My early professional experiences were in environments of total chaos. It was not that I was working in poorly run companies (I was working in very large, very well run companies) but that I was constantly working in environments with new and emerging technologies. Furthermore, I was working with people that were knowledgeable, but not necessarily experts in the technologies we were trying to deliver.
Growing up professionally in this kind of environment taught me that uncertainty was the norm. As technology guy, working with other technology guys, I rebelled against managers that though we could standardize process around activities that were ultimately unknowable. My experience never reinforced that predictability was something that could be attained.
When I was promoted into formal project management, I tried to learn the science and best practice around my new job. We started using MS-Project to plan out our work and I got my first copy of the PMBOK Guide. The problem was that I could never get comfortable my plans ever quite reflected the reality of what was really happening on the project. The more I spent time planning, the more the projects seemed to drift off schedule.
There was a profound disconnect between what the books were telling me and what I was experiencing in real life.
To cope with uncertainty, I started laying out high level milestone plans and doing rolling wave planning to flesh out the details. I had to to trust the team to deliver. During critical times on our projects my teams would have daily meetings to talk about what we were doing and to discuss problems in real time. We started estimating in relative units and calculating how fast we were moving through our list of deliverables.
We found using these approaches that we could deliver more reliably, with less overhead, and deliver greater value to the business.
It would be a few more years before I discovered that others had already figured all this stuff out. It wasn’t until I started working with a development team that was already practicing XP that I realized there was a science behind what we had been doing… that there were other practitioners out there… and that there was an informal body of knowledge that I could lean on to expand my understanding.
I have always thought of my “lightbulb” moment, not so much as the moment when I understood (my career had perfectly positioned me for understanding) but more when I found my tribe. My moment came when I discovered that there was a community out there to validate and support what I intuitively already knew to be true.
So not so much a singular moment as a creeping awareness that blossomed over time? Or was the moment when you picked up a magazine and saw an article on agile that validated what you’d been doing all this time (for example)? Do you remember that first meeting/article/conference?
I started working with a team at CheckFree that was doing XP. Prior to that, I did not really know there was a thing called agile (although as I mentioned had accidentally been doing some agile practices by accident).
When I sat down and started talking with the Director of Development that hired me, that was when I had probably my specific moment of discovery. I started reading about agile like crazy… actually started with Sanjiv Augustine’s book and Mary Poppendieck’s book on Lean.
Everything that I was reading really resonated based on my experiences over the previous few years. The team that I was working with was pretty undisciplined in many respects and I started trying to model what I was formally learning in a way that I could actually run the project.
I discovered Scrum and Schwaber’s book Agile Project Management with Scrum. That helped me put some structure around things that had previously been unstructured. Of course, Cohn’s book on Agile Estimating and Planning helped as well.
So… those first few conversations with the Director of the team doing XP were the moment. That is what clicked everything into place. My philosophy around managing agile projects (as a specific discipline) emerged over the following year through reading and implementing the practices on real projects.
I guess we all have that aha moment. For me it was Ken’s Google tech talk. Never looked back since. What I like most is how practical Agile is. Just all seems to make so much sense. Mike Cohn’s book was instrumental in my learning.
For me, I was working with a customer who stated they delivered more in their 3 months of being Agile than they did in the previous 18 months of being waterfall. Once I started to understand the benefits of Agile to product management (regular points for feedback, ranked backlog, short succinct user stories, etc.) it really fell into place for me.
Thanks for sharing your story.
I am in the midst of my “AHA” moment right now while working through the experience of my first agile project. Everyday I find something new about agile that transforms me out of some old “traditional” mode of thinking. But at the same time, I’m trying not to get so caught up in doing it just the agile way that I lose sight of what made me successful in the first place. Agile does have some inherent short-comings and it takes strong thinking to overcome them.