Department-Level Kanban for Engineers

In the commercial software engineering environment, collaboration is important. Despite all the attention given to technical decisions like framework or language choices, it’s often the way — either collaborative or not — that a team makes technical choices that has the biggest influences on the success or failure of a project.

The ubiquity of the agile movement in software over the last decade has given many businesses and teams a good framework for establishing intra-team collaboration. However, if we embrace that intra-team collaboration provides value, then how do we handle inter-team (team to team) collaboration? Is the principled foundation of team-level agile strong enough to support collaboration practices at a larger scope? Within the Shopper group (department) at Ibotta, the platform engineers are attempting to find out.

David Anderson’s Kanban: Successful Evolutionary Change for your Technology Business presents a succinct and approachable perspective of the principles that underpin Kanban, and the ideas that were ultimately the basis for this experiment.

Visualize Workflow

One of the refreshing aspects of Kanban is the simplicity with which it can be approached. The first principle of Kanban, visualize workflow, is extremely straight forward but is also worth taking the time to consider in depth.

The concept behind this principle is that work is being done for the purpose of delivering value. More than one step is needed in order to deliver that value. These steps are likely taken, or at least can be taken, by different individuals. If all of the steps were collectively understood from start to finish, this process of steps to deliver value could be called a “value stream.”

While the idea of visualizing a value stream is easy, having to visualize your workflow reveals that in order to do so you must have a deep understanding of what your own workflow is. Spending most of your time immersed in your own workflow it can be easy to assume you understand it, even if you haven’t taken time to thoughtfully consider it.

We accept the reality of the world with which we’re presented.
— Christof (Ed Haris, Truman Show)

For software engineers, this is likely a familiar story. The value stream may begin with an idea or product feature; which is then discussed; it’s implemented; it likely undergoes some kind of peer review somewhere in this process; then it’s queued up for deployment; delivered to customers; and finally evaluated for effectiveness.

The Value Stream

When coming to “visualize workflow”, starting with a deep understanding of the value stream is a prerequisite. Once that has been obtained, making it visual so that all of the team can see it is the end result of the principle.

While the value stream described above is a familiar path for most engineers working now days, this same principle can be applied anywhere a value stream exists. For example, an HR department may have a process to handle incoming applicants that involves various stages of contact, interviews, evaluations, then steps of on-boarding once hired. Here too is a value stream that can be understood and visualized.

Units of Work

On the Shopper group, our question was, can this principle of understanding and visualizing a value stream be applied to a larger group of people or an entire department? At Ibotta, we started by understanding the way that we think about work.

Domain teams might focus on individual units of work, Tasks or Stories in SCRUM parlance. These stories or features are often grouped into a theme or a milestone, again borrowing from SCRUM, called an epic. Epics are collected into initiatives, large strategic objectives that may be defined quarterly.

Epic-level Value Stream

What is the process for an entire team to deliver an epic? There’s a value stream there, and if it can be understood, then it can be visualized.

Each organization likely has a slightly different approach to how teams move through engineering themes, but there are some similarities. While each team within Shopper is unique, there were common pieces we identified: There is likely some phase of ideation and requirement gathering; engineering effort may start, but in an exploratory fashion; A/B tests may be run from early engineering efforts. At some point a shared understanding of what that theme or feature needs to be successful will be reached and shared by the team, in which the team often turns a corner and focuses on completing the work based on previous learnings. The epic may end with a final analysis or evaluation of the work completed.

Those steps are all part of the epic value stream and just like delivering a single task or story, can be modeled on a Kanban board and visualized to a large group of people.

On the Shopper group we sketched out a first pass at what that value stream may look like:

• Tech Design
• Plan
• Early Engineering
• Late Engineering
• Analysis

The split between early engineering and late engineering is attempting to capture the exploratory nature of engineering for new features. “Early Engineering” is largely about shipping enough work to really understand the requirements and what satisfies the customer. This phase could be thought of as exploratory engineering. Actual features may make it into customer’s hands, but the team’s overall sense of what needs to be done to satisfy a need is still being evaluated.

“Late Engineering” captures that point at which a team has done enough work to understand what it is they need to do. Teams often get to a point where, after having built and shipped some amount of code they reach an understanding of what actually needs to be done. At that point a clearer plan and vision for remaining work can be laid down.

A slight limitation that is introduced by trying to visualize this value stream is that it makes it appear linear when in reality there may be a little bit of design and planning, followed by a small amount of engineering. Based on learning from that early engineering there may be a little more design, and so on. It could be argued this linear nature of the board pushes teams to be more waterfall in their approach. On Shopper however we attempt to use the board only to reasonably understand how far we’ve progressed with an epic, with the understanding that any of the previous activities can be re-visited and refined as a team develops a feature.

In the spirit of agile, the modeled value stream above was just a starting point. As a group we will continue to refine and match our visualization to our value stream. There have already been some efforts to capture the broader software development lifecycle (SDLC) and those understandings will further inform the cross-team visualization.

Visualization alone will, perhaps surprisingly, provide a lot of benefit by itself:

• The act of discovering the value stream in order to visualize it will have likely stimulated good conversation amongst the team and revealed opportunities for improvement
• Regularly looking at the progress of the value stream and how epics are moving through it will create both transparency amongst the team and an accountability to it
• A common knowledge of what other teams within one’s own department are working on is a good stimulus for conversation and knowledge sharing

All of these benefits have been observed by the Shopper platform group during this experiment. However, as we look towards the future, and further improvement, additional principles of Kanban, like limiting work in progress, have the potential to add further value.

If this kind of collaboration and experimentation sounds interesting to you, Ibotta is hiring! Check out our jobs page for more information.