Non-Technical Agile Leads to Waterfall

There is a trend today that I find troubling: non-technical release train engineers, Agile coaches, or others in Agile leadership roles who are non-technical, leading the way for Agile ceremony planning without including technical thought leaders who know the technical side of Agile (which today is CI/CD).

Technical practices are the backbone of Agile. It is the technical practices that make Agile possible. If you don’t center discussions around technical enabling practices, you are wasting your time.

Don’t get me wrong: there are non-technical things about Agile. Things like a Lean Portfolio, retrospective, and backlog grooming. But if you want to improve those processes, you have to include a discussion of the technical enablers that make improvement possible.

A common example is Work In Progress (WIP) limit. I often hear Agile leaders talking about how they need to manage WIP, in order to ensure that teams are focused. Why do they care? What are the metrics that need to improve? Generally it is cycle time.

But you cannot improve cycle time just by reducing WIP. In today’s Agile settings, a cycle time that is stuck at several weeks or more is almost always the result of an inability to integration test frequently. What happens is that teams code and unit test stories, but they can’t really finish the story until they can “put the code into QA”, so they put it aside and work on another story. Finally, they get access to QA, and the whole team dumps their work in there, and they perform an integration test phase—just as in waterfall from 1990. That’s not Agile.

From this, non-technical Agile leaders observe that all the stories got completed at the end, and they erroneously conclude that the team members should not have started working on stories until others were done. But they had no choice! A story is not done until it works, and you can’t tell if it works until you integration test it.

In this example, the non-technical Agile leaders drew the wrong conclusion because they did not understand the impact of the inability to integration test frequently.

Not understanding the technical factors leads to treating Agile planning as merely an exercise in story splitting and juggling things around. Ideas will be discussed such as cross-functional teams and managing dependencies better. But none of that works unless the technical enablers are present. Cross functional teams are not possible unless teams can integration test on demand, and unless they have devised practices for managing dependencies.

But to manage dependencies, one must define how code changes get merged across teams, and how and when those cross-dependent changes get tested together. Dependency management is deeply technical—it is not merely identifying dependencies, but it is deciding how to reconcile the dependencies and validate that changes work together.

Merely moving things around is a-lot like master schedule planning—in other words, waterfall. Splitting stories into smaller pieces is another waterfall technique: it is called tasking. Doing better estimating is yet another waterfall technique. I contend that if one does not include Agile technical enablers in an Agile process discussion, one inevitably ends up doing things that look very much like waterfall.

Ron Jeffries, one of the creators of eXtreme Programming (XP) has said, “Manual testing cannot sustain the two week delivery cycle...Therefore, for a truly successful iterative software project, automated testing is absolutely necessary.”

XP is what launched Agile, before the Scrum certification mill appropriated the Agile movement. XP is deeply technical.

If you try to improve Agile processes without considering the enabling technical practices, you are largely wasting your time!