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

by | May 28, 2015

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

The Magic of Mortals

The Magic of Mortals

Daily we wake up to new developments in automation, Artificial Intelligence (AI), and Machine Learning (ML). Across sectors and industries, automated solutions prove highly successful in surpassing the capacity of the human brain for certain tasks, improving...

read more
Leveling Up: How to Hone Your Skills at Home

Leveling Up: How to Hone Your Skills at Home

Leaders have been trying to crack the code on talent development for years. Recent studies have shown, however, that strength-focused leadership [read: intentionally elevating the qualities that already come naturally to us] is the clear winner for developing talent...

read more
Fake Case Study: Jack of all trades vs. Master of One

Fake Case Study: Jack of all trades vs. Master of One

  Listen to any earnings call or executive presentation and you will likely hear the terms “top line” and “bottom line.” These are words used to describe a business’s performance. According to Investopedia, the words are defined as follows: Top line refers to the...

read more
Your Personality Is Showing

Your Personality Is Showing

There I was, minding my own business one evening, digging into my organization's SEO performance (as one does), when I came across something interesting. Search terms related to "MBTI" — or the Myers-Briggs Type Indicator, developed by Katherine Cook Briggs and Isabel...

read more
Lessons From a Change Manager Who Hates Change

Lessons From a Change Manager Who Hates Change

Hello. My name is Monique, and I’m a change manager who hates change.   After years of receiving “consulting therapy” from various mentors, I am now able to say these words out loud and proudly. But for a long time, it felt more like an admission of guilt. I mean, who...

read more
Creativity as a Cure

Creativity as a Cure

The topic of creative solutioning has been front and center these days as we talk more and more about organizational adaptability in the face of dynamic and uncertain times. For example, I recently read about a project that got me thinking about specific priorities...

read more
Thought Ensemble, a Pariveda Company — Why Now?

Thought Ensemble, a Pariveda Company — Why Now?

Big news over here as we close out the year - we have been acquired by Pariveda, a 750-person consulting firm in 12 markets across North America! We are now “Thought Ensemble, a Pariveda Company” and I’ll be serving as the Managing Vice President continuing to lead...

read more
Thought Ensemble Joins Pariveda Solutions!

Thought Ensemble Joins Pariveda Solutions!

Dallas, December 9, 2021 /PRNewswire/ -- Pariveda, a leader specializing in solving complex technology and business problems, announces the acquisition of Thought Ensemble. With the addition of Thought Ensemble, Pariveda now provides holistic business strategy,...

read more
Thoughts on Colorado’s Equal Pay for Equal Work Act

Thoughts on Colorado’s Equal Pay for Equal Work Act

It was about a year ago that we first started hearing about Colorado’s Equal Pay for Equal Work Act (SB19-085) and I knew it was going to be national news. We’d just gotten past the “Rocky Mountain High” jokes, and our lovely state was trying to break new ground...

read more