My Agile Journey…

This weekend marked the 10th anniversary of the creation of the Agile Manifesto. Part of 10 Years Agile was to reflect on the progress of Agile over the years and the conversations on Twitter have been fascinating.  I thought it was a good time to reflect on my own journey with Agile.

I first heard about Agile back in 2004 – before I even thought about switching over to software.  Unfortunately, my first look at Agile was a presentation at a project management conference.  The consultant and a programmer passionately talked about the power of Agile to an audience of experienced traditional project managers, some of whom were working in highly regulated industries.   The reactions to the statement about working software over comprehensive documentation were priceless.  I was more confused than convinced after that presentation.

When I entered game development I began to develop a love-hate relationship with Agile.  First, I had to get over the culture shock.   I was expected to assign, manage and track programming tasks, which was completely bizarre to me, since none of my managers had ever done that with me when I was an engineer.   I loved that I could use Agile to describe the values I had developed earlier in my career.  Three months into my new job, I was asked to manage a very challenging innovation project that could best be described as “Agile-but”.  We didn’t have a clear customer who could work with us.  We followed all the regular communication and tracking practices of Scrum but never used that name.  The team was perfectly content with working in isolated silos on their own vision of the project, quoting parts of the manifesto that suited them.   That’s where my hate relationship with Agile began.  At that point, my grasp of Agile wasn’t strong enough to fill in the gaps and align the team.  We muddled through, the project was considered a success, and it was still the worst project I had ever worked on.  I had spent four months herding cats and we succeeded due to the force of our collective will.

It all fell into place for me after I signed up for a ScrumMaster course with Esther Derby.  The pre-requisite for the course was to read Ken Schwaber’s book, Agile Project Management With Scrum, which finally made the link between my hardware/manufacturing world with Scrum and Agile practices.  I am sure some of the founders of Agile aren’t happy about the “factions” that have emerged: Scrum, Lean, Kanban, etc.  The ones I listed all have their roots in manufacturing, so I love seeing the application of those concepts in a new context, though they may not completely hit the mark.  Still, between the book and Esther’s training, it worked: I was converted.

Even with physical constraints, technology manufacturing was the most truly agile (read: flexible, adaptive, results-focused, ego-less) environment I have ever worked in.   Those who understood thrived.  Those who didn’t eventually moved on to other roles.   Sadly, this is where Agile is going down the same path as every other project management or development method.   It is focusing more on the what and the how to become Agile (capital “A”) than on why organizations need to be agile (small “a”).   Most human beings love clearly defined steps to success.  However, processes only work if the people using them buy into why it’s a good thing.  Certainly, the leaders of Agile have bought into it, but the message is lost on many teams in the adoption process.  If the teams truly understand the why, then they will naturally adapt or develop the tools and processes needed for their projects and companies.   Agile can change cultures, but only if leaders and coaches spend more time coaching, influencing and demonstrating to their teams why being agile is necessary for the business.  For companies with core culture and values that are far away from agile values, the effort to building that understanding is tremendous and change is slow.  With the pressures of business to see results quickly Agile fails for those companies.  In those situations, a step-by-step process may be a good first step to show results, but it is difficult to sustain.  Embrace the current culture and use that as the starting point to get the desired culture.  Either way, it’s about putting egos aside, working closely with people and adapting to change.

Here’s to Agile continuing to evolve and change the way we work!

Related articles

• The Best Scrum-ban-plan Board Ever!
• Brief History of Agile Movement (udayanbanerjee.wordpress.com)
• Agile And PMI: It Is Not A Competition
• Taking An Agile Project To The Next Level