In late 2016, I took over the WillowTree website project (the very site you are on now!). We were moving from a Wordpress implementation to an in-house build. Completely new design, new content management system, analytics overhaul, new servers, the works. Everything was being re-implemented from the ground up. My new stakeholders all had the word “Chief” in their title, too. In short, lots of dependencies, plenty of unknowns, and a very high profile. Also due to the nature of our fast-paced business model, we expected frequent new requirements from our executives. Oh, and a deadline.
One of the first decisions we had to make as a team was which Agile methodology we would use. This project had a lot of shifting priorities and changing requirements, and while I was most familiar with Scrum, a “Lean” approach seemed like a better fit for this project. Luckily, the tech lead on the project had plenty of Kanban experience and championed it.
I’ve seen Kanban implemented poorly at previous jobs, so I wanted to focus on the Kanban Values and Principles in order to avoid some of the more common mistakes and lay the groundwork for success.
When teams implement Kanban, but ignore the driving ideals behind it, the process often morphs into something that looks more like a free-for-all. While Kanban does not have a defined “Sprint Planning” meeting, you will find that there is plenty of planning and process involved in Kanban when implemented correctly.
By discussing each of the 5 Kanban Principles with your team and brainstorming the best way you could exercise them in your organization, you will explore lots of ideas and come up with good starting points that work for you. Kanban also has 9 Values that I’ll be bolding throughout this article.
Visualize your work
In a lot of cases, this can be done simply by using a wall, some painter’s tape, and some post-it notes to visualize your queues and your workflow. In addition you could draw your burndown chart on a whiteboard and update it at standup every day for example. In our case we used Jira, so at standup every day we brought up our board so everyone was looking at and discussing the same thing.
We also routinely looked at our cumulative flow diagram, which told us how long our work was staying in progress, and how many stories we were completing per week.
Your board, your charts, and your diagrams act as Big Information Radiators ensuring that everyone is seeing the same image of what is in progress, what’s next, and where problem areas are. This kind of transparency promotes discussion, accountability, and responsibility.
Limit Work in Progress (WIP)
We looked at each of our queues, like “In Development,” “Ready for QA,” and “In Test” and figured out reasonable limits for each - in our case, it was 2 stories per person. In Lean this practice relates to “Heijunka” which means Leveling. Leveling equates to reducing the batch sizes of your work so that you are delivering the right amount of customer value, at the right time. Keep work items small, reduce delays in the system for quick throughput, and deliver items quickly with WIP limits. On the website - we agreed on stories smaller than 3 points, we and set WIP limits of 2 stories per person. Whenever we hit a moment where a team member wanted to go above that limit, it always indicated a problem. Answering “why” would surface a blocker, like they were waiting for an answer from I.T. before they could finish a ticket, or something similar. It was my job, my top priority, to be removing impediments and delays like that as quickly as possible.
Figuring out the right balance for your team is important. For more information on optimal queue size, check out any article that discusses “Little’s Law” in relation to Kanban.
This principle ties into the Lean concepts of “Just in time” and “Pull Systems”. In Kanban you manage flow by focusing on how much customer value you can deliver in the immediate term, instead of trying to plan out big backlogs of work. This requires constant attention to your ‘To Do’ column, creating small, manageable stories that can flow quickly through your queues, and being vigilant about the prioritization of the next work to be done. You also want to be removing any “Muda”, or waste from your processes. This includes any delays, premature optimization, bugs, and any other actions or movement that are not creating value for your customers.
We set up a cadence of regular story grooming sessions every week, and discussed upcoming priorities every day after standup. If any story looked too big, or complex, we broke it down, and if we didn’t have a good handle on how to implement it, we put in a ‘spike’ story instead to act as a discovery task.
Make Your Process Explicit
Once your process is decided, ensure it is published and socialized with stakeholders for maximum transparency and understanding. We did this on our wiki and made sure it was easily accessible, constantly updated, and often discussed.
Collaborating as a team, we worked out what the agenda, duration, and participants for our demos, retrospectives, bug triages, groomings, and standups would be. We agreed on the severity definitions of our bugs, and how big stories should be. Our QA process was outlined and our code review practices were codified and documented. We agreed on a ‘Definition of Done’, when an item is ready to move from one process state to the next, for each of our queues to help with flow. Coming up with a “Definition of Done” led us to discuss Jidoka, which means “Built in Quality”. Ideally, we wanted our project, workflow, and product to be as efficient as possible, require minimal refactoring, and have few defects. This is accomplished by building quality procedures into your creation process. This means good coding and testing practices like those discussed in Extreme Programming (XP), such as Pair programming and Test-Driven Development (TDD).
By explicitly deciding how all of your processes work, you add stability and standardization to your team by making your creation process repeatable.
In Lean this is called “Kaizen”. We tried to create a team culture where everyone involved in delivering value to our customers was also actively engaged in improving the processes used. Honesty, transparency and a willingness to fail in the name of finding better ways to work is imperative.
Establishing regular retrospectives was step one. We established a bi-monthly retrospective that everyone involved in the project was invited to. We changed up the format several times, adding “Shout-outs” and “What keeps you up at night” sections to more familiar retrospective agendas like “Same as, More of, Less of” and “Loved, Loathed, Longed For.” As a result of these retrospectives, we tried new processes routinely to see whether they would improve our throughput, modifying the way our QA process worked and our demo cadence for example.
In addition to this, we established early the practice of “stop the line” from Lean, which enabled anyone on the team to bring up a critical priority issue that we would all swarm around. Close to the website launch date it was decided that we absolutely had to have a “Leadership” section of the website. Once the priority was decided, and trade-offs were agreed on, the whole team pitched in the design, develop, test and launch this feature to our staging site for stakeholder approval.
Kicking off your Implementation
Starting with the Values and Principles of Kanban will promote some great team discussions, and help re-enforce why you do what you do. A shared understanding and a focus on quickly getting the customer as much value as possible provides a solid foundation for any team.