📬 The Backlog #199
An easily-digestable perspective on cross-functional work, a suggestion on where you might stick your backlog, and a beautiful argument for agile coaches to mind delivery speed.
-
In my last weeks at my current gig, I’m helping colleagues kickstart a new product team. For most of the software engineers in that group, it’s the first time they’re part of a cross-functional team. My intent is to show example behaviour, nudging them to ask questions of each other.
That’s important, because in previous teams they’d just hand off work items to testers when they felt confident enough about the code they’d written, and pick up something else. Their new team doesn’t have a member with a QA or testing background, leading to some disquiet. “How’re things going to get tested?!”
This is an occasion for me to use examples like cooks not needing a third party to prevent them from burning their food, and a little further down the line, stuff like Michael Lloyd’s article about how Testing is not an end of Sprint activity.
Lloydd writes about testers and software engineers working collaboratively. And while my colleagues can’t do that in their current setup, I think the article still sheds a light on their previous and new ways of working.
The principles of the article are solid regardless of your discipline: “When you’re no longer raising tickets mid-sprint, but solving issues as they arise, you need to foster collaboration and communication.”
People like my colleagues, who were used to “throwing coded work over the fence to testers,” in Lloyd’s words, “probably aren’t going to jump straight into a high-trust, collaborative way of working. But there are some things you can do to get there.”
The article is punchy and brief enough for you to confidently share it with, and expect it to be read by, even the staunchest siloist on your team. -
To all of us working on the same product for a while: Allan Kelly suggests we Nuke the backlog (by which he means the thing, not this newsletter). His article is a companion piece to his recent talk at Agile on the Beach.
Kelly argues that Product Backlogs “work in the small, for the team, for the coming week or the next few sprints but they don’t scale.” According to him, that is because they often accrue more items than make it to a release, and in doing so, they distract from the conversations that we should be having: about “the world you want to create, not the pieces”.
Kelly’s argument for wiping backlogs is related to the maturity of agile practices (or perhaps better, their rigidity trap) and his approach is informed by outcome-based product thought.
I find it a nice companion to Mary Poppendieck’s piece about backlog removal, in which she argues for replacing it with relentlessly fast delivery practices in software development.
See also, issue 111 of The Backlog. -
And speaking of fast delivery: Michael Küsters signals a false dichotomy between being agile and being fast, in his article Why Agile Coaches need to care about Delivery Speed.
Essentially, Küsters argues that no-one should have to care about being agile as a goal, it only makes sense as a means to an end - and that end is often related to fast(er) discovery.
Using a clear argumentative structure and some biting captions, Küsters aims his article at agile coaches who target mindset without considering delivery acceleration.
More precisely, he makes short work of those who say you don’t need the latter by emphasising how both are crucial.
“The Agile Coach who neglects Sustained Delivery Speed and its incorporating technical practices, such as Continuous Delivery, is much more likely to struggle in demonstrating significant long-term outcomes. They may miss critical gaps in quality practices, feedback mechanisms, collaboration, and adaptability, thus leading to predictable challenges in meeting stakeholder expectations, driving improvements, and effective agility.”
Have a week filled with constructive criticism, and Scrum on,
Thomas van Zuijlen