From Push to Pull
Tips to foster goal-reaching and flexibility
A couple of retrospectives ago, the team floated the idea of switching to Kanban. We struggled with reaching our goals while handling ad-hoc requests from business. Priorities often changed, and it seemed sprints didn’t make sense. The seemingly more continuous Kanban flow sounded more like our reality.
In the past, I was too eager to replace Scrum with Kanban, which resulted in a superficial implementation. This time, I stopped to think. I suspected that switching to Kanban — to the extent that we understood it — would improve the optics, but not address the underlying causes. It would be a sizable change that would require a disproportionate amount of time to explain to all parties involved. Was it worth the effort? Could there be other, mostly optical tweaks that would do the trick at a lower cost?
Over a couple of months, we experimented to find out. Here’s what worked. Even though these tips are based on a case of one project team, they sum up all I’ve learned in my work with software teams so far.
Visualize work as a whole.
In the remote environment, we use a digital board during our daily syncs. Doing so in Slack, where you can draw on the shared screen, is especially handy. Our board had swimlanes for assignees, and it structured the way our daily syncs went. It made it easy for the speaker to report on their progress, but it narrowed down the group focus and made it harder to see the bigger picture.
We got rid of swimlanes. Our entire work pipeline became visible at one glance. It showed more clearly where the bottlenecks were and how work items depended on each other. It also opened the doors to a different way of running the daily sync.
Tip: Get rid of swimlanes for individual team members. Let your default board view show all your work.
Swimlanes work best to separate different streams of work, but not different people working on the same stream. If you need to highlight someone’s work items, use a custom filter instead.
Right-left, bottom-up.
Our daily syncs focused on individual progress. One by one, people would tell what they did and what they planned to do next. It was the vocal extension of the swimlane approach. After we removed them and saw our work as a whole, we started to inspect its individual parts.
We dropped the one-by-one reporting and traded it for inspecting tasks, going from the stages of work closest to completion — from right to left — and from the oldest tasks in individual stages — from bottom — up. It helped to keep the attention where it needed to be and made the meeting more dynamic.
Tip: Don’t make your daily syncs about individual storytelling and reporting. Use them to inspect the work in your pipeline, starting from the items closest to getting done. What’s stopping you from moving them there?
Identify the bottleneck and limit Work in Progress (WIP) there.
The Toyota Way & Lean teach us that any improvements outside the bottleneck are a form of waste. Do you know where your bottleneck is? In our case, the place where we lost the most was clearly the Code Review stage. Not only were tickets accumulating there more than anywhere else, people often had to repeat their request for code review from day to day. Not a good sign.
We imposed a limit there (number of team members -1) and started to inspect the status of open Pull Requests (PRs) more regularly, making it a key point of our daily sync. Going over the WIP limit triggered a strong visual signal on the board and redirected our attention there. Steadily, time-to-review dropped, people got feedback from testers faster, and cycle times became shorter.
You might already know or suspect where your work piles up. You might need to dig a bit into the data to clarify what the bottlenecks are, but your gut feeling is probably right. Besides, when you see your entire work as a whole, it’s easier to spot where it’s stuck.
Tip: Find your bottleneck and impose a Work-In-Progress limit on it. The goal is to focus the effort on a smaller number of tasks and finish them faster. When the batches of work are smaller, defects are detected earlier and the cost of fixing them is minimized.
Limit the scope of iterations based on the number of items worked on, not the story points.
We estimated work using story points in the Fibonacci sequence and re-estimated it at the end of sprints. We then looked at our average velocity in story points to gauge how much we could take into the new sprint backlog. It worked, but felt pointless.
As Vasco Duarte showed in his book NoEstimates: How To Measure Project Progress Without Estimating, the numbers of story points and work items delivered tend to equalize long-term. I ran the analysis in our project and the similarity was uncanny. It showed that on average, we delivered as many work items per sprint as the story points we burnt. The difference was below 1. If all we needed story points for was to assess how much work we could fit in two weeks, and we could do this by simply counting, why bother with story points at all?
We switched to referring to the number of work items for the sake of forecasting and planning the scopes of iterations.
This enabled us to simplify our estimation system and spend less time doing this, eventually dropping it altogether.
Tip: Forget about story points. Or at least take them less seriously. Focus on the number of work items in the pipeline. If your work items are too diverse in their size, break them down until they aren’t.
Time value is absolute. It makes no excuses and accounts for everything that happens between TO DO and DONE. Throughput is a much better indicator for forecasting and estimating delivery than velocity in story points. Take it out of the equation and don’t burden your mind with this useless variable.
Limit the iteration scope, so that it is below the average.
Having switched to referring to the number of work items as our benchmark, we thought about a way to handle these unexpected-yet-expected requests from business. We started setting the limit of tasks per iteration below the average to make space for the unknown, whose volume was to some extent predictable based on the past. We also created an Expedite swimlane for these ad-hoc requests.
Doing this actually resulted in increasing throughput significantly and exceeding the old average of story points/work items delivered from sprint to sprint.
When you get things done sooner than planned, you end up delivering more. That’s something that I see notoriously underplayed while planning and assessing scopes of iterations, especially at the start of projects. Product Owners dump too much on teams who fail to push back. Two weeks of crunch mode later, we end up with a lot of things started, but few having completed the entire workflow and truly done.
Alternatively, when you narrow down the focus to only a couple of items — even though it might not reflect the desired roadmap burn down — you increase the chance of finishing them before the time-box ends. With nothing left on the TO-DO of the current sprint, you can start pulling work from the next one or address urgent issues reported along the way.
Tip: By setting smaller, more achievable goals, you increase the chance of reaching them earlier. If you get things done before the deadline, you have time and energy left to be proactive and get ahead of new work to come. Plan for less, deliver more.
Refine regularly in small bites.
Our backlog was getting out of control and our refinement slot was not enough to keep up. The more work piled up, the harder it became to do the refinement right. To counteract this, we increased the frequency of the sessions and broke them down into smaller bites.
In a couple of iterations, we cleaned up the backlog and reached the rhythm where we could maintain a constant pull of new work through the refinement stages into the ongoing and future sprints. It also allowed us to use our refinement slot to invite colleagues from Business to discuss new features ahead of time, which sped up discovery and delivery further.
Tip: Refine work regularly, preferably on a weekly basis. Let it set the rhythm for your delivery rate and serve as a health check of new work coming into the pipeline. Have a clear way of scheduling and communicating topics to be refined, so that people whose input is needed are able to prepare for the activity. In our case, a placeholder sprint section in Jira with items scheduled for the week did the trick.
Enjoy the spoils and optimize further
All of these tweaks led to a bit more time on our hands. We got back on track with our roadmap, started delivering goals ahead of schedule, and had a stable flow that enabled us to pull in work from the backlog rather than react to what was pushed into it. The dynamics between Business and Development changed as the team started to run out of new features to implement. We gained the flexibility to tackle new topics with a hard deadline overnight without endangering the ongoing goals.
Tip: Use the extra time and energy to your advantage. It might mean more workflow tweaking, reinforcing the changes underway, learning and developing, team building, or addressing technical debt. The choice is yours. Once things are clicking, beautiful things start to happen.
