I’m often asked why I do what I do. It’s simple really.

In the late 1990’s I was an early adopter of Extreme Programming while working at Lucent. I was in a leadership role, leading software development and test teams, and it seemed to me to be an interesting way of effectively building software.

I had struggled with Waterfall approaches for years. I’d even worked hard at refining my estimation processes. But my projects were inevitably challenged and many failed to meet critical criteria. That is – projects that met all aspects of our stakeholder expectations.

When I stumbled on XP, it just…resonated with my experience. It also resonated with my leadership style and beliefs that PEOPLE were the central success proposition in software efforts.

Not: risk plans, test plans, project plans, management spreadsheets, cost accounting, estimates, system requirement specifications, metrics, status reports, etc.

Early Adopter

So, it’s relatively safe to say that I was an early adopter of agile approaches. I was using XP soon after it was introduced. I was also an early adopter of Scrum, not just in its entirety, but leveraging aspects of it.

Over the years, what’s excited me about agile is not the specifics of any method or the individual tactics. It’s when I’ve managed to inspire an organization to truly embrace the “package” of agile & lean principles and practices that something magical has happened.

The teams themselves have become empowered. They start to work collaboratively and deliver more than any one of them individually is capable of.

The business side starts to engage the teams in a new way – as partners and with mutual respect and trust. Its this combination that creates something powerful, in a word, it’s the results of agile done well that inspire me.

But it’s not that easy!

Since being an early adopter of agile approaches, I’ve discovered quite a few things. I’d like to share some of the more compelling learning’s I’ve had in my own agile journey:

• Agile doesn’t mean you marginalize roles like tester, project manager, or manager over developers. I’ve found the best teams have a mix of skills, backgrounds, and perspectives.
• A self-directed team does not mean there is no leadership or that the inmates are running the asylum. Leadership is required.
• Agile isn’t intended to focus on speed. It’s intended to focus on flow and quality, which if done well, can lead to speed.
• Continuous improvement is hard. It takes solid coaching and self-aware teams to keep consistently getting better.
• Teams (and organizations) still struggle mightily with two critical things – asking for help and saying I don’t know. I don’t know why that is.
• Successful agile transformation needs leaders, visionaries, and change agents. These folks also need to “step back” and allow the teams to emerge.
• We talk about collaboration being a central theme within agility, but we avoid it in distributed teams.
• I wish teams were more amenable to running experiments and failure, particular the latter. The ‘F’-word still seems to cause most folks to shudder violently.
• There is an increasing trend for organizations/teams not to commit to a full-set of agile practices, which sub-optimizes their results. Sad really!

Wrapping up

But beyond all of that, the agile approaches truly resonate with my essence as an experienced software developer, leader, and coach. It’s the best way I’ve found to build software, teams, and organizations – period. Its honest, balanced, value-focused, transparent, and people-centric.

I’ve found that if you get the balance right, it brings out the very best from the great people you’ve hired.

And there is no greater honor or responsibility than an organization inviting me into their home and asking me to partner with them on their agile journey. Its something that I take very seriously and I value each and every opportunity. And quite frankly, it never gets old, which is why I do what I do.

Stay agile my friends,

Bob.

Interesting article by Tobias Mayer