Continuous Improvement

“We’ve completed our lean adoption.” “We’ve completed our LeSS adoption.” Does that need explaining? Probably not.

So in lean thinking and in LeSS, there’s only continuous improvement towards perfection. That’s a radically different mindset and behavior than the punctuated, big-batch, controlled-change traditional model. How does it feel different? For example:

• You’ve eliminated the corrosive HR policy of stacked ranking of individuals in semi-annual performance appraisals? Great. Can you abolish performance appraisals next?
• You’ve eliminated the project/program manager positions in the product group? Great. Can you eliminate the Project Management Office next?
• You’ve reduced your total build time—including all tests—from nine hours to two? Great. Can you strive for in one second?

As these examples show, the boundary of improvement and change experiments is not limited to the Teams. Evolutionary continuous improvement in LeSS expands to the overall system, eroding all the organizational impediments to a perfect value stream, month after month after month.

And so there’s no change initiative, no change group, no change managers. In LeSS, change is the status quo.

Create a clear direction

Organizations are wonderfully complex systems in which it’s impossible to control everything or to know everything.

Everyone makes small decisions and the organizational behavior emerges from these. People make decisions based on their experiences, goals, principles, and values. When decisions are misaligned then well-intended people scurry in different directions, causing an organizational deadlock or gridlock. When these decisions are aligned, energy gets unleashed and things start moving and improving.

Clarifying and reaching agreement on a clear direction does wonders in aligning daily decisions. The successful product groups that we have worked with had a perfection vision—an unattainable goal where each step towards the goal is an improvement. How is it used? People discuss and evaluate decisions based on whether it brings them closer to the perfection vision.

For example, the classic lean perfection vision is Toyota’s just-in-time system—every time a customer buys one car than exactly one car is produced just in time. This perfection vision lead to the ideal of “one piece flow” in which the production system is set up to handle small batches of work, ideally batches of size one. This ideal will probably never be achieved but it has guided Toyota’s continuous improvement of their production system for decades.

The perfection vision for LeSS that we sometimes use is:

Create the organizational ability to respond to changes by being able to deliver or change direction at any time without additional cost.

Managers—together with the whole product group—have to establish clear directions that guide decision making. This is usually done by informal discussions and workshops, leading to some guiding vision and principles. Discussing is important work, but words float away. So people also want to write a vision to help get everyone on the same page, literally.

Do experiments

The mandate to improve is a lofty goal, and can scare off people from experimenting. What if the improvement…doesn’t? Kaneyoshi Kusunoki, a student of Taiichi Ohno and executive vice-president at Toyota, said about kaizen and management support:

A defining characteristic of the corporate culture at Toyota is that managers don’t scold you for taking initiative, for taking a chance and screwing up. Rather, they’ll scold you for not trying something new, for not taking a chance. Leaders aren’t there to judge. They’re there to encourage people. That’s what I’ve always tried to do. Trial and error is what it’s all about! [SF09]

Developing problem-solving skills through many experiments is cen- tral to lean thinking. The only bad experiment is the one not tried!

The real measure of success is the number of experiments that can be crowded into 24 hours.—Thomas Edison

Focus on problems, not tools.

“We’re starting to do agile. What tool should we buy for agile project management?” This is a question we hear often; our suggestion is always the same—and we mean this even for the very large-scale cases: “Avoid any special agile tools until several years after starting the adoption. Keep it simple. Use the wall or, in the most complex solution, a simple spreadsheet and wiki.” Why?

Problems from system weakness cannot be solved with processes or tools. Worse, attempting to quick fix systemic problems with tools creates an illusion of control or change but no real improvement… Executive: “What is the agile transformation progress?” Agile-change manager: “We have installed and three of the projects are using it. Come take a look at the burndown charts…”

Avoid the lure of “tools to do agile management” for at least several years after starting to adopt agile or lean development, so that people’s focus can be where it belongs: on the system. By removing all crutches and quick-fix illusory solutions, people may—just possibly—be prompted to squarely face the important but hard issues: competent individuals, interactions, organizational design, the illusion of command-and-control, and so on.

If you automate a mess, you will get an automated mess.—anon

We are not suggesting agile-management tools are poor—or good. This is about focusing on important things first and avoiding the dysfunctions that accompany management-reporting tools.

After years? Prefer free tools so that the cost of experimenting is low and there are fewer barriers to discarding tools. We have heard the following several times: “We can’t stop using tool (or process) X because we have invested so much in it.”

We have seen thousand-person multisite development groups successfully apply large-scale Scrum with some Excel spreadsheets for their Product Backlog and Release Burndown chart. Indeed, they are almost certainly better off for doing so; it keeps their attention more on fixing the system.

The agile-management tools we have seen emphasize tracking and displaying individual and team tasks and Sprint Backlogs to managers—almost the antithesis of these principles. In Scrum, the team’s tasks (the Sprint Backlog) are created by the team to help them self- manage, not to report their status to others. As the well-known team researcher, Richard Hackman, explains, “In self-managing teams, the responsibility of tracking the progress is delegated towards the team” [Hackman02]. Since the team is self-managing, they are not to be tracked or monitored; such tools are a slippery slope that may reinforce a traditional command-and-control culture rather than a culture of self-management.

Computerized management-reporting tools can also take people away from gemba and the practice of Go See. Lean thinking emphasizes—to understand what is really happening—go with your feet and see with your eyes at the real place of work, help solve problems there, and build relationships with the workers there.

Finally, these tools are optimized for reporting—not for success, improvement, or a better flow of value. What meaningful problem do they solve?