Avoiding Apples-to-Oranges Comparisons for Clients New to Agile

by

Apples-to-Oranges_TE

Agile methodologies have been all the rage for the last few years and they are the new normal for most companies, including corporate IT and other homes of “traditional” development. But, just using Agile terminology and iterative development doesn’t mean that a company has embraced the full impact of the change. Most are still recalibrating their expectations and clinging to Waterfall ways of seeing the world.

On a challenging assignment a few years ago, I was working with a client that was excited about moving from a Waterfall methodology to an Agile methodology. They had an Agile Roadmap. But, they didn’t fully understand the trade-offs and, while I tried, I didn’t do a great job of explaining those trade-offs or managing their expectations in this new world. I’ve thought a great deal about how I would handle that situation again if it came up on a future engagement.

The client said something to the effect of, “At least with Waterfall, we get a firm commitment on what is going to be delivered and when.” There are a number of problems with that assertion, but the biggest was that it set the stage for a related misunderstanding: that the upfront Analysis time (sometimes called “Sprint 0”) of an Agile project is comparable to the Requirements and Design phase of a Waterfall project. That leads me to the picture below:

Waterfall-vs.-Agile_TEThere is a lot of over-simplification in this picture, but the diagonal dashed line represents the misunderstanding. The client wanted a commitment for what would be delivered after development was “complete” and they wanted that commitment before we started writing code. They understood that our Sprint 0 was shorter than the Requirements and Design phase of a Waterfall project, but they had the same expectation of commitment and estimation.

So, let’s break down the issues here:

    1. Apples to Oranges – At the most basic level, the two milestones are completely unrelated. Yes, going from Sprint 0 to Sprint 1 is when development begins, just like when you go from Design to Development in Waterfall. But, Sprints 1 to N are mini, full-lifecycles: they have Requirements, Design, Development, Testing, etc. all baked in. The goal of Sprint 0 isn’t to understand everything: it’s to lay enough of a foundation to get down to writing working code as part of building the solution.

 

    1. Agile Isn’t Magic – Most importantly, there is no magic to Agile that can get you comparable answers in a dramatically shorter period of time. That’s where the solid vertical line comes in; for true apples-to-apples comparisons of when the team would be able to make reasonable commitments, we should have insisted on waiting until a few sprints were complete (in the illustration, that point is after Sprint 2). If the client were willing to wait until the longer Requirements and Design phase of comparable Waterfall projects, why shouldn’t they wait for the same amount of time in an Agile project?

 

    1. It’s Safe to Write Code Early – But wait, how can the team start writing code before commitments are made? Because writing code (and potentially rolling it back) is much easier now than it was in the past. We have better source code control, regression testing, and other tools that take away any risk of the effort related to unwinding changes.

 

    1. It’s Really Powerful to Write Code Early – We learn much, much more about requirements and what works / doesn’t work by writing code than by writing Word documents. So, think of Sprint 0, 1, and 2 as an extremely practical and powerful analysis period. Which, oh by the way, if things go even reasonably well, produces working code. Compare that to the zero code produced in the comparable Waterfall timeline for the same duration.

 

  1. More Analysis Doesn’t Prevent Scope Issues – Even with all of the analysis (and even with writing working code), new requirements and revisions to existing requirements always emerge. In this case, we were making enhancements to an existing system and the client had done their own analysis of the problem, so they were absolutely convinced that they knew exactly what they wanted and that it was a discreet set of functionality. But, that didn’t stop the team from discovering related functionality that became critical. Here’s the real kicker though: Waterfall would not have fixed that problem. In fact, it would have probably delayed the discovery of the related functionality.

Waterfall doesn’t really add certainty, it just makes people feel better that it has. Agile methodologies embrace uncertainty, are more honest about it, and reduce that uncertainty faster by building stuff sooner.

 

READ MORE

Shifting Perspectives: 3 Learnings From a 3-Day Training

Shifting Perspectives: 3 Learnings From a 3-Day Training

About a week ago, I completed the second live (virtual) training in the process of becoming a Certified Professional Coach through iPEC. Once again, my mind was blown! It reinforced for me that virtual workshops can, and do, work, and, in a lot of ways, I prefer them...

read more
Finding My Work-Life Balance

Finding My Work-Life Balance

In my previous post, I told the story of how I got back into consulting after becoming a mom. All of the diverse experiences I had during that journey have helped me to find my work-life balance by… Defining Boundaries “Go home,” my first boss said 12 years back —...

read more
How I Got Back to Work After Being a Full-Time Mom

How I Got Back to Work After Being a Full-Time Mom

I Landed My Dream Job Throwback to 2014, I had completed my MBA, landed my dream job as a consultant, and was hoping that my new consulting career would exponentially ramp up my career growth for the next 5 years. This would position me to take on critical decision...

read more
Self-Awareness is Key to Belonging

Self-Awareness is Key to Belonging

In August of this year, as part of our annual company meeting, our team at Thought Ensemble participated in the foundational session of Diversity, Equity, and Inclusion (DEI) training led by Dr. Nika White, IOM, CDE (she/her/hers). One of the most meaningful moments...

read more
Finding Your Organization’s Magic Pixie Dust

Finding Your Organization’s Magic Pixie Dust

It is often said that organizational culture is like a fog — it is all around us; it impacts our ability to see, to move quickly, and to deliver; but we cannot quite put our finger on it. Indeed, some organizations see their culture as a byproduct of operations,...

read more
We’ve Refreshed Our Brand!

We’ve Refreshed Our Brand!

Why have we refreshed our brand, you ask? Well, as we have grown and matured as an organization, we felt that our previous brand elements no longer represented us as well as they could. You see, we founded Thought Ensemble back in 2008 to help companies better compete...

read more
Thought Ensemble’s Purpose — Inspired in 2020

Thought Ensemble’s Purpose — Inspired in 2020

I recently wrote about how company purpose is being tested and inspired by all the events of 2020. This topic is very real for us at Thought Ensemble. We’ve been thinking a lot about what really matters as we’ve navigated the...

read more
How 2020 Is Testing and Inspiring Corporate Purpose

How 2020 Is Testing and Inspiring Corporate Purpose

In August 2019, the Business Roundtable rewrote their statement of corporate purpose. I followed this with significant interest being that I have never forgotten the debates about corporate purpose in business school almost two decades ago. We were taught that the...

read more
Why Purpose-Driven Organizations May Struggle With Change

Why Purpose-Driven Organizations May Struggle With Change

I love working with companies who really want to make a difference, beyond just making money for their shareholders. I mean, making money is fun and all, but it is even more rewarding to join in on a just cause. Plus, as this HBR article explains, companies who have...

read more