Real-World by Kanban Mattias Skarin

• Kanban is a bit like the Chinese board game Go--a few moments to learn, a lifetime to master.
• Storytelling is the most ancient and effective way of conveying knowledge.
• Magic happens when people are in the zone, when they can focus their creative energies on making a difference in the world. Positive things happen when they realize they can challenge and improve things that don’t work, even when the problem spans across the organization.
• The actions you take every day shape your future.
• The true are of improvement is all about making the most of opportunities as they present themselves. It’s about grasping, exploiting, and leveraging opportunities to your benefit and advantage instead of staying put with the status quo.
• The idea is simple: a Kanban card is sent upstream when there is a need for parts. It is only then that production for the needed number of parts is done. The arrival of a new card is a signal to produce more parts, and a lack of cards is a signal to stop. The number of cards is limited to prevent overpopulation and to reduce the parts needed in production.
• The Kanban rules are in fact much more interesting than the Kanban cards:
• A later process tells an earlier process when new items are required.
• The earlier process produces what the later process needs.
• No items can be made or moved without a Kanban.
• Defects are not passed on to the next stage.
• The number of Kanbans is reduced carefully to lower inventories and to reveal problems.
• Knowledge work is largely invisible, often hidden in hard drives and in email inboxes. Visualizing workflow allows us as a team to act and learn based on a shared overview.
• By limiting the work-in-progress, we allow our teams to work at a sustainable peace with quality output. Limiting WIP is often the first step to shift the emphasis from starting to finishing.
• The two most common measurements for flow are throughput and lead-time.
• The big idea behind the Kanban method as applied to knowledge work is to improve evolutionarily from the current state using small steps.
• Here is a rule: no defects can be passed on to the next stage. Passing known defects down the line is unconscionable--not only does it increase costs because of rework, it also wears down trust between people and teams.
• In Lean, we judge value from the customer’s perspective.
• The trademark of a Lean organization is its focus on continuously improving. To always be better is the operational strategy.
• When we improve how work is done, the resulting efficiency leads to a reduction in total costs.
• To ensure focus and to avoid political deadlocks, it helps to use scientific thinking and small experiments to improve.
• Taking a fact-based approach to decision making helps preserve energy. The key to decisiveness while applying a fact-based approach in product development is to recognize that the goal is not to be exactly right, but to seek just enough information so that we can eliminate the unlikely options.
• A sanity check for long-term leadership is that a change should never come as a surprise. Follow this rule, and it will help you build up trust capital. This trust capital is hard currency when it comes to taking risk in periods of uncertainty.
• When observing the world, our mind has to decide what information to act on. So if you see something that your mind doesn’t think is important, you subconsciously ignore it. This is known as change blindness. So in a sense, we are predisposed to ignore and discard new information, even when it is staring us in the face.
• Your leadership is only as strong as the conversation you are ready to have.
• You only really know whether your actions generated the desired effect by observing real outcomes (product quality, lead time, predictability on delivery, and so on).
• Leadership is your ability to seize opportunities and to turn information into action. This requires building up people and managers who are problem solvers and who take initiative when opportunities present themselves.
• No product is perfect the first time. No problem is perfectly solved by the first solution. Generally, some tweaking is needed once a solution is put to use for the first time. But the trick is not to wait for perfect information before starting. In any complex environment, waiting for the perfect solution means waiting until it’s too late.
• For both hardware and software, time to feedback is a leading indicator of innovation speed.
• An organization’s ability to solve problems and make good decisions is key to keeping up pace. The fact that decision pace tends to slow down as an organization grows often goes unnoticed.
• The ability to learn is an essential competitive advantage.
• Thumb voting is a very simple decision-making technique and helps teams jump into action:
• Thumb up means, “Yes! Let’s go!”
• Thumb to the side means, “Hmm, I’m unsure but willing to give it a try.”
• Thumb down means, “No way, this is crazy!”
• As a general rule, people are more likely to agree to an idea or change if they get to weigh in first. People are more willing to accept an alternative plan if they feel their concerns have been heard as part of the process. If you get a negative response, then ask for suggestions. Doing nothing is never the better option. Letting other ideas bubble up always is.
• For a process to be useful, the people who use it have to take ownership. To do that, the process has to be simple.
• A good facilitator ensures that multiple options are explored, especially for ideas that were rejected unintentionally or that got lost during the conversations. Facilitators should also inspire team members to think about the problem from different angles.
• An all-too-common mistake I see product development departments make is determining cost and time estimates on too fine a granularity.
• Clarify the decision you are trying to make first; then decide what makes a reasonable investment to make your decision.
• The idea of having a standup is to see and act on problems. This means the forum needs to have decision-making authority on both product-level calls and technical issues.
• If for any reason you are not able to continuously validate the usefulness of a product under development, alarm bells should ring. Regardless of your choice of development method, this is your first clue that something will go wrong.
• Every new product needs at least one revision before getting it right--this is your key to corrective action.
• The art of slicing (turning big things into small) and continuous validation of working software are two key components that can help you get it right.
• In software, early indicators of success or failure often show up in the form of observations by people close to the problem. Experience helps in detecting important signals from noise.
• Basing improvement decision on documented processes is not a good idea because it is a flawed premise based on flawed assumptions--namely, that documents reflect how work really happens and that they provide fact-based guidance to your biggest improvement opportunity.
• A well-documented process is unlikely to show how things really happen. Software development moves fast. If it is perfectly documented, it is probably already outdated.
• The importance of the role of communication during change cannot be overemphasized. Keep this as a rule of thumb: a change should never come as a surprise. When change happens across multiple functions, you cannot leave communication to chance. Verify if and how the message got through.
• Avoid abstract terminology, because it could invite reinterpretations of your message.
• By enabling people who depend on the team to see progress, you allow them to coordinate work proactively on their own, without having to bother the teams for status reports.
• Keep an eye on your board. If you, as the manager, keep the board neat and tidy and act on what happens, you will inspire the same behavior in your team.
• There is a simple rule to follow if you don’t know whether a tool is right for you: make sure you have a good reason for using it. “It sounds cool” isn’t enough of a reason.
• The first step in solving a problem is seeing that it exists.
• It’s really difficult to figure out how to fix the problem if no one agrees what the problem is in the first place.
• Making a stand for quality is always a good bet.
• A trick to free up time is to look for planning efforts aimed at future work. The more distant the future, the higher the chance the work will be rendered useless by later changes and your preparations will have to be redone.
• A very simple and effective technique to estimate a bunch of stories in one shot is to gather your team and silently sort the stories on a table, from the highest complexity to the lowest.
• A challenge to using the 5-Why technique is knowing when to stop. If the cause is outside your sphere of influence, then stop. Strive to do something small that improves things, even if it isn't he perfect approach. Over time, the small things add up.
• It’s easy to fall into the trap of making short-term decision when you’re under heavy pressure.
• Visualization is essential in knowing what needs to be addressed.
• The first step in good leadership is to clarify the common goal.
• Try to resist the temptation to postpone improvement actions and defer decisions. Procrastination will set you back right off the bat. A good leadership strategy is to always do something, regardless of how small, to improve the current state. The effect of improvements is cumulative, so don’t underestimate the effect of small improvements. By making many small improvements, you are also setting a good leadership example; people will do what you do, not what you say you would do.
• The second thing to do in good leadership is to follow up with vigilance on improvement actions taken. Nothing derails trust and brees resentment more than people not pulling their weight.
• Stick with one improvement at a time. Investing in quality is always a wise choice.
• There is no better way to fix problems than to have the developer on the spot, sitting right next to the user.
• Getting to know the people on the teams you want to involve in a change is a wise tactic.
• Developing things that people want is more important than running faster.
• Products are developed by people. A great tools can never supersede great people. The job of a great tool is to help skilled people find more value-added use of their time.