So chances are that, should you follow any kind of formalized project management, it’s likely to be a form of Scrum. And if so, we’ll just betcha that you’ll nod along with this piece:
Why SCRUM Sprints slow you down
Basically SCRUM sprints set you up to commit to something you can’t possibly deliver on. The only way to reach predictable performance in SCRUM sprints is if …
- … your team’s performance doesn’t change ever: No people leaving, no people joining, no knowledge gained over time, no vacations, no motivation highs & lows,
- … the items you are working on are highly predictable: You’ve done them many times, know which problems to expect & how to solve them, no external dependencies, no collaboration with others, no changes in scope even if they would make sense, …
- … nothing else comes up that’s more important: Server down, bug in the payment system, a security vulnerability that needs to be closed ASAP, incredible marketing opportunity if implemented & shipped in the next few hours, …
Considering this it is quite obvious why reaching predictable SCRUM sprint performance is almost impossible in most real world situations no matter how much time and effort you put into sprint planning and estimates.
But the main problem is that SCRUM sprints force your team to optimize for predictability (“how much of what we’ve committed to can we get done”) instead of optimizing for value & agility (last responsible moment)…
Preach it, brother! Yes, we feel all that pain. Particularly that last point. Last time we had an interview ask about our experience as a scrum master in our last management job we scoffed “As if we ever knew what our priorities were going to be by the end of the day, never mind multiple weeks down the road!” These problems are obvious enough to everybody that sprints are usually one week these days, at least they are the last half-dozen places we’ve scrummed at … at which time you’re spending more time in planning and review than the effort is worth, amirite?
Some software companies are starting to embrace continuous delivery and feature pipeline visualization tools inspired by lean manufacturing concepts and Kanban.
This helps them to release improved versions of their software as soon as they are ready. On top of that it enables them to drop arbitrary sprint time-boxes if they want to.
By using Kanban and feature pipelines you pull new work items into your process once space (focus) frees up on the board.
This enables you to defer decisions & commitment to the last responsible moment, a time when usually more information & context is available allowing your team to be more agile compared to SCRUM time-boxes…
Well, this certainly sounds more like a project process that would actually work in the world we live in. Here’s another good discussion:
When to dump Scrum for Kanban
Kanban is useful when requirements and priorities change quickly and often. This becomes evident in teams who can see that their Sprint Planning doesn’t quite hold up for the entire Sprint duration. Kanban helps you react faster, but…
Contrary to popular belief, in Kanban, it’s not only about reacting faster, it’s about being closer to a state of Zen
But how do you get there? Simply prioritize: focus over speed …
Well, that sounds worth a try. Let’s see what tools are out there:
Blossom is from the fellow who wrote that first article up there that got our attention; pricing is $19/month for 5 seats, $59/15, $149/25.
There’s approximately a zillion other Kanban tools, but these two seem widely well regarded for getting your feet wet:
Kanban Tool — pricing is $5/user/month or $9 with time tracking, and a basic 2-user free one too.
LeanKit — pricing is free to 10 users for basic features, $15/20 user/month for more
Us, we’re going to give Kanban Tool a shot, since the price is right and Adding tasks with Siri on iOS devices sounds pretty cool. But as always, if you have any particular recommendations of tools of this type you’ve tried and can recommend, or recommend against, please share!
Why SCRUM Backlogs lead to bad Product Decisions
“… let us count the sins of “Agile” and Scrum …”
Continue Reading →