Without test automation, how do you face future:

Without test automation, making changes in the system is very hard, because things break without anybody noticing. When the new release goes live, the real users discover the defects, causing embarrassment and an expensive hotfix—or even worse, a chain of hotfixes, because each hotfix introduces new, unanticipated defects. This makes the team terribly afraid to change code and therefore reluctant to improve the design of the code, which leads to a downward spiral of worse and worse code as the system grows.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

What to do when in doubt:

Just stick to this rule of thumb: “When in doubt, choose the simplest solution.”
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

So Write down the test cases, then start a experiment travel, never make expensive decisions before you get enough knowledge.

The output of Empirical process control and complex adaptive systems theory:

Scrum is a software development approach that Jeff Sutherland and Ken Schwaber developed during the early 1990s. It is rooted in empirical process control and complex adaptive systems theory and was inspired by a Harvard Business Review article called “New New Product Development Game” from 1986.[11]
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

Mapping Lean principles to software development：

Mary and Tom Poppendieck have been instrumental in mapping Lean principles to software development. Here is their summary.[9]
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

http://www.poppendieck.com
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

How to drive a valid change:

Most people like change; they just don’t like to be changed. So, don’t make any change without first involving the people who will be affected by it. Forcing people to change is usually ineffective, unnecessary, and, well, cruel. If people resist your great change proposal, you probably haven’t made the problem clear enough. Or you’re solving the wrong problem. Go back to your cause-effect diagram (see Chapter 20, ​Cause-Effect Diagrams​) and think again! Better yet, don’t even make the change proposal yourself. Instead, visualize the problem that you think you see, and engage the people affected by the problem to propose solutions. People are much more likely to accept a change if it was their own idea! Once everyone agrees that the problem really is a problem and that it is worth solving, then you’re halfway to the solution!
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

Have Dedicated Change Agents to make change smoothly.

Change is hard! Especially when it involves people. And organizational change always involves people. One critical success factor is having at least one dedicated change agent, someone who focuses almost entirely on driving, leading, and facilitating the change process. Even better, have two change agents: one insider and one outsider. The insider (typically an employee) has the domain knowledge, knows who to talk to for what, and knows the history of the organization and what has worked in the past. The outsider (typically a consultant) provides a fresh perspective and experience from helping other companies go through the same type of change. Culture can be defined as things that everyone does without noticing it.” An outsider is more likely to notice, and challenge, the status quo.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

How to deal with Real or Hypothetical problem:

Whenever you’re trying to change something, ask yourself continuously, “What problem am I trying to solve? Is it real or hypothetical? Is there any other more important problem that I should focus on instead?” When in doubt, ask people! It is very easy to fall into the trap of focusing on irrelevant or imagined problems, especially as external coach on a part-time basis.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

Don’t look for perfect solutions:

Don’t look for perfect solutions. It’s probably not worth the wait, and you’ll probably get it wrong anyway. Instead, look for small incremental improvements, and think of them as experiments. An experiment may or may not lead to the intended improvement, but it should always generate insights that can be used to design the next experiment. A great process isn’t designed; it is evolved. So, the important thing isn’t your process; the important thing is your process for improving your process.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

Tools:

Use Google Drawing to create online Kanban;
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

Cause-effect diagrams are a simple and pragmatic way of doing root-cause analysis. I’ve been using these diagrams for years to help organizations understand and solve all kinds of problems, technical as well as organizational.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

The benefits for Cause-effect diagrams:

1.Create a common understanding: Team-based problem solving is extremely effective but requires a common understanding of the issue. Cause-effect diagrams are a very practical collaboration technique.

2.Identify how problems affect the business: Knowledge of this enables people to focus on the most important problems first and make informed decisions.

3.Find root causes: This helps maximize the effect of your changes.
Eliminate vicious cycles (negative reinforcing loops): Break vicious cycles or turn them into positive reinforcing loops (good stuff leading to more good stuff, instead of bad stuff leading to more bad stuff).
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

The basic process:

1.Select a problem—anything that’s bothering you—and write it down.

2.Trace “upward” to figure out the business consequences, the “visible damage” that your problem is causing.

3.Trace “downward” to find the root cause (or causes). Identify and highlight vicious cycles (circular paths). Iterate these steps a few times to refine and clarify your diagram. Decide which root causes to address and how (that is, which countermeasures to implement).

---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

How to trace Real time & historical trends:

The Kanban board shows us bottlenecks in real time, which is great, but it does not show us historical trends. Cumulative flow diagrams are a popular tool in Kanban circles to visualize bottlenecks over time.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

When WIP(work in progress) limit is full:("Stop" will make the team more self-organizing):

One way to help test is for more people to do manual testing and bug fixing. Another way is to develop more automated tests and improve the test infrastructure. Those things are represented as tech stories. That’s why we don’t include tech stories in the WIP limit, because we want to encourage team members to work on tech stories when the WIP limit is full.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

During some periods the teams focused almost entirely on test automation, with only green-dotted cards on the project board. This is a great example of how Kanban boards with WIP limits facilitate self-organization and bottleneck alleviation.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

Why do WIP(work in progress) limit or not:

features[yes], tech stories[no], bugs[no].
The reason tech stories aren’t included in the WIP limit is because, well, let me try to explain.... One of the reasons for having WIP limits is to avoid overloading a downstream process. Building a new feature will certainly add work to test, so if we build features too fast, we will overload test. Tech stories, however, often have the opposite effect: they offload the downstream bottleneck. Many of our tech stories are related to test automation and infrastructure improvements, both of which improve quality and make life easier for testers.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

the essence of WIP limits: focus on finishing things rather than starting things!
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

The process improvement proposal and its purpose:

The process improvement proposal template forces you to think about why you want to make this change. “What problem are you trying to solve?” “Who is affected by this change?” “What steps are involved in executing this change?” The answers to these questions are very helpful when determining the value vs. the cost of doing this change.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

The purpose of introducing this little template was to allow us to limit the amount of change. So if we get four proposals, we might implement only one or two of them, even if all four of the proposals were great. It is very difficult not to implement a great process improvement proposal, but we realized that we have to limit the amount of simultaneous process improvement initiatives. If we don’t, we get too much confusion, which offsets the benefit of the process improvement.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

How to use Gut feel or hard metrics:

Any Lean enthusiasts of the more fundamentalist type reading this book might point an accusing finger now and say, “Yuck, that’s all subjective, touchy-feely stuff! Process improvement must be driven by quantitative, objective data and reports!” Well, I don’t agree. Complex product development of this sort is a creative process done by creative people, and the most important currency is motivation. In this context, gut feel beats hard metrics. If something feels like an important problem, it most likely is an important problem, whether or not we have metrics to prove it. And the nice thing about gut feel is that it often is a leading indicator of a problem that’s about to occur, while hard metrics often show a problem only after it has occurred. So yes, we use hard metrics (see Chapter 12, ​Capturing and Using Process Metrics​), and sometimes those metrics will trigger the necessary gut-feel realization that there is a problem (the proverbial “Oh shit!” moment). But we use metrics primarily to support process improvement, not to drive it.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

Process improvement workshop's basic structure:

Each process improvement workshop follows the same basic structure, which roughly corresponds to the meeting structure defined in Diana Larsen and Esther Derby’s book Agile Retrospectives: Making Good Teams Great [DL06]. At a high level, here’s the process:1.Set the stage: Open up the meeting and set the theme and focus. 2.Gather data: Go through what has happened since the last meeting, including victories and pain points. If we have a theme, go through concrete data relevant to that theme. 3.Generate insights: Discuss the data and what it means to us, focus on the most important pain points, and identify concrete options to alleviate them. 4.Decide what to do: Make decisions about which changes to implement. 5. Close the meeting: Decide who is going to do what and what will happen by next meeting.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

Why Do not Stop meeting:

Having the process improvement workshop every week was rather intense, though; we barely had time to execute the changes from one meeting to the next. The positive side was that the frequent workshops drove us to implement change quickly, because it is embarrassing to sit down at the next process improvement workshop and say, “Well, dang, we never actually got around to implementing that change.” Also, because the workshops were held every week, we had to keep them short and focused, which forced us to prioritize only the most important changes and take small steps in our change process.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

We need Coach:

Bringing in a team-external facilitator from time to time is usually a good idea because that gives the team some variation in how the retrospective is run and provides the team lead with insights about different ways to run retrospectives. And it allows the team lead to participate fully instead of facilitating. One simple and cheap way to get an external facilitator is for team lead A to facilitate the retrospective of team B, and vice versa.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

A good process was discovered rather than designed：

Our process was discovered rather than designed. The first thing I did was put in place a process improvement engine. Well, I didn’t use those words, but that is in effect what it was. The basic formula is as follows: Clarity: Have physical boards in prominent locations that show everyone what is going on. And have a clear goal for the delivery that everyone can understand. Communication: Do process improvement workshops on a regular basis (weekly or biweekly), both locally within each team and at the cross-team level. Data: Track some simple metrics that show us whether our process is improving. We measure velocity and cycle time (see Chapter 12, ​Capturing and Using Process Metrics​). The strategy is pretty simple: it’s based on the assumption that people inherently want to succeed with their projects and that people inherently like to solve problems and improve their way of working. So, create an environment that enables and encourages these behaviors. If everyone knows where we are going and where we are right now and if we have the right communication forums in place, then chances are people will self-organize to move in the right direction and continuously figure out ways of getting there faster.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

Why limit the Number of Bugs in the Bug Tracker to 30:

Before we moved to Kanban, we had hundreds of issues in the bug tracker. Now we have a hard limit of thirty. If a bug is found, the first question is “Is this a blocker?” Blocker in this case means “The feature won’t be releasable with this bug” or “This bug is more important to fix than building additional features.” Write it on a pink sticky note and fix it now, like any other impediment. Don’t put it in a queue. If the bug is not a blocker, however, we have a decision to make: “Is this bug more important than any of the other top thirty bugs in the bug tracker?” If so, then that other bug is removed from the top thirty list to make room for this one. If not, then we ignore the new bug. That way, the bug tracker continuously keeps us focused on the most important bugs and doesn’t become an administrative burden.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.

Bugs in your product are a symptom of bugs in your process:

If you do cause-effect analysis on your bugs, you’ll find that bugs aren’t really a problem; they are a symptom. Bugs in your product are a symptom of bugs in your process. If you focus on fixing your process, you’ll dramatically reduce the number of new bugs in your product. It’s just like if you focus on fire prevention, you’ll reduce the need for fire fighting.
---Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban . Pragmatic Bookshelf. Kindle Edition.