5-Minute DevOps: The Three Wrongs

The never-ending methodology debates are exhausting. “Agile or Waterfall? “Are we doing Scrum correctly?” “Should we use Kanban instead of Scrum?” “What about an agile scaling framework?” “When will this “agile” fad blow over?”

I see these questions constantly followed by answers from “Agile experts” who will happily quote the Agile Manifesto, tell you it’s a mindset, and explain in excruciating detail how you aren’t using their favorite methodology correctly. Let’s be clear, “doing Agile correctly” is never the problem we want to solve. The problem to solve is something I’ve decided to call The Three Wrongs.

1. The idea is wrong.
2. We’ll misunderstand during development.
3. The users’ needs change before we deliver.

No matter how hard we try, one or more of these is true. Let's look at each of these, understand why they happen, and how to mitigate them.

First Wrong: The Idea

We believe we’ve identified a gap in the marketplace or our internal business operations. We have a fantastic idea for how to fulfill that need. So, we begin defining the features and user stories. Once we are happy that everything is defined correctly in the backlog, all that’s left is to estimate the work in story points, start development, and track the burndown chart to ensure we deliver on our commitments.

We’ve already failed. We have invested a lot of time and energy into a large batch of work, and we have all agreed it’s going to be awesome. One of the biggest hurdles to delivering something valuable is assuming the idea is valuable. Instead, we should treat the idea as a value hypothesis.

“We believe that if we deliver X, we will see measurable improvement Y.”

The point of the “agile” thing isn’t two-week sprints to process a backlog more quickly. The point is, “How can we find out as quickly as possible that there is a problem?” Our goal is faster feedback on the value of the last thing we delivered so we can improve our ideas. When we fail, we want to fail small and find out quickly. Instead of spending time polishing our ideas and congratulating ourselves on how awesome they are, we should focus our energies on improving the efficiency of our delivery process to make it inexpensive to run small experiments. A costly, slow development process will drive up bach size and put us at risk of building and supporting something no one wants.

Second Wrong: Misunderstood During Development

“What the heck does this acceptance criteria mean?”

A common development anti-pattern is where developers are given user stories with acceptance criteria. They then provide story point estimates and start working. However, when those acceptance criteria were written, the author made unconscious assumptions. When the handoff to developers occurs, there is a loss of context. The result? Misunderstandings. In the best case, a developer will identify a gap and ask questions. However, the more common outcome is that the developer will assume they understand what is meant and will develop based on that understanding. Besides, they may not make the date if they wait for answers!

The obvious solution is to have a QA team responsible for writing tests to ensure the requirements are implemented correctly. Besides, developers don’t know how to write tests.

That’s wrong on so many levels. First, developers are responsible for delivering working solutions, not code. That means they test them. Second,

“It’s interesting to note that having automated tests primarily created and maintained either by QA or an outsourced party is not correlated with IT performance. ”

Accelerate — Nicole Forsgren PhD, Jez Humble & Gene Kim

Why is that? Besides the fact that developers creating acceptance tests results in more testable code and developers who are more invested in maintaining a good test suite, there’s also the loss of context problem.

Testing teams are not magically better at avoiding misunderstandings than development teams. If we add a testing team into the flow, the odds of requiring rework climb dramatically. It gets worse with every team we add to the flow.

The result is test failures that require meetings to discuss which set of code is the source of truth, only to find out that it’s neither. This causes delays that drive up batch size and delay feedback.

Hopefully, the idea wasn’t wrong…

Fixing this means removing the handoffs between teams and creating a truly cross-functional product team.

• Define the feature and acceptance criteria as a team so we can cross-check for assumptions and misunderstandings.
• Define how we will test them as a team.
• Define how we will measure success for our value hypothesis
• Deliver the smallest change we can think of to validate that.
• Then, we use that feedback to make the requirements less wrong.

Even if you have a fully functional product team, avoid creating a large backlog of work ready for development. Refined user stories age like milk, not wine. The more time between when we say something is ready to start and when we start developing it, the more we lose information fidelity.

“What did we mean when we wrote this?!”

Third Wrong: The Users Changed Their Minds

How often does this happen? Very frequently. Usually, because what the users ask for isn’t what they thought they needed. They only realize after they see it that “what I really need is…” or “it would be so much more useful if…” or worse, “I don’t need that anymore because…”

I will leave that truth table to your imagination.

The more we deliver at one time, the more likely this is true and the more expensive and time-consuming it is to fix. The idea of “we’ll deliver this and be done” is simply a fantasy, and any plan based on that assumption fails before it begins.

The Three Ways

The antidote to The Three Wrongs is The Three Ways

1. Systems thinking
2. Amplify feedback
3. Continuous improvement

We need to look at our entire delivery system to improve everything about how we work to enable us to ship smaller batches to get faster feedback. We need to continuously improve how we work so we can continuously improve the value of the work.

How? Solve the problem of “Why can’t we deliver today’s work today?” Break things down small and ship it!