Non-Technical Agile Leads to Waterfall
Cliff Berg
Co-Founder and Managing Partner, Agile 2 Academy; Executive level Agile and DevOps advisor and consultant; Lead author of Agile 2: The Next Iteration of Agile
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!
Lead R&D engineer | core platform | ERP | testable and reliable software | database expert | tech writer
5 年Agile is bottom-up method, waterfall is top-down. Technical or non-technical, they cannot lead to each other.
Coach | Scrum Master | Program Manager | Tennis Enthusiast | Philosopher
5 年Hmm. As a Scrum Master with little to no technical background, I generally ask the team "why" something like your example is happening, in order to figure out if there are technical problems. If so, then they as a team discuss (with some facilitation by myself) the possible solutions, including the technical aspects, which I turn around and make sure are transparent (and VERY apparent) to those that make decisions higher up the food chain, with the caveat that if the blockers the team discussed aren't fixed, then we'll never really be that Agile. Feels like you just have to be humble (I realize the irony in claiming one is humble)
Agilist - opinions posted are personal and not on behalf of NSW Health
5 年This is the voice of experience. A mini-waterfall is still a waterfall.
Senior Developer@Spark NZ
5 年Stephen Stewart this one is worth reading too.
DDD Solution Architect, Distributed Systems Designer, Eventstormer, Speaker, Facilitator, Drummer
5 年I think Agile has a lot of facets that if you leave out technical pipeline elements, the rest can help some, but soon it sure does feel under powered to not have that pipeline growing more and more efficient on all levels. And then are you really as agile as your business needs? Fun problems.