Kanban

A Brief Introduction to Kanban

30 December 2019 By Peter Herr

Kanban is an Agile method that, like Scrum, can be applied to technology work (and already is applied to many other areas as well, like manufacturing). However, unlike Scrum which is a more prescriptive approach to your process, Kanban is an empirical approach that offers principles and guidelines to be applied based on your environment and specific situation (you do more ‘learning as you are doing’).

Where Kanban Comes From

Kanban originated in the mid 20th century in Japan, when Toyota began optimizing its engineering processes based on the same model that supermarkets were using to stock their shelves (read more in The Toyota Way). Toyota innovated with Just In Time (JIT) manufacturing process, the Toyota Production System, Kaizen, and Kanban. Over time this was brought to the West and evolved into Lean, Six Sigma, and eventually, Kanban was taken and adapted for technology companies.

Kanban literally means signboard or billboard in Japanese. A Kanban board of what you’re doing right now looks like this:

Or if you use software like Trello or JIRA for your team, maybe like this.

Unlike Scrum’s sprint-based approach, Kanban is about continuous flow through the system. A simple flow could be three steps, like above, or more complex as necessary depending on what makes sense for the team and context.

The goal of the team is to optimize the flow of work through the system to best support the goals of the business (i.e., be profitable).

What are the Benefits of Kanban?

Increase measurable efficiency and productivity (increased throughput)
Respond faster and more directly meet business demands
Executing at a sustainable pace (reduce overburdening)
Better team morale
Better quality code; reduce bugs and tech debt (better quality)
Create a culture of continuous improvement

How do I get started with Kanban?

At a starting point, products that are already live and supporting customers often lends itself quite well to Kanban over Scrum, for example, as the demand and priority of issues can fluctuate over time, and it lends itself better to a continuous flow. However, if your product maintenance operated in Scrum, you may find yourself abandoning or breaking a sprint halfway through due to recently surfaced higher priority requests.

The best way to start is slowly, and to adapt a current process by incorporating the five core principles below, as described in David J Anderson’s book Kanban: Successful Evolutionary Change for Your Technology Business.

The Five Core Principles to create an emergent set of Lean Behaviors

Principle 1: Visualize Workflow.	Your workflow should be visible to the team on a board. With a defined workflow, first, you have to start work by pulling your first ticket in progress. Each ticket should correspond to one piece of work.
Principle 2: Limit Your Work in Progress (WIP).	Limiting work in progress reduces context switching, communication breakdowns, re-work, duplicate effort, meetings, and missed deadlines. You WILL BE more efficient. Tickets can continue to be pulled in progress, but only the number of tickets equivalent to the agreed capacity of a system should be put in circulation. Once the agreed-upon capacity is reached, no additional tickets can be pulled to in progress until capacity becomes available.
Principle 3: Measure and Manage Your Flow.	Metrics to consider tracking include Lead Time & Cycle Time, Work In Progress, Blockers, Throughput, Escape Defects, and times tickets are sent back to Development from Testing. Start with a few key metrics and go from there. Start by understanding how well your team is performing by establishing a performance baseline and creating a low-effort process to track & report this on a regular basis.
Principle 4: Make Process Policies Explicit	Set standards with your team to define and make clear what the expectations are for delivering work. Putting agreed standards in writing allows growing teams to ensure everyone is following the same process and following best practices. Apply change management practices and give team members a seat at the table.
Principle 5: Continuous Improvement; Use Models to Recognize Improvement Opportunities.	After setting baseline standards, define a process to maintain said standards, identify improvements, and iterate. Kanban is about evolutionary change. As such, continuous improvement doesn’t mean you have to stop work completely or even slow down – it’s about making small iterative changes to make you, your team, and your organization better. Read up on Theory of Constraints & Kaizen.

In Summary

Agile methodologies and processes serve as ‘tools in our toolbox’ to be applied in the right situations. Kanban, like Scrum, should not be prescriptive. Each combination of team, product, and organization will always be different, which means the way we apply agile principles to our process can and should be adjusted to fit each context.

The more we know, the greater the chance we can enable our teams to be successful – in any environment. And so, to the technology leaders who have learned and embraced Scrum, don’t stop here, continue on to embrace other agile philosophies – like Kanban.

Case Study: Delivering Efficiency at a Travel Startup

6 June 2019 By Peter Herr

1. Executive Summary

The most innovative thing I’ve done is to create a process of continuous improvement at Plusgrade, a startup in the travel industry.

When I arrived at Plusgrade in January 2018 the company was faced with consistently missed customer deadlines, weekly production issues, and inefficient processes and communication. By applying methods from several disciplines including Agile (Kanban), Continuous Improvement (Kaizen), Change Management, and traditional Project Management, I shaped an organizational culture that upholds customer commitments, is focused and efficient, and flexibly organizes around the most important company priorities.

This effort led to a reduction of defects, improved quality, and increased Product and Engineering efficiency by 40% from Q1 to Q3 2018. Along with the entire team’s efforts and contributions, this helped Plusgrade secure $150 million in investment in November 2018, valuing the company at $450 million.

2. About Plusgrade

Plusgrade is a startup that provides upgrade solutions for customers in the travel industry. Their flagship product allows travelers to purchase an upgrade to premium seats through an auction platform, which in turn, allows airlines and cruise lines to maximize the use of excess inventory.

Example: An airline customer, Scandinavian Airlines (SAS), uses Plusgrade’s white label platform to reach passengers traveling from Boston to Stockholm by email. Passengers submit bids on upgrades to First Class using the auction platform, and if selected, prior to departure their seat assignments are manually or automatically upgraded (based on airline preferences) through backend reservation systems.

3. Understanding the Problem

As Director of Product at Plusgrade, I oversaw two areas:

Delivery (or execution) of development work for 6 teams (7 Product Managers)
Oversaw the PMO, including 2 Project Managers managing 10+ simultaneous projects. I was responsible for ensuring Plusgrade kept our commitments to customers from a delivery perspective.

When arriving at Plusgrade in Jan-2018, we consistently did not meet customer commitments. The company faced the following problems:

Missed customer deadlines by months causing customers to threaten to switch to a competitor
Critical production issues every week (i.e., site availability, reduced customer conversion, execution of seat upgrade)
Poor communication within and across teams (i.e., unnecessary and wasteful meetings)
Inability to keep up with the workload load to initiatives that never finished or cancelled
High stress and low morale across the organization

4. Correcting the Problem

4.1 External Customer Commitments

I began by addressing what I believed to be the biggest bottleneck (concept: theory of constraints). The biggest problem that we faced was the fact that we did not meet our customer commitments: we did not actually do what we said we would. In order to increase trust and good favor with customers, I worked with the team on the following:

PMO Process Improvement: I established critical processes for the PMO which did not exist:
- I developed a project health report to communicate project status, risk and mitigation strategies
- We developed a project/Gantt timeline template
- We defined best practices for managing projects
Estimation: Some said we were not ‘supposed’ to do traditional bottoms-up estimation in Kanban. Yet our largest & most complex projects were consistently way over budget. If we want to meet customer committed deadlines, we had to estimate. And so, I developed and matured the estimation process with Product Managers and Engineering Team Leads to obtain estimates for all projects 1+ month in duration. In doing so, the team gained the ability to estimate with varying degrees of speed & granularity, identify risk, and understand critical areas where technical approach should clearly defined.

Result: Our large projects and most critical initiatives for our Customers were now consistently completed on time. This led to increased confidence with our Account Managers, and more importantly improved satisfaction and trust with customers.

4.2 Kanban Process Improvement

At Plusgrade, we were constantly being directed to work on 300% of what our available capacity actually showed we could complete. However, right-sizing this or “doing less” wasn’t a simple argument that the CEO would accept; he expected us to figure it out.

I gained credibility and buy-in from key stakeholders across the organization to embark on numerous process improvement and continuous improvement initiatives. Key examples include:

Track Expedites: We had too many fires. We established Expedite-level ticket prioritization, whereby anyone in the company could create a critical issue alerting PagerDuty and dropping messages in Slack, triggering the action and awareness needed to resolve the problem. Result: We tracked and measured Expedite issues, and fixed technical debt. This improved Engineering team morale as they had fewer stressful situations and late nights.

Define “Ways We Work” Policy: Work was not being prioritized and pulled by Product Managers in an efficient manner. This democratically-defined process document established baseline commitments that everyone agreed to:

Before “Ways We Work” Policy	After “Ways We Work” Policy
Tickets with no descriptions Tickets worked in incorrect status Developers pulling own tasks PMs pulling incorrect priority tasks Poor communication and status	Tasks clearly defined/detailed Tickets always up to date Only PMs pulling tasks with clear understanding of priority WIP limits defined Team metrics/goals defined Fewer meetings; better communication

Result: The company objectives/KPIs were now much more closely aligned with development work performed by the 6 Product & Engineering teams. We reduced inefficiency and waste.

Prioritization Meeting: With 65+ customers and ever-changing priorities for 6 engineering teams, Product Managers didn’t always have the latest information from Leadership, Sales or Account Management about what’s most important to the customer. We established the Prioritization Meeting to review incoming tasks just before development would start to ensure it was always next highest in priority and tickets were clean/ready. Result: This provided much needed accountability so that engineering capacity was always applied to the most important company priorities.

4.3 Product and Capacity Planning

Using a revenue share model with customers, when a new contract was signed Plusgrade began to get paid once the product went live and was processing Upgrade payments. What I learned and expressed clearly was that when a new customer was signed, the implementation of their product immediately became the highest priority project for the company, to be started immediately as it represented the highest revenue opportunity for the company. This was effectively like adding an additional 10-15% company-wide workload to the top of the priority list for the next 8-12 weeks onto a team who’s capacity was already committed to other work. These signings were relatively unpredictable, coming in fast from Sales.

Plusgrade planned upcoming work in 3-month increments, and was continuing to underestimate and overcommit to the amount of work that could be completed. Without key data points and insights, the Leadership team lacked the appropriate details to collectively understand why Product and Engineering was having project delays and missed milestones.

Several Operational metrics I put in place include:

System and Customer Lead Time

Work in Progress (WIP)

Escape Defects (bugs allowed into production)

# of trips from testing back to development

Ticket type (i.e., bug vs improvement)

Type of Request

Result: These metrics allowed us to quantify and report on where effort was being spent and how Product and Engineering teams were improving.

Development teams now had more information on their own performance which made their retrospectives more effective.
Product and Engineering more clearly communicated progress on key initiatives, where capacity was being spent, steps being taken to improve efficiency, and ultimately was able justify additional staff to support Product efforts for FY 2019.

5 Summary

Plusgrade’s Product and Engineering organizations had poor communication, lacked efficiency and did not meet customer commitments. Through initiatives I led, the team was able to correct these issues resulting in the following:

Process improvement efforts increased customer satisfaction, reduced wasted effort, and increased efficiency by 40% from Q1 to Q3 2018.
The Leadership team had a better understanding of 1) current Product and Engineering initiative status and health and 2) where capacity was being spent, which improved organizational alignment.
The Product and Engineering team justified additional resources to expand the 40+ person team by 30 people for FY 2019.
These efforts supported Plusgrade’s ability to secure $150 million in investment in November 2018, valuing the company at $450 million (https://bit.ly/2IgUicm).

Do you run Stand-Up? Learn this important strategy to help your team be more efficient

22 July 2018 By Peter Herr

All development teams have an opportunity to improve their stand-up meetings and reduce the number of overall meetings and interruptions the team has on a weekly basis. We all know that meetings will be better run when those leading the meeting come prepared, yet why do so many not prepare for their stand-up meeting?

‘Walk the Board’ is a fundamental concept that will allow you to enable your team to be more efficient.

What is Walking the Board?

Walking the board is a process where you review all tasks currently in progress with your team, starting from those closest to being finished first and working from right to left across your board. The goal of this is to keep the team unblocked and efficient and to minimize the chance of a misstep happening in the development workflow.

Often time, Walking the Board is a concept for how to run a stand-up, which is also a great practice and an option to consider following. However, the proposition made in this post is that this task should happen by someone – anyone – on the team individually before the stand-up begins. Usually, this person is the Product Manager, Scrum master or Technical Lead.

Why it’s important?

It saves time and effort! That means cost & time savings for the business, increased the chance that you’ll meet project deadlines, higher throughput, and happier teams. If no one properly ensures the team is following an optimal flow, mistakes WILL HAPPEN that can lead to lost effort, inefficiency, or technical debt.

How do you ‘Walk the Board’?

Step 1: Review each ticket individually and ask yourself:

What is the current status of the ticket? Is it clear?
What is the next step for the ticket? Is it clear?
Are there any issues with the ticket that should be addressed? Example issues could be:
- It’s blocked
- Confusing requirements or purpose
- It’s not updated
- Not following the teams established process

Step 2: After doing this with each ticket, appropriately update the ticket or take a note with your list of action items or questions for the stand-up:

Questions to ask during the stand-up on particular tickets
Tickets that require a discussion after the stand-up
Action items for you to take (testing, requirements clarifications, ticket cleanup, etc)

If you do this effectively, you will have greater awareness and status on what your team is working on, and save yourself time throughout the week since you won’t have to constantly check on the status of tickets. Additionally, you will have provided yourself with a list of action items, which you can appropriately prioritize against everything else you have to get done or delegate out to other team members.

But this will take too long? I have too many tickets to review!

This is not a good excuse. It’s like people complaining they don’t have time to exercise. Wake up 30 minutes early, get to work, and GET IT DONE. If you either can’t spend more time or can’t finish in 30 minutes, then finish after stand-up.

If you can’t finish after stand-up, then start where you left off the next day and finish the rest of the board.

After doing this for a week, you will find that:
Your review will happen faster and faster, since you constantly know the status of where things are through your stand-ups and your individual walk the board.
You save time throughout your day because you’re already up to date on current issues, and you’ve prioritized your investigation of other issues for your team.

If you still find you have too much Work in Progress, consider limiting it so that developers are not working on too many tasks at once. This is a core principle of Kanban which can be applied to any process, and can help increase the further efficiency of your team.

Summary

Product Managers and Scrum masters are responsible for being facilitators of good process for their teams. The ‘Walk the Board’ strategy is a fundamental way to keep up to date on tasks, and allows you to ensure team members are following the process, staying unblocked, and working together efficiently.

About Peter Herr

Peter is an experienced Delivery Manager and Product Manager with 10+ years in technology consulting, notably spending 3 years managing and launching new high-profile technology products for the Obama White House.

As the Director, Product Delivery at Plusgrade, Peter oversees all product implementations and focuses on improving delivery practices. Plusgrade is a startup focused on increasing ancillary revenue for partners in the travel industry.

Beyond Scrum: Why Product Managers and Leaders Should Learn Kanban

19 July 2018 By Peter Herr

Scrum brought with it a revolution to how we work together as product teams. It brings together a common understanding of how we can better develop products and nicely illustrates our roles/responsibilities in an understandable way. Yet it’s just one agile method, one approach. Just one philosophy of many.

Why do so many teams stop learning once they know scrum? There is a better way to work.

Long ago or not so long ago we spent two days in training, and after that, we have learned a framework for managing the team and can explain why what we do is better than the “waterfall”. Stand-ups, 2-week sprints, etc and now everything is awesome. But then once you apply it and start learning by doing, something else happens – you start seeing where it can potentially, or occasionally, just might – fall apart.

The purpose of this post is not to bash scrum. Not the point. Scrum has reached incredible adoption and has made things better for everyone. It’s a worthy framework to know, understand, and practice. My point is different:

Product Managers and Leaders should learn a second approach, like Kanban.

Learn a second approach, like Kanban.

There is a huge opportunity to up our skills by knowing more than one way to work. Why you should learn it:

Be a more effective manager and leader. Apply multiple approaches when and where needed to manage through difficult situations.
Have a more effective and efficient team. When managers and teams appropriately learn and adopt the principles of Kanban their teams will consistently outperform those that don’t. However, most teams either don’t know Kanban or don’t have enough experience with them to apply them adequately.
Be more marketable. The more you know, the greater the chance for earning that promotion or new gig.
You may already be practicing it unconsciously. Lastly, if you don’t know it, many of us are already doing kanban in basic form or another. And so if that’s the case, why not follow the

My first experience with Kanban was 5+ years ago where I was fortunate enough to work with a super talented, bright, and hardworking team at the Executive Office of the President. It was here that I was able to truly grasp the value of managing a team differently, and understanding how a second philosophy can also be super effective at managing a team.

Many teams struggle to deliver their products with adequate quality and efficiency, yet most of them either don’t know it, or they do know it but are still learning to apply it. Kanban can help solve these problems.