In Tracker support, I take delight in answering support requests we get from people on teams who are thinking through the way they make software and how Tracker fits into that process. Recently, a customer asked us if Tracker can support their team’s switch from a more Scrum-focused process to a more Kanban-focused process.
Typically when I get such questions, if I can’t answer them myself, I look through our Tracker blog posts or our Community forum to see if I can’t find something salient. In this case, I found very little information. Knowing that Scrum vs. Kanban is a debate happening for many of our users and, indeed, within the Agile community itself, I decided to ask the Tracker Team: what do we think about Kanban and Tracker?
Glen, a Tracker Developer, says:
“If there were a continuum between Kanban at one end and strict Scrum (per-iteration story commitment), I think that within the Tracker team we’re actually about 75% of the way toward the Kanban end. We operate much closer to “pull” than we do to commitment, letting stories ebb and flow through the Backlog, periodically refilling the Backlog with batches from the Icebox as it becomes clear that we’re getting toward the (meaningful) bottom of the current work pile. And we let releases migrate to logical times in the workflow, rather than being rigid about either their content or timing.
On the other hand, there remains significant benefit (in our opinion) to estimating stories and computing velocity. The discussions of relative complexity and difficulty that we have when we estimate stories is valuable to the team, and having a cost associated with stories and features is an important factor in whether the Product Owner decides they should be prioritized or not. And having a record of iteration velocity tells us lots of interesting things about how the team is performing—in particular, periods of significant velocity drops indicate a struggling team and signal that we should be looking for a cause and something to fix.
In short, our opinion is that you should do what Tracker does, rather than either ‘real’ Kanban or ‘real’ Scrum.”
The rest of the team agreed pretty quickly with Glen, and it’s worth decomposing his response to see how this applies to working with Tracker.
Understanding pull vs. push is central to understanding Kanban. In her book, Leading Lean Software Development: Results are not the Point, Mary Poppendieck describes a push system as, “managed by ‘pushing’ a predetermined plan to the operating environment and tracking task completion against that plan. You manage a pull system by managing the queues, instead of by scheduling the details of the work…” On the Tracker team, instead of deciding on a large set of stories to be completed for a release, we are constantly prioritizing new stories in our Icebox and Backlog. Because we do this, the most important tasks are always at the top and automatically get “pulled” into Current when an iteration changes.
While XP and Agile brought us out of the dark ages of big-bang releases in favor of smaller, more frequent releases, there are now varying flavors of frequent releases. In XP and Scrum, releases are typically associated with the end of an iteration, but they don’t necessarily have to be. On the Tracker team, we focus on flexibility within an iteration. This is part of the logic behind Tracker’s release markers. The release markers have a date, but that date does not have to coincide with the end of an iteration, neither is the marker tied to a certain set of stories. We have Epics for that. You can read more about both Epics and Releases here.
Having seen my fair share of support tickets where people ask questions about how they should expect their releases to change when using Tracker, I asked Glen to expand on how and why the Tracker Team releases the way it does:
”Tracker’s model for deployment tries to have frequent releases but to put them into the workflow so that they come after the completion of a batch of related stories. Some development processes are rigid about when releases happen (Every two weeks on Friday!!), and either make people work late to make the release timing or have a “train” model where releases are the train leaving on a particular schedule, and features either make it or they don’t, based on the code being merge-able before some fixed pre-release cut-off time that allows for integration/regression/etc.
Scrum tends to be a rigid work-late process, and Kanban is often either continuous deployment or a “train” process (admitting that their deployment wants feature delivery to be chunked, but only at the very end of the process).
The up-side of our process is that you don’t do silly things like make ‘empty’ releases or do a release a day before a big pile of features are done, causing their becoming available to users to be artificially delayed by the fixed release interval. The down-side is that you can get into a loop where some batch of features is always a day or two from being releasable, so the ‘next’ release keeps being pushed back a couple of days every couple of days, and then maybe you forget to release for a couple of weeks (or months). And that’s bad.”
So far, much of what I’ve written about in our process is, as Glen said, pretty close to Kanban. Our team currently diverges from Kanban by using the estimation of story points and relying on the velocity calculated by Tracker which comes out of XP and Scrum rather than relying solely on the amount of time stories take to finish. In Kanban, focus is placed solely on the amount of time it takes to implement and deliver a story. The Kanban metric, Cycle Time is calculated by looking at the time a story spends in a queue instead of estimating it. Jeff Patton explains Cycle time and how it differs from using points and velocity in his post, Kanban Development Oversimplified.
When I asked the team why we estimate points vs. calculating cycle time, their responses revealed that points estimation is one of the areas in Tracker where team discussion and participation is expected. Tracker developer, David Stevenson points out that there is more than time involved in estimating stories, “PMs should have the ability to see what things are at least ‘easy’ ‘medium’ and ‘hard.’ Then they should get immediate feedback when they try to do too many hard things, by realizing that they can’t get done quickly.”
Kanban’s velocity based on time treats all stories the same, which only makes sense if you have a consistent mix of easy, medium, and hard stories, and don’t care when a specific story gets done.”
Our Product Owner, Dan Podsedly, who recently wrote the Tracker blog post, Velocity Matters, also weighs in on using Velocity vs. Cycle time. “There are certainly advantages/benefits to tracking cycle time, and being able to predict how long a given item might take to get from point A to point B in the workflow. Kanban focuses on this because it’s based on assembly line manufacturing, where the important thing is to optimize station queues and reduce costly bottlenecks.
While Kanban is popular these days, modeling software development based on station-to-station car manufacturing can have negative side effects, as it can lead to more silos (stations) and lines of communications. In my opinion, Tracker forces teams to act more like teams, and work together to get stories through a simple workflow and towards acceptance (the finish line). Instead of measure how long stories take to complete, we track rate of output (of business valued features), and use that to predict future pace of output.”
And of course, as already discussed, focusing on complexity, rather than estimating/tracking time, drives the important conversations and allows the PM to make important (prioritization) decisions early on.”
The comments reveal an important, recurring theme within the Tracker team. We don’t get too hung up about labels such as Kanban, Scrum or even Agile. No matter which tool or process your team is using, at the end of the day, it has to be about getting the software out the door given the people you have and the resources at your disposal. At its core, Tracker is about a team of people making software, not the labels they use to describe their process. Since every team has its own context, your mileage may vary although we are obviously happy if Tracker happens to be the tool that helps you the best.
Category: Productivity
