My Agile Journey: Waterfall Zealot to Agile Evangelist
My Agile Journey: Waterfall Zealot to Agile Evangelist
You might find yourself reaching this pivotal point when you realize that plans need to be flexible.
Join the DZone community and get the full member experience.Join For Free
See why over 50,000 companies trust Jira Software to plan, track, release, and report great software faster than ever before. Try the #1 software development tool used by agile teams.
When I recall my career as a project manager, one day seems pivotal. I was a new graduate in “programming”, as we called coding back then, and was hired at a major NY bank as a specialist in the then-new PCs and network group. After managing a migration project that went long and over budget, I was invited to a session with a senior programmer on the bank’s team, for what I expected to be a scolding. Instead, Jerry took me to a blackboard and explained the simple fundamentals of managing an IT project. Jerry drew four boxes on the blackboard, and put a ‘D’ into each one. “What do you think the D’s are for?”, he asked. I just stared, stupeﬁed. Jerry then condescendingly (this being NY), explained a simple 4D project management framework.
Discover, Design, Develop, Deploy. Being a typical New York guy, Jerry didn’t explain this to me in terms of critical paths or network diagrams.
“Discover what the guy wants, and what you’re walkin’ into.” Jerry advised. “Design a solution to ﬁx the guy’s problem. Develop that thing that you designed, then Deploy it for the guy.”
Over the next ten years of my career, I, like millions of IT project managers, ampliﬁed Jerry’s common sense project management philosophy by exploding each phase into tasks, assigning estimates to those tasks, and creating “gates” to ensure that no-one illicitly progressed without completing their activities. Those gates then became more codiﬁed, and eventually developed into the 17-binder proprietary project methodologies that were all the rage in the 1990’s.
I went to work for one of the Big 5 consulting ﬁrms, and was trained in their particular version of the multi-checklist, highly-enforced methodology. After a year, I became such a zealot of the regimented, gated approach that I joined the Project Committee. Then I got out in the field and quickly understood why it was unworkable in a consulting context. Simply put, no client being billed by the hour will abide dozens of hours of overhead, ﬁlling out forms and passing gates that don’t add business value. The amount of energy we spent trying to convince clients to pay for our project management time was prodigious.
I’d also noticed the beginnings of a “light methodologies” movement erupting, with guys like Rob Thomsett writing books like “Radical Project Management”. My quest became simple: ﬁnd a method that maintained the rigor of a phase-gated approach with the low-overhead of these new ‘radical’ project ideas.
When the overhead of the big consulting giant became too much, I moved to a local system integrator. This business, dealing with smaller clients and less complex IT challenges, was nevertheless struggling with consistent delivery. We spent a long time experimenting with different versions of ‘project toolkits’,and eventually reached a light, adaptable 4D-style model that was less likely to scare away clients. With the simple application of a lean project management discipline, we grew the consulting practice signiﬁcantly, and I became branch manager.
I left this gig to write my ﬁrst book, “The IT Consultant”, and began to travel as an advisor to other IT shops. A pattern became clear, the more small IT shops I visited. Either they were strangling in bureaucratic project regimes that destroyed their ﬂexibility, or they were making it up as they went along and disappointing clients.
I discovered a magic secret: put in place a few, simple project disciplines, apply some consulting skills, like collaboration and communication, and most IT shops will solve most of their problems.
On a writing assignment during this time, I interviewed Jim Highsmith, soon-to-be signatory of the yet-to-be-written Agile Manifesto, and Jim introduced me to ideas that were about to revolutionize the world of software development. The concepts of high-performing teams that managed and motivated themselves, of enforced client participation, of lean thinking throughout the process, fell so neatly in line with the on-the-ground experience I was having in the ﬁeld, that I quickly became an adherent.
Yes, agile is revolutionary for those who came up in a gated, waterfall world. And yes, it’s going to become a lot more revolutionary in the next few years, as these agile ideas of collaboration, speed-to-value, adaptability, and iterative, incremental delivery move up the ladder from IT through marketing to the executive suite. But it’s based on real, pragmatic experience.
Those who lived through the shift from PERT-method, Gantt-chart, predictive management know that it taught us a lot, but it got strangled in its inconsistency. You can’t possible predict how projects will go, no matter how many gates you set up or papers you sign. The technology changes instantly. We can’t know what clients will want, since they rarely know themselves. We can’t accurately estimate huge programs, but we can time-box and cost-box projects and deliver valuable, useful increments quickly. We can’t manage talented knowledge workers into compliance, but we can lead them to glory. Once IT executives, their teams, and their customers absorb these ideas, agile will change everything.
Published at DZone with permission of Rick Freedman , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.