I have found that very few organizations are starting out with Kanban as their first choice for their Agile implementation. Almost every organization that I have been exposed to through training and coaching began their Agile implementation with Scrum. Unfortunately, many companies have significant organizational impediments to being a true Scrum shop.
Before I go any further, I want to say that I am a Scrum believer. If there is a way to implement “pure” Scrum, I believe you will have the most productive and happy development teams. That being said, I have found that many organizations trying to implement Scrum have significant "Scrum-buts"and their implementations would be better served by stepping back and considering a simple Kanban approach.
There are many different approaches to Kanban for software development, and some are even proprietary. Since everyone else is attempting to trademark their own Agile approach, from this day forward, I am trademarking, “Simple Kanban™.” Just kidding… Anyway, the benefit of Simple Kanban is that it assumes you already understand Scrum and User Stories and can apply what you have learned in Scrum to Kanban. When I train on Kanban, I train one day of Scrum and User Stories and one day of how to apply those practices to a Kanban approach.
I can’t say that I am an expert in Kanban for software development, but early in my career, I did have some great exposure to Kanban in manufacturing. In college, I majored in Industrial Engineering, and my first “real” job was working as a sales engineer for an environmental controls manufacturer. They used the Kanban pull system for inventory control and as part of my onboarding training I spent three weeks on the shop floor. It was an experience that left a deep impression on me.
While I worked there, they won the Shingo Prize for world-class manufacturing and excellence in productivity and process improvement; quality enhancement; and customer satisfaction. This award is considered one of the “Triple Crown” industrial excellence awards, along with the Baldrige National Quality Award and the Deming Prize.
- Specify what creates value from the customer's perspective
- Identify all the steps along the process chain
- Make those processes flow
- Make only what is pulled by the customer
- Strive for perfection by continually removing wastes
Keep existing functional teams: Most organizations are struggling with eliminating roles, especially QA. One major reason that this won’t change is because separation of duties is required for many IT shops.
- Business Analysts perform role of Product Owner and write User Stories. They prioritize these Stories in the Product Backlog for the development team which becomes the work queue for the team to pull from. Ultimately, given the lightweight nature of User Stories, there will be fewer Analysts needed.
- Software engineers perform high-level design, and identify the development tasks. For complex systems, it may require that an architect or senior software engineer is on the team for this activity.
- Software engineers continue to develop, write unit tests, and advance Agile engineering practices such as continuous integration. This is the same role they have been playing, but in a “pull” environment they will be much more empowered.
- Lastly, retain quality assurance team members to perform functional testing. I still suggest that the Business Analyst and/or a true Product Owner role exist to perform ongoing acceptance testing.
Utilize User Stories: Kanban typically uses cycle time to size requirements. It may be heretical for me to propose this, but User Stories can accomplish the same thing, especially if the team members have already been trained on User Stories.
Manage WIP using functional velocity: Each functional team estimates the story points for their work on a story. As with Scrum, over time, each team will know their velocity and can commit to their work in progress (WIP) limits. They can then work towards a stable time-based velocity which can provide the same transparency as cycle time.
Team Size is managed by Story Points: The number of business analysts, software engineers and quality assurance team members is determined by the number of story points in the functional queue and ultimately the release schedule. As with Scrum, multiple small Kanban teams work better than one big one.
Self-Organizing is the same as a Kanban pull system: When a team member is done with a story, they go get more work from the queue.
Keep open spaces: This is just a good idea. Regardless of your Agile approach, one of the keys to success is having everyone in the same room.
It may sound complicated, but as with Scrum, after a few cycles the team begins to work out the kinks. I agree that over time, cycle time is a better approach for Kanban, but if you are moving from a Scrum model, it may be an easier transition to retain the use of Story Points, and I have seen teams be successful with this approach long-term.
Do you want to learn more about our approach to Kanban? We have 2 options:
- Contact us for a quote for onsite training
- Try our on-demand training Implementing Kanban for Project Management
Interesting article. I just recently wrote an article, why moving to Kanban won’t solve your problems: http://marcloeffler.eu/2015/11/09/why-switching-to-kanban-wont-solve-your-problems/
I have a question about that Kanban board you show: http://www.setheliot.com/blog/2015/07/17/analysis-and-design-as-named-columns-in-kanban-in-scrum/
After years of successfully using Scrum, one of my teams tried to do “pure” kanban (note: this is no such thing), ignoring the first rule of Kanban, which is to start with the process that you have now. Within a week, we had restored most of the Scrum practices, ending up with something probably very close to what you call “Simple Kanban” which was a Scrum approach to defining work and to talking about it in daily standup meetings and a Kanban approach to visualizing work and focussing on flow. The thing we never missed, and still don’t, is timeboxed iterations. It took a while to establish the most effective cadences for us, but they certainly weren’t done by linking planning, deployment, and retrospectives.
Same here – we tried different things, some worked, some didn’t, but the one thing that we never missed nor liked was a typical scrum where you combine the 3 (plan, release, retro). We now do Scrumban, which is some time-boxing and wip limits, seems to be doing the trick. I’d like to offer a good follow up read, if possible – http://kanbantool.com/kanban-library/scrum-and-kanban/why-we-dropped-scrum-for-kanban#.Vk8iDnY6PDc. Seems like a story I hear over and over again ; )
Regarding those 5 lean principles I’m glad to hear that my team estimated more or less similar basic rules. We needed time to find most suitable software. Finally after couple tests we figure out that there is no perfect solution, but best performance gave Kanban Tool