About fifteen years ago, I remember a Client at a large Financial Services firm calling me into her office late on a Friday afternoon and handing me a book on Extreme Programming. She asked me to read the book over the weekend and tell her on Monday if I could lead a new team that she was putting together, utilizing her best developers and business resources.
She wanted to use this new iterative paradigm to build a new business application to report on overseas revenues. I read the book and that Monday I walked into her office to say that I could absolutely do it. I thought, “How hard could it be?” I had good programmers, business people I trusted, and what I thought was a generous timeframe of four months.
My job was to run the project and report back on the pros and cons of this new method of rolling out an application. Needless to say, the effort was a borderline disaster. Two and a half months in I realized there was no way we were going to deliver this straightforward, relatively simple application to the client. I was mortified but determined to deliver the application on time and operating correctly.
So, what did I do? I ripped up the plan for delivery in an iterative fashion and we developed the entire application in the way all of us on the team knew very well – using the Waterfall method. We wrote specs, did all the sign-offs, coded like mad people, and did all the requisite testing. We completed all the tasks and delivered on time!
One day before my deadline I strolled into my Client’s office, whipped out my laptop, and proudly demoed the application without a hitch. I was expecting accolades for all my team’s work, but all she said was, “Where is the report on using the new methodology?” Sheepishly, I had to tell her I abandoned that path to get the job done. Her reply was terse and direct: “You failed. I don’t care about the application, I wanted to find out if this crazy idea of Agile can work.” I learned rule #1 of transforming to Agile that day, that the one given about any Agile development project is that it’s easy to give up.
I asked for another chance to develop a different application and thankfully got my second opportunity to find out about Agile. This time I stayed the course, was a little late, but the application was completed, and I turned in a document on the pros and cons of each methodology. This was the start of a roadmap detailing my journey with Agile, along with lessons learned and recommendations to move forward.
My plan is to write a series of articles drilling down on topics that are important for your organization to start or complete the journey from Waterfall to Agile. To start, I will provide some high-level thoughts, strategies, and tips on how to become Agile proficient without recreating the disaster I described above. For starters, those who have significant exposure to Waterfall know all the elements and it’s pretty simple to follow along. Everything is done in a linear fashion and nothing new starts without the previous task or phase is 100% complete and signed off by stakeholders.
Iterative or Agile (I’ll use the terms interchangeably going forward) rely on a series of analytical iterations of business needs and code construction, aka sprints, which are built on each other to produce a stable code base without a significant rewrite. I often describe the difference between the two as the difference between playing a one-dimensional game of checkers vs. playing 3D chess.
Let us look at the differences at a more granular level:
Now, back to my near Agile disaster so many years ago. I want to point out that the client I am referring to in this article is now primarily an Agile shop and I often communicate with them to see what innovations they have added to their base Agile methodology. What lessons learned did I garner from the second, successful Agile project? Here are some important points to consider as you move to an Agile-based organization:
Education – Before jumping into your project headfirst, take time to become educated on Agile and how to practically transition to the methodology. We often see clients make an executive decision that all development going forward will be Agile without investing in the basics of how to implement and transition to Agile. One client built a virtual Agile Center of Excellence Education Center, where anyone could submit questions in real-time, be provided with seminars on any topics causing project difficulties and the Center’s output served as a vehicle for building Best Practices.
Communication & Collaboration – Business and Technology organizations are not used to symbiotically working together. Agile development can not be successful without functioning side by side (or virtually in today’s Covid-19 world) and providing direct communication.
Start Slow to Go Faster – It is hard to start an Agile practice from scratch, especially if there are significant numbers of resources that are used to working in siloes. Choose projects to start that are good candidates to succeed – whether that be cherry picking the application or resources. I have seen so many organizations start off at warp speed with the best intentions to succeed but get stuck because the new paradigm cannot be integrated into the DNA of the organization automatically. It is going to take time.
Utilize Tools – Agile has tools for practically everything. Unlike many of the legacy tools for waterfall-based projects, Agile toolsets were built along with the methodology and are therefore tightly integrated with the concepts of the methodology.
Keep the Transition Going! – Do not do what I did. I panicked after facing methodology issues head on. Because it is a new paradigm, one usually has no clue whether the challenges you will encounter are showstoppers or minor issues that can remediated with a tweak or two. Use your resources, especially if your organization has developed a Center of Excellence.
So why take the risk of moving from Waterfall to Agile Methodology?
Quite simply, once you get it right, after the start-up bumpy ride, Agile projects are delivered faster and with fewer errors. But how much quicker and how much cleaner? I usually quote a 30% reduction in time to build a project with Agile vs. Waterfall and the rate of Severity One and Two errors reduced by 75%. Furthermore, those errors are typically not the showstoppers that occur when the business community looks at an application for the first time after a lengthy development effort and the business owner blurts out, “That’s not we wanted!”
In the next article in this series, I will take a deeper dive into the basics of Project Managing an Agile project and provide tips to ensure your projects are delivered to the highest degree of success possible.
If you have a topic or question on Agile you would like me to explore, email me at mkalafsky@enterpriseiron.com.
Let the sprinting begin!
