Some PMs wait until end-of-sprint to review and approve stories. This small behavioral pattern has an outsized impact on output for the engineering team.
Software manufacturing is manufacturing. And like any manufacturing process, if WIP (the manufacturing term for “work-in-progress”) builds up, it will constipate the process. Yes, that visual is appropriate.
For example, let’s say you manufacture custom racecars and only a dozen exit your labor-intensive manufacturing process each day. The exit criteria includes a QA review to make sure everything is perfect: no thumbprints in the paint, the engine runs smoothly, the electronics are working. If a car fails e.g. the electronics test, it is set aside and the electronics team comes to fix it.
Do you see the problems with this normal, logical approach to manufacturing QA?
The electronics setup happened midway in the process. After that other components were added, like the dashboard, that are dependent on and covering up the previous work. It will be much more time consuming to fix the electronics now.
The person that did the electronics setup has already moved on to working on the next car. For them to come look at the QA-rejected car, they need to stop their work on the current car in the process. Meanwhile cars before them will pile up, and the manufacturing step after them will go idle.
If someone else troubleshoots the QA problem they will not be familiar with the details of that custom car. It will take them longer to identify the problem and they run a risk of fixing it poorly or introducing another error.
In general, the better solution would be to identify errors close to the relevant step rather than recycling finished product back into the process.
Let’s get back to software. The same issues arise with the common scenario where a PM reviews, accepts and rejects software stories near the end of sprint.
The work may be obfuscated by other work that has been done on top. For example, a second story which adds a feature to the output of the first. Changing the first story will impact the second as well.
That engineer moved on several days ago to working on a new story. The old story is no longer in their biological RAM because they are mentally deep in figuring out the new story. Asking them to revisit and tweak/change the old story code requires them to break flow and lose momentum on their current work, spend time to load context for the previous work, and then re-immerse in the interrupted project. Lots of switching cost.
Reviewing at end of sprint likely means the team is also integrating and deploying at end of sprint, once the stories have been approved. A batch process like this often centralizes the deployment (and invariable troubleshooting!) to a senior engineer, who while senior was not the same person that initially wrote the code.
What is the overall impact of reviewing at end of sprint, instead of inline as work is done?
Reduced output, because engineers have to break flow on their current work when old work is returned into the process
Increased time to fix, because returning work has accumulated dependencies, or is being fixed by a different engineer
Increased risk, because fixes will be done less-than-ideal in order to get the batch out the door
The solution? A simple behavioral change for PMs. Attempt to review stories within two hours, i.e. before starting the next batch of meetings. And have a firm SLA to review everything before end-of-day, so that you can use a late evening to catch up if necessary. No days should begin with a story up for review.
While simple, the decision to review inline versus at the end of the sprint will do wonders to un-constipate your software manufacturing workflow.
I have a couple hundred cycles directly leading (as PM) a development team and a few thousand indirectly leading (as head of product). You use a tool a thousand times and you’ll start to see behind the glossy packaging. In particular, how Scrum and Kanban perform when used outside core engineering. Here are some observations with the hope it reduces your frustration time in finding a process that fits your team.
Does your development team feel like their process is working for them…or against them?
Acid test #1 for process mismatch is to step back and ask, “without process at all, what should this team be doing?” If the without-process doesn’t match the with-process, you have a problem.
Acid test #2 is to ask whether you could triple in scale and still remain confident. If the process is a good fit it will scale linearly. A poor process will have vulnerabilities at one team that become exacerbated and visible when replicated to additional teams.
The two most popular Agile procesess are Scrum and Kanban. Each has inherent strengths and weaknesses. The key is to choose the process appropriate for your team.
(Note, sometimes a team will run both: Scrum for sprints, and Kanban inside of a sprint as a “child” process. That’s different than using Kanban as the primary “parent” process, which is what I describe below. Using Kanban inside of a Scrum sprint is an excellent but lower-level organizing tactic.)
Scrum
Scrum is a cyclic process. You run a cycle of Scrum, called a sprint, usually 1 or 2 or 4 weeks in length. There are a set of activities you do for each cycle, like estimation and a retrospective. You have a budget of development points for each cycle. When a cycle is complete, you plan and launch a new cycle.
Scrum is not a “light” process. The activities you do each cycle — estimation, retrospective, sprint demo — are meetings that consume time across the entire team. My estimate is that Scrum is at least a 20% overhead cost.
The benefit of this weight is a structure that provides visibility and control even under heavy repetition. Each cycle has with a planning stage that includes comparison to previous cycles. Each cycle has a conclusion in which the delivered work is presented and the progress towards a goal can be assessed. The cycle has a natural measurement cadence: a “heartbeat” for monitoring the development process.
Kanban
In contrast, Kanban is a flow process. There is no cycle. In its most basic form, you have three stages: planned, in progress, and complete. The flow is governed by a cap on how much can be in progress at once. The flow runs continously so there is no finish and restart.
Kanban is a very lightweight process, barely a single constraint on top of no process at all. No planning cadence means that prioritization is free to change at any moment. Even work in progress can be backed out and replaced as long as the in-progress constraint is respected. Kanban’s strength is this flexibility to react immediately to changing development needs. In this way, Kanban is more agile (lowercase “a”!) than Scrum.
However because there is no cycle, Kanban also lacks a natural monitoring cadence. There is no block of effort from which the team can assess the work done and compare versus previous blocks. Over time, while it is clear that output is happening, the lack of cadence means that Kanban resists measurement or monitoring. This in turn makes can make it difficult to assess and improve, both for the development team and the teams they work with.
Selecting a Process
Given the above strengths and weaknesses, which process is appropriate for a given team?
The “contract” of Scrum is that the set of work planned for a sprint should not change once the sprint is started. The development team commits to deliver the work as long as the product manager commits not to change their mind during the sprint. If the product manager does change it, the sprint contract is “broken” and the team will attempt to do the new priority but without a committment to deliver. Teams should break sprint only rarely, otherwise there is no point in having a sprint cadence and a sprint commitment to begin with.
Thus, while the monitoring and assessment benefits of Scrum are attractive, they require a team to have enough forward visibility in their prioritization that redoing the priority once inside a cycle is a rare event. For example, if a team can maintain a four-quarter roadmap, planning the next two-week sprint should not be a problem. Conversely, if the team is at the whim of priorities changing day-by-day, a two-week committment will be impossible to maintain.
The most common failure of Scrum is a team being unable to react to changing priorities. The most common failure of Kanban is not knowing if the team is performing well.
Some Recommendations
In practice, what does this mean?
Feature-development engineering teams act on aggregated customer need and long-term vision for the product. Both of these are relatively slow to change, thus prioritization will be visible to a horizon far beyond a short-term sprint cycle. It should be easy to avoid breaking sprint with unnecessary priority changes. Scrum is an excellent choice for feature-development teams which can then reap the benefit of increased assessment and self-improvement.
Sales engineering and professional services teams work either pre-sales to help close deals or post-sales to configure a product. Unless the product has a very long sales cycle, priorities will change as deals escalate in urgency. More importantly, sales engineering teams “take orders” from outside the team and thus are susceptible to frequently breaking sprint if they attempt to run Scrum. Kanban is a safer choice for SalesEng and ProServ teams.
Design teams often operate in two modes: long-term mode when researching UX, and short-term mode when creating UI or “styling up” output from engineering. For UI work, the temptation is to run Scrum in order to sync with the Scrum cycle of an associated engineering team. However in short-term UI mode, designers are reacting to work coming out of engineering. With Scrum they are forced to introduce an additional delay as UI work waits until it is added to the next sprint to start. Thus Kanban is a better choice for reactive Design work.
SRE (systems & reliability engineering) teams, like design teams, often operate in two modes. In short-term mode they are reacting to system stability emergiencies and moving quickly to fix or patch. In long-term mode they are deploying changes that reduce the likelihood of future issues. While the long-term projects might lend themselves to Scrum, the need to react immediately to short-term emergencies means that most SRE teams are happiest using Kanban.
Other business functions, like Marketing, often see Scrum used in engineering and attempt to implement it themselves for development of content and campaigns. However the prioritization horizon for Marketing is usually measured in weeks as opposed to the months on a feature-engineering team. Unless a business team has clear visibility forwards for mulitples of a sprint duration, that team would be better with the lower process overhead and fewer restrictions of Kanban.
Different Tools for Different Needs
Both Scrum and Kanban are good development processes. Both are agile, and Agile.
If you select the right process for your team, that process will improve your team’s ability to develop over not using a process at all. Conversely, choose poorly and the team will struggle against the process and be harmed versus using nothing at all.
