Holistic Methodologies: Odd bed partners (Six Sigma and PMLC/SDLC), but Harmonious Relatives
Special K (Kaizen, Kano Model Delivered through Kanban)
No, I'm not talking about breakfast cereal. This article explains how Kaizen and Kano can be used in conjunction with Kanban. Building on the previous discussion on Poka Yoke, we will explore additional continuous improvement topics and how they relate to software development or operational support of a legacy environment. Let's start with defining each of the components and how they support each other.
Kaizen simply means "improvement" or "change for better." Kaizen is a core tenet of lean manufacturing. You might say it focuses on the process of process improvement. It also supports the Deming wheel of Plan, Do, Check, Act or the (PDCA) lifecycle. Some other guiding principles of Kaizen are:
- Good processes bring good results. "Good" in this case it means that processes are documented and that all actors have a common understanding of their boundaries, metrics and outcomes.
- Management by walking around. Nip the problems in the bud by talking to the actors without micro-management.
- Speak with data, manage by facts. Kaizen leaves no room for guessing or emotion-driven decision making; the clock or defect rate tells the true story, yet another example of voice of the process (VOP)
- Work as a team as Kaizen belongs to everyone. A process is owned by its actors just as much as by the process owner who is accountable.
- Control defects by root cause analysis. Asking the right questions allows us to derive the root cause (see the previous article "Why Oh Y Does X Mark the Spot").
Kano is a theoretical model to drive customer satisfaction through product or service capability. Simply put, the pleasers of today are the must haves of tomorrow if you wish to remain competitive or continue to enjoy the confidence of your customer.
The Kano model can be broken down into five primary components.
These are the pleasers of yesterday and mandatory requirements of today. Think of the progression of portable music devices.
Initially, a transistor radio was a pleaser in the 1960s, but a radio became an expected inclusion in later generations of portable music devices. Eventually the initial capability was no longer as important to the core capability, but was still expected to exist. Examples of this can be found in software and hardware application capability and reliability.
- Mean time between failure
- Total cost of ownership
- Ease of maintenance or enhancement of the core product
Fundamentally, these are attributes that the product must have to be considered complete. The product would not be considered a marketable or competitive product without them from a usage or support standpoint. The attributes listed above are also considered non-functional requirements, but not all must-be quality attributes should be considered non-functional. For example, core functionality or compatibility with other applications also falls into this Kano component.
These are quality attributes that become customer pleasers when present, but if they fall short of expectation they can quickly become displeasers. Using our example above:
- Mean time between failure, but when it fails the failure is costly or catastrophic
- Total cost of ownership, but the cost goes up unexpectedly after year x
- Ease of maintenance/enhancement of the core product, but the resources are not available to do so due to skill set or prioritization
- Usability, but there is no documentation or the documentation is limited or inaccurate
One-dimensional attributes can also encompass performance metrics such as skill, product knowledge and relationship management, which relates to how much the customer is willing to pay for these capabilities even though their value may be difficult to quantify.
Attractive qualities are attributes which provide satisfaction when fully implemented, but do not displease if not present. Continuing our example:
- No mean time between failure metrics exist, but the product is reliable
- No total cost of ownership metrics are available, but the product is cheap to acquire and use
- A dedicated support team is available, but product support can be done by the users or is stable and does not require much maintenance
- Documentation is not available, but the product is intuitive and easy to use and the documentation is not deemed necessary
These are attributes that the customer does not necessarily derive satisfaction or dissatisfaction from. They may be even transparent.
- Preventive maintenance is routinely carried out resulting in a low mean time or no failures
- Total cost of ownership is part of an operational budget and transparent to the customer
- Server patching and backups -- part of preventive maintenance
- Unused application features -- capabilities bundled out of the box that do not pertain to the product usage by the customer
These attributes provide a significant level of dissatisfaction caused by giving the customer something they did not want. Some examples:
- A new product feature that was expensive to develop but is difficult to use, defective on shipment, or is useless to the customer due to performance issues.
- User 1 wanted a simple solution, User 2 wanted a more sophisticated capability, and User 3 wanted something completely different, but was not even consulted. All three customers find a deficiency in the end product.
- A new capability was delivered but removed existing capability the customer still needed, resulting in the product being dumbed down or forcing the user to do critical business processing manually or outside of the system.
Kanban's literal meaning is "signboard" or "billboard" in Japanese. The term was first applied in the context by Taiichi Ohno (1912 - 1990), father of the Toyota Production System, which later became Lean Manufacturing.
Taiichi Ohno derived Kanban from his study of supermarket concepts of self-stocking factory supplies.
Toyota's Six Rules
- Do not send defective products to the subsequent process.
- The subsequent process comes to withdraw only what is needed.
- Produce only the exact quantity that was withdrawn by the subsequent process.
- Level the production.
- Kanban is a means of fine tuning.
- Stabilize and rationalize the process.
Kanban focuses on continuous improvement within the process lifecycle, as each pass delivers throughput metrics relating to cycle time duration and product defects.
In manufacturing, Kanban uses a three-bin system. Bin #1 is the initial demand point (orders) on the factory floor, Bin #2 is in the factory store (inventory), and Bin #3 is at the supplier. Each bin is represented by a card that is shown on a Kanban board, and the contents of the bins are monitored. When Bin #1 is emptied in the course of manufacturing work, the contents of Bin #2 in the factory store are moved to Bin #1. Likewise, an order goes out to the supplier (Bin #3) when Bin #2 becomes low or empty.
Kanban in Agile Development
In Agile development, Kanban has become increasingly popular in some shops, even supplanting Scrum (especially with the advent of the Scalable Agile Framework or SAFe, which is beyond the scope of this article). David J. Anderson has been a major player in adapting Kanban to software development.
Here are some of the core tenets and guiding principles of his approach, as formulated by David J. Anderson:
- Start with what you do now. Agile Kanban does not replace your current process. It only provides change management controls.
- Agree to pursue incremental, evolutionary change. The performing team agrees to make improvements without impacting the overall process.
- Respect the current process, roles, responsibilities and titles. It's important to respect the current process and the actors within it to eliminate threats based on changes from evolutionary process changes.
- Leadership at all levels. Empowerment to execute is driven down to individual team members.
- Visualize. The workflow of knowledge work is generally invisible. Process control requires visualizing it using a Kanban board or wall with cards to represent the tasks.
- Limit Work-in-Process. Limiting work-in-process (WIP) focuses on supply and demand (Pull system) for parts or application areas that will be impacted by the change (Continuous improvement (Kaizen)).
- Manage Flow. Managing flow, the team can control the level of interdependency between tasks and control quality.
- Make Policies Explicit. Documentation of working agreements, exit agreements, or definition of done (DoD) institutionalizes the common agreements across the team.
- Implement Feedback loops. Use metrics and measures along with anecdotal narrative to explain events that are occurring during the process.
- Improve collaboratively, evolve experimentally. Team consensus on improvements to make to the process/product is work output, and suggests a scientific approach, but is not prescriptive like Scrum.
Anatomy of a Kanban Board
A Kanban board can exist as either a physical instance or within a software product.
- Backlog is synonymous with the product backlog or orders that will be delivered as part of the current release.
- Defined contains the User Stories (US) that have specific functional and business requirements defined and are ready to be pulled into the Work In Progress (WIP) Bin.
- The In Progress or WIP Bin should only contain one or two user stories that the team is focusing on during development.
- Completed contains user stories that are completed by the development team and may be handed off for user acceptance testing (UAT).
- Accepted are those user stories that have been accepted by the product owner or customer and are in production.
Other Bin Tidbits
- Bin categories are industry specific. System maintenance bins would be different from a manufacturing Kanban board.
- Bins can be tied to exit agreements to denote when work will be moved from one bin to the next.
- These bins can also be aligned to the same phases used in Scrum or customized to logical phases of your business or manufacturing process.
- Careful monitoring of the content of each of the Defined, In-Process and Completed bins should occur at all times to make sure there are no bottlenecks in the overall throughput occurring.
Bringing It All Together Using Kanban
Using the continuous lifecycle within Kanban versus the stop-start approach of Scrum makes it easier to adapt how continuous improvement is applied via Kaizen. Kano can be applied by reviewing the applicability of the user stories within the product backlog to current needs and future delighters as the product evolves and is used by the customer.
Think of Kaizen as the way improvement is applied to the development process, Kano as the method to gauge value in the customer's eyes, and Kanban as the value or feature delivery method.
Just Say No to "Gold Plating"
In PMI's Project Management Body of Knowledge there is a discussion around Gold Plating, or giving the customer more than what they are asking for. This tenet also holds true even in the Kano model. Don't try to second guess what the customer can derive value from. The customer is your partner and should always be consulted to make sure you are delivering value. Even though the content of that value (product backlog) is dynamic, this Special K formula using these methods, coupled with ongoing dialog with the product owner, will ensure that the customer always has a healthy start each day of the product development and delivery lifecycle.
Further reading – Karen Martin/Mike Osterling – The Kaizen Event Planner
A really good video showing how Kaizen can help even simple manufacturing processes: https://www.youtube.com/watch?v=su9CulCZTBg
Consulting and education