Non-Technical Agile Leads to Waterfall

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!

Serguei Tarassov

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.

回复
Ken Crocker

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)

回复
Francis Liu

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.

回复
Damon Xu

Senior Developer@Spark NZ

5 年

Stephen Stewart this one is worth reading too.

回复
John C.

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.

回复

要查看或添加评论,请登录

Cliff Berg的更多文章

  • They Know a Collapse Is Coming

    They Know a Collapse Is Coming

    The CIO of Goldman Sachs has said that in the next year, companies at the forefront will begin to use AI agents as if…

    78 条评论
  • Agile – I Told You So

    Agile – I Told You So

    I think it is no longer controversial that the Agile movement is in decline. When I made a post about it a year ago…

    51 条评论
  • The Most Brilliant Programmer I Have Known Couldn't Work at Google

    The Most Brilliant Programmer I Have Known Couldn't Work at Google

    During the late 1980s I worked at a 30-person startup. The company was founded by the two fellows who had been the lead…

    31 条评论
  • The Most Guaranteed Way to Improve the Bottom Line

    The Most Guaranteed Way to Improve the Bottom Line

    Culture eats strategy for breakfast, but it’s leaders who generate the culture – leaders at all levels, not just at the…

    2 条评论
  • Empowerment, Not Self-Organization

    Empowerment, Not Self-Organization

    Have you heard people say something to the effect of, “Self organization is not really entirely self organization”? I…

    11 条评论
  • Join a Community that is About Learning

    Join a Community that is About Learning

    Things like leadership, product development, technical practices in DevOps, and more. Free workshops for learning.

  • Anyone Can Learn DevOps

    Anyone Can Learn DevOps

    Are you looking for ways to expand your skills, to be more effective in your organization? One way is to learn more…

  • Use a Capability-Focused Approach — Not an Agile Framework

    Use a Capability-Focused Approach — Not an Agile Framework

    Article here: https://www.agile2academy.

    3 条评论
  • Why Team Performance Is the Wrong Thing to Focus On

    Why Team Performance Is the Wrong Thing to Focus On

    Many companies today are obsessed with teams. The “old” approach of static departments and hierarchies is out.

    12 条评论
  • Leadership Is the Key Skill Today

    Leadership Is the Key Skill Today

    Join our free “Intro” to our acclaimed course, Constructive Agility? for Leaders. (Formerly Agile 2 Foundations) It…

    5 条评论

社区洞察

其他会员也浏览了