My agile journey began unexpectedly back in 2005. My client was launching a new IT services business unit and made a strategic decision to become an agile organization. That simplified matters considerably because there was strong senior management support. The problem with the agile transformation was mine – not theirs. As a PMI-certified project manager who had been utilizing a traditional waterfall approach for many years, this move to agile seemed like a risky decision.
My client tolerated my objections, allowed me the opportunity to participate in their agile training and then allowed me to use the framework to manage a new program. Thus began my agile journey. All told, it took nearly two years to become comfortable with this new approach and to overcome various challenges, a few of which are described below.
Challenge #1 – “Say, what?”
In the world of agile, the lean adherents speak of WIP, XP aficionados extol the virtues of pair programming and scrum proponents talk about chickens and pigs. Each agile tribe has its own language and all of it is foreign to the business owners. In some cases the new language was needed, but often it was simply jargon and a barrier to effective communications. Where new terminology was needed, we endeavored to explain the terms to external stakeholders. Where it was not needed, we dispensed with the “magic words and secret handshakes” and used English to communicate with business stakeholders.
Challenge #2 – Communicating with Senior Leadership
One of my first “agile” steering committee meetings featured a burn-down chart that I developed to depict progress from 10 different work streams. Some of these work streams were making good progress and others were not but, in aggregate, everything appeared to be just fine. But everything wasn’t fine. The two or three work streams that were falling behind were critical to the success of the program. The burn down chart was technically correct but useless for this purpose. After some failed attempts to explain the burn down charts, the steering committee members requested that we resume the commonly accepted practice of “Red, Yellow, Green” milestones by work stream. An agile purist would have objected but programs are run by pragmatists, not purists.
Challenge #3 – Differing interpretations about what is really “agile”
During my agile transformation and in the years following, I’ve heard varied answers to the question, “what is agile?” For some, agile meant never having to say they are late because they thought making schedule commitments was “just too waterfall.” Others proposed that agile means management served no particular purpose so should therefore be kept in the dark. Last but not least, there were those who refused to produce documentation the agile manifesto said they shouldn’t. Or so they thought. Over time, we adapted to business reality by doing “just enough” schedule commitment, management oversight, and documentation.
Even after all of these years, my personal agile journey continues, as do the challenges. Responding to these challenges requires keeping the following principles in mind:
- Focus constantly on the success of the project
- Listen to feedback from project stakeholders
- Adjust the practices as needed to address the challenge
- Remain consistent with agile principles and values