Does Continuous Improvement and Delivery Make You Agile?

I try not to get involved in arguments — but when a debate started in the Dev Interrupted Discord about if exceptional continuous improvement (CI) or continuous delivery CD) makes a group agile or not, I had to jump in. I’ve helped build many high-performing teams with agility, and I know that neither CI/CD nor Scrum makes an organization Agile.

It’s Not What You Do, It’s How You Respond

Probably my favorite way I’ve ever heard someone describe agility was that it’s about moving away from believing we can predict and plan everything to sensing reality and responding to it instead.

Consider two extremes. In the “predict and plan” view of the world, we build a feature list, come up with screens, represent that in a backlog, and dutifully execute in two-week chunks. This approach focuses on accurate plans and predictions in the early stages. Mistakes in the early stage compound rapidly later on.

Are these folks agile? What did they sense and respond to?

A different group has a sense of problems to solve and their relative importance to one another. This group decides the goal for their next investment in a sprint. Every day they look at what happened and determine if they need to change course. They frequently shift direction mid-sprint because they’ve learned something new. Are they agile? What are they sensing and responding to?

Both teams are following Scrum’s rules, but one has lost all its ability to respond to new information, and the other, while it seems chaotic, is using near real-time data to guide their next steps.

Regardless of how you do it, agility is a lot more like the second group than the first. You can tell this not by the meetings they have or titles like Scrum Master, but rather by the frequency with which they make decisions that significantly change their direction.

You Have To Have Working Feedback Loops

A way to detect weakness in a group’s pursuit of agility is to examine the strength and length of their feedback loops.

Scrum is a framework, which is a weird way of expressing that it has a few useful pieces and room to figure feedback loops for yourself. The parts it does have, though, are a series of events and structures that provide feedback loops.

A feedback loop is an activity where you can pause to look at the results at the end. A chef that tastes their own food as they prepare it creates a feedback loop. A chef that never tastes their own food or waits until the dish is finished to take a taste, does not.

If you think about the events of Scrum in terms of feedback loops, every activity has a counterpart that closes the feedback loop. Sprints have Retrospectives, Increments have Reviews, and each day has a Daily Scrum.

All too often a Sprint Review is nothing more than a team saying they did a bunch of stuff with no actual feedback happening. The same can be said of Retrospectives, where the team produces many stickies, but no change manifests. The Daily Scrum Is a daily feedback mechanism, but all too often reduced to merely a task status update.

Scrum puts the potential to leverage these feedback loops in place, but they don’t work by themselves. So you can easily wind up with a team building a two year roadmap, executing on that roadmap, but never recognizing the signals that there is actually no market for what is being built.

Sponsored Section

One way to ensure quick feedback loops internally? Cutting the review time for code in your development process. WorkerB developer automation tools by LinearB can give your team proactive notifications of changes in their PRs and update developers on long PR review times while correlating the PR to the relevant project issue.

Just turning on WorkerB with LinearB helped Illuminate Education decrease their cycle time by 44%! Learn more about how WorkerB can increase organizational efficiency.

The Rut of Following Form

I often see groups espousing that they are agile because of some activity they do or capability they have. In fact, that very behavior is what inspired me to write this article.

It can be tempting to look at agility as a feature list or series of checkboxes that, if you complete enough, you’ll summit the mythical agile mountain. But if those things aren’t so important, are the rules important at all?

Well, they are, but it’s just not enough.

Organizations and teams put a lot of emphasis on getting the basic structure of Scrum in place but tend to get into the rut of standing pat with those structures, and so the promise of agility remains elusive. These groups similarly work hard to cut things that they’ve been told are not agile anymore. Basically, they focus too much on the form, and not enough on the function.

You have my permission and support to keep using work-breakdown schedules as you pursue agility.

On the one hand, you need the form to be correct, or you can’t get the benefit. On the other, if you only follow the form, you stand in place.

So with my teams, I look to see if our process is “alive.” With a clear purpose for each activity, I can quickly see which of them are exhibiting signs of weakness that will disrupt feedback. Then I can intervene and bring the form back to accomplish its purpose.

For example, in a talk I give about Daily Scrums, I say, “The purpose of the daily scrum is to begin the day’s collaboration and coordination towards a sprint goal.” Most daily scrum meetings miss the mark of that purpose.

Looking at things from this angle, we can mature our forms and get the benefit back.

Change Takes Time

There is a fascinating intersection between these concepts where we recognize we want to address weaknesses in how we practice agility, but have difficulty estimating how to move forward and how long these changes will take.

One aspect to this is that we do need those forms to be in place before we can sense and respond to it. In my experience, a change in these forms takes about three months to normalize in a group.

When I introduce more advanced concepts like Test-Driven Development or Work-in-Progress Limits, I introduce those forms and also hold them in place for three months. This time frame might feel slow, but it comes down to how we as people handle change.

What we’ve done in our past is what frames what makes sense to us today. Our brains crave that feeling that the world works a specific way. When we disrupt that, people’s instincts are to reject the change. Even if it is a rational and logical change, we’ve disrupted what is normal. The three month adjustment period seems to be enough to allow change to take hold and for a new normal to be realized.

During that whole time, though, the form has to be sustained.

So as much as adherence to form can be a trap, it also is the scaffolding for change.

Learn to be Comfortable with Change

My honest advice for leaders who want to make things a bit better is to get really comfortable with microscopic change for a while.

An example might be phrasing a question differently — a small change.

Take an honest look at how you view things working best along a spectrum of plan and predict and sense and respond. Make sure to compare how you think you do to the actions that actually take place. There is usually a disconnect there.

Next, look at an opportunity within the existing forms to strengthen a feedback loop. Using something as simple as phrasing a question differently — a small thing — can completely alter the course of a Review or Retrospective or Daily Scrum. A thoughtful question that encourages feedback can easily improve things..

From here, you can continue this pattern of making small adjustments to how you and others move towards sensing and responding and leveraging the forms of Scrum to become truly agile.
.
.
.

For more thoughtful discussions on engineering and leadership topics, consider joining the Dev Interrupted Discord Community. With over 1600 members, it’s the best place for Engineering Leaders to engage in daily conversation. No salespeople allowed. Join the community >>

If you haven’t already heard, Dev Interrupted is hosting INTERACT, our biggest event yet. The interactive, community-driven, digital conference takes place September 30th. Designed by engineering leaders, for engineering leaders INTERACT will feature 10 speakers, 100s of engineers and engineering leaders, and is totally free.

Originally published at https://devinterrupted.com on September 1, 2021.