Learning Agile

I have to admit, I have a little quest going on. To read all books that come up on the first page (12 items) when searching for the word ”Kanban” in Books on Amazon.com (sorted by relevance). It’s a fun quest, but I don’t know if I will ever complete it though, since the search result keeps on changing over time 🙂 Anyhow, in that quest, I have read ”Learning Agile” by Andrew Stellman and Jennifer Greene. The book was released in November 2014 and the sub title is ”Understanding Scrum, XP, Lean, and Kanban”.



The book has ten chapters and they are:

  1. Learning Agile
  2. Understanding Agile Values
  3. The Agile Principles
  4. Scrum and Self-Organizing Teams
  5. Scrum Planning and Collective Management
  6. XP and Embracing Change
  7. XP, Simplicity, and Incremental Design
  8. Lean, Eliminating Waste, and Seeing the Whole
  9. Kanban, Flow, and Constantly Improving
  10. The Agile Coach.

The first chapter sets the agenda for the book by presenting what Agile is (”Agile is a set of methods and methodologies that help your team to think more effectively, work more efficiently, and make better decisions”) and how it is structured.

In the second chapter the Manifesto for Agile Software Development is introduced. This and all the following chapters are structured in a very pedagogical way. The subjects are first described in ”plain text”, broad up again in a narrative (fictive stories), summed up as key points and finished off as a FAQ (Frequently Asked Questions). This redundancy is intentional according to the authors ”we do it to help you get that ’aha’ moment”. For me, that have read a few other books on Agile, this gets a little boring and time consuming with all the repetition. The book spans 420 pages which could have, in my option, been less to be a truly ”agile” book.

Moving on, the third chapter explains The 12 Principles of Agile Software in greater detail. This is a good chapter to get a deeper understanding of the Agile principles!

Forth chapter starts off with a good slogan from the board game Othello: ”A minute to learn, a lifetime to master”. This can be applied to all Agile methodologies described in this book (well, maybe not just a minute to learn, but they are all very simple to get started with but needs a lot of practice to ”master”). If you want to know the basics of Scrum, you can download the official Scrum Guide. More in this chapter are the five Scrum values:

  • Courage
  • Commitment
  • Respect
  • Focus
  • Openness.

Chapter 5 completes Scrum, it has a reference to a survey (on page 142) that states that 64% of the features in software is never used! It can be due to something called gold-plating. Developers that, with the best of intent, throw in extra functionality that never has been requested.

Chapter 6 & 7 covers XP (eXtreme Programming) that has similarities with Scrum. A personal takeaway from this section (though I’m not programming anymore) was the section about code smells or anti patterns (”a pattern of behavior that a team exhibits that cause problems with the project”). Those being listed are:

  • Shotgun surgery – A small change to one part of the code requires another change in another part of the code than in turn requires yet another change somewhere else in the code and so on.
  • Half-baked code – An object that needs to initialize other (irrelevant) objects as well to be used.
  • Very large classes – Hard to read and maintain.
  • Duplicated code – Identical (or almost identical) blocks of code that does the same thing.
  • Spaghetti code – Code with complex and tangled structure.
  • Lasagna code – Too many layers.
  • Hook – A hook added for future use (but then never used).
  • Edge case – Code that handles an edge case that seldom (never) will happen but makes the ”normal flow” much more complex to understand and maintain.

”A system that’s designed to immediately report a failure as soon as it happens is called a fast-fail system” – Andrew Stellman & Jennifer Greene

I would also like to list the XP practices:

  • Pair programming
  • Continuous integration
  • Energized work
  • Ten-minute build
  • Incremental design
  • Whole team
  • Refactoring
  • Sit together
  • Test-driven development.

Chapter 8 talks about Lean that is a mindset with its own values and principles. The values are:

  • Eliminate waste
  • Amplify learning
  • Decide as late as possible
  • Deliver as fast as possible
  • Empower the team
  • Build integrity in
  • See the whole.

Reaching the end here, chapter 9 is about Kanban, flow and constantly improving (kaizen). Not so much new stuff for me here, once again WIP (Work in Process) limits are enforced and described as the ”secret sauce” behind Kanban.

”Kanban is about helping a team improve the way that they build software” – Andrew Stellman & Jennifer Greene

Final chapter tells you about the agile coach that helps the team adopt agile. The team needs an agile mindset to be successful with an agile methodology.


If your are new to Agile, and have a lot of time to read, I can recommend this book to get more knowledge about Scrum, XP, Lean and Kanban. If you only want to know about a specific method, or have short of time, there are other more suitable books around.

All the best,
 Tomas from TheAgileist

Tillsammans / Together

This is the first time I do a review on a book written in Swedish, my native language. I realize that many of you will never get a opportunity to read the book, but according to my blog statistics Sweden is in third place when it comes to visitors (after USA and UK). The book is ”Tillsammans” (”Together”) with the sub title ”Så skapar du flyt och egenmakt med agile och lean” written by Peter Antman (@peterantman on Twitter).



According to the table of content the book has three main parts/chapters and they are:

  • ”Flyt och kunskap med agile och lean” (”Flow and knowledge with agile and lean”)
  • ”Team – en agile organism” (”Team – an agile organism”)
  • ”När chefen inte längre leder och fördelar arbetet” (”When the manager is no longer acting in ’command & control’-mode”)

For all of you to understand I will stick to English from now on (i.e., I’ve done my own translation from Swedish to English, any mistakes during that process is mine only). Instead of a formal review that I usually do, I will give you five short stories/lists that are presented in the book. I hope you enjoy them.

”Bread maker”
This history from the 1980s tells that the management at Matsushita (now Panasonic, a Japanese multinational electronics corporation – my comment) had formulated an idea of a kitchen appliance that could bake bread. The vision was that you should be able to get up in the morning and smell fresh bread without too much work. The engineers were not able to complete the bread maker, no matter how much work they put in. The bread never turned out good enough. Finally someone asked: ”Can we actually bake bread?”. The engineers had to leave the drawing board and go to practice at the best bakery in Tokyo. When they returned, they rather quickly solved the problems and got the bread maker to work.

My comment: This story tells me that you really need to know your product, and of course the customers that shall use it.

”Broken windows”
The broken window theory was introduced in 1982 by two social scientists. Most of us are familiar with it: Someone breaks a window. If it’s quickly fixed, broken windows will happen but it is not the normal state. But if it’s not fixed? Then people stop caring and persons that normally behave is more likely to also smash a window.

My comment: What can we learn from this? My takeaway is that we alway should strive for highest quality. That we have 100% pass on our tests. If it drops lower, even with ”known errors”, we start to care less.

”Go green”
During several years the metaphor ”go green” was very important for Peter Antman’s working life. Put in context it was filled with purpose; focus on quality, tests, visual feedback and hard work. In the working group the metaphor became part of their culture, and affected their mental picture of the reality and their acting within it.

My comment: ”Go green” relates back to the previous story, where ”green” means pass on all tests. ”Green” shall be the normal state. If an error is introduced, i.e., the tests will go ”red”, it shall be fixed as soon as possible to go back to the normal ”green” state. Hard work is required to get this up and running, so it has to be in the mindset of the teams.

”Grow an agile culture – With phrases”
For Peter Antman and his teams the essence of scrum, agile and lean could be expressed in a few key phrases, they were:

  • Last responsible moment
  • One-piece-flow
  • Adapt to capacity
  • Cult of quality
  • Stop-the-line
  • Art of the possible
  • Always releasable
  • Inspect & Adapt
  • Take it to the team.

My comment: All things on the list above is explained in more detail in the book.

”Agile mindset”
The last list from the book that I would like to share with you holds the foundation of agile thinking, with respect for human beings and our capability to do good work when we are not limited by things out of our control. We emphasize:

  • Self-organizing teams are our lowest organizational unit.
  • People are driven by intrinsic motivation and we need to let it free.
  • We focus on value and to only do things when they are needed.
  • It’s pointless to have detailed long term plans since the reality will always change.
  • We have short feedback loops since we constantly need to learn new things.
  • It’s the system we change when we try to correct things that are not working.

My comment: I can only agree with this list!


I can recommend this book if you want to read about Lean & Agile in the Swedish language. There’s not so many books available about that in Swedish, hopefully this one can increase the understanding beyond the IT department in companies throughout Sweden and the other Nordic countries.

All the best,
 Tomas from TheAgileist

The Essence of Flow

Summertime is here, and for many of us that means vacation. During the vacation period I can take time to do more reading than I normally do. Do you want to do some more reading as well? Maybe I can interest you in my article ”The Essence of Flow”, that has been published on InfoQ.


(Picture taken from http://www.infoq.com)

Here is a short description:

”How do you get good flow? A common scenario in a software company is that too much is going on at once. We need a shift in mindset, to go from focus on resource efficiency to focus on flow efficiency.”

You can read the full article here.

All the best,
 Tomas from TheAgileist

WIP limits

In a previous blog post I mentioned that we are in a transition from Scrum to Kanban. Or to be more precise, we have been using Kanban for almost a year, but some of the ”Scrum thinking” is still present in our teams. This doesn’t necessarily have to be a bad thing, but one thing we are really struggling with, is putting limits on WIP (work in process).


Can you see, there is something missing in the picture above?

Yes, you are correct, there are no explicit WIP limits present. Putting limits on work in process is essential to achieve flow through your work process and it also ”high-lights” problems that are candidates to be fixed in the name of kaizen (continuous improvements to your process). The WIP limits were there initially, but the teams didn’t see ”the meaning” with them, and removed them (after all, the teams are autonomous). In trying to put the WIP limit ”back” on the Kanban boards, I seek help from some fellows in the Kanban community. Their answers to my question ”How do you get the teams to use WIP limits?” are found below.

Mike Burrows

Mike seems to be a really nice guy and he is also the author of ”Kanban from the Inside”, find my review of this book here.

I tend to approach the question of limits rather indirectly, and (as you’ll know from my book) I’m interested in more than just column limits, being open to limiting WIP in multiple, cross-cutting ways. Tips?

1) I tend to start from the right hand side of the board, looking at the flow of work through (say) validation, deployment, acceptance etc. Not much point in optimizing the flow through development if the work is only going to pile up somewhere else.

2) I’m careful not to celebrate partially-done work (eg in status reports) and to report cycle times that go beyond development.

3) I like to organize work horizontally also and to explore the allocation of effort across those. In my current situation I’m seeing an interesting difference in performance between two workstreams that could be explained by a lack of discipline with regard to WIP.

Marcus Hammarberg

Marcus has helped us a lot. We are even reading the book that he co-authored, ”Kanban in Action”, as a book circle at work. I’ve also made a review of this book.

Hmm, I’ve seen this myself also. I think the most important thing is not to enforce anything: ”DO LIKE THIS! NOW!! This will only lead to alienation and the team will not feel that they ’own’ their Kanban board.

Ask the team – this is simplest, and hardest way; why is it that we always have more things to do than our WIP limit states? Is it too low? Why? I think it is also important to understand that WIP limits is not a law or a ”correct number”. It is a tool to find improvements. Breaching a WIP limit shall trigger a discussion; ”fine we are beaching the WIP limit now, but we do it on purpose”. Some teams that I heard about had a mini-retrospective each time it happened.


So how did we actually solve the problem? I leave you with a ”cliff hanger” for next week, when I present our approach in limiting WIP 🙂

All the best,
 Tomas from TheAgileist

Control room

We have a ”control room” where the teams perform all of their important meetings, like the daily standup and retrospectives (we call them Kaizen-meetings). This is how the room looks like.


I’ve put in some circles in the picture to be able to better describe to you what you see. Here it goes:

  • The green circle to the right – This is a priority pyramid that we use for visualizing our backlog. You can read more about how that is done here.
  • The yellow circles – Team kanban boards. We are in a transition from Scrum to Kanban so the boards are not perfect yet (to my opinion), but we are slowly getting there.
  • The red circle to the left – This is the Kaizen-board. Here we track long term continuous improvements with a simple ”To do, Doing, Done”-board. All stickies get a date on them when they enter the board, to be able to spot ”oldies”.
  • The white/grey circle to the right – This is a empty whiteboard. We use it to write down quick ideas on meetings etc.
  • The blue circle in the middle of the room – This is our gem! A 4K TV that currently shows status from our automated tests and our bug tracking system. Here we can always see the current situation. Basically green means ”good” and normal, and everything else is deviances that we need to act upon. All information is present to be able to build a SW-GPS for navigating our projects. The graphs are made with gnuplot. An extra HDMI cable is connected to the TV to be able to plugin a laptop for quick demos and other discussions.

In total we have eight whiteboards in the room (not all of them are shown in the picture). Also present in the room is a sofa (for coziness), chairs and and a small table to place a laptop on. Meetings in the ”control room” tends to be more informal than in a ordinary meeting room with a projector.

What does your ”control room” look like?

All the best,
 Tomas from TheAgileist

Lean and Agile in three pictures

Recently I attended a ”Lean Coffee”-meeting hosted by the magnificent @hakanforss. At the meeting there was a person that described their situation with one team of four developers serving the needs from four different product owners. She explained the situation as scattered (”spretig” in Swedish). This made me reflect of our situation that is similar and how Lean and Agile fits into that picture. It’s also said that a picture says more than a thousand words. So here is a blog post ”worth” more than reading 3000 words 🙂

Process with bottlenecks


This a generic picture describing a process. Requests come in to one end of the process and deliveries go out of the outer. Inside the process a number of value adding steps take place. If the process doesn’t add any value, these is no reason for its existence. All processes have limitations in the form of bottlenecks. The ”most narrow” bottleneck determines the throughput of the whole process. One key concept in Lean is kaizen that means you should work with continuous improvements to your process. When one bottleneck is ”fixed” another will be the ”most narrow”, hence you need to continue your kaizen efforts that never ends. The process is the most valuable thing a company have, more valuable than its products and services (that will come and go over time). Improvements to your process hopefully stay forever!

”What we do to the process, echoes into eternity” – LeanGladiator

Sadly, my experiences from the software development industry is that we care more of what we do (our products and services that are somewhat volatile), then how we do it (our process that will eventually define company success in the long run). Hopefully this can change to the latter in the software industry.

Common situation


This is the situation that I think we share with a lot of other companies. Focus is scattered ”all over the place” (as the Swedish prince Daniel said) on a number of different products and services that the company provides. We tend to do a little bit of this, and a little bit of that, not to ”loose out” on something that could be ”the big thing”. Since we are doing many things at once we become too ”thin” and all the context switching between tasks makes us produce less and less actual value. Not been able to predict when things ”can be done”, we have to start things earlier to increase the work in process even more. You end up in a vicious circle…

In fact, the lack of focus makes it more likely to be unsuccessful. In the ”Steve Jobs”-biography written by Walter Isaacson there is a section that tells about an offsite meeting with all executives at Apple. If I remember correctly, the executives had like 100 different ideas that they thought would be ”the next big thing” and they wanted the company to support and finance. Comparing the ideas against each other and discussing them during days of meetings (I can imagine a lot of egos rubbing against each other) they finally boiled it down to three. The benefits was that the whole company now was behind those three ideas, and the focus they got was tremendous.

What we want to achieve


This is what we want to achieve:

  • Streamline our business to focus on fewer things (i.e., have less work in progress) and thereby increase throughput and shorten lead times.
  • Kaizen, continuous improvement to the process to handle the bottlenecks.

We want to deliver smaller increments (time wize) that faster bring continuous value to our customers.


How do we do it? For many organizations a shift in mindset is needed. Today we tend to focus on high resource efficiency (people to be busy at all times). Opposite to high resource efficiency we have high flow efficiency (work moves fast through the process). What we must do is to temporarily ease the focus on resource efficiency, get ”slack” (resources becomes available) so that flow is prioritized and then improve your process (kaizen) so that resources can work more efficient.

My favorite presentation on this topic is ”The Busy Bee Paradox” by Håkan Forss.

All the best,
 Tomas from TheAgileist

Lean Change Management

The Christmas holiday is for me time to read and reflect. This year was no exception. My Agile endeavor has continued during 2014, but it feels like we have reached a plateau. Agile acceptance and adaptation are high within the IT department, the challenge now is the rest of the organization. That must change during 2015! 

”The only thing constant is change” – Heraclitus

If change is a natural part of life, how come it’s so hard and sometimes painful? To find out, I did my normal routine and started to search for books on the topic. Pretty soon I found ”Lean Change Management” by Jason Little. The subtitle of the book is ”Innovative practices for managing organizational change” and it was released 3 October 2014.


Lean Change Management Cycle

The book introduces something called the Lean Change Management Cycle that consists of:

  • Insights
  • Options
  • Experiments (with the sub-cycle below):
    – Prepare
    – Introduce
    – Review

This non-linear, feedback-driven model for managing change is explained in more detail throughout the book. Insights is the understanding of the current state in the organization. Options have a cost, value and impact. They include one or more hypotheses and expected benefits. Hypotheses are turned into Experiments. Prepare is the planning stage of the experiment. Introduce is where you put the experiment into real action, and Review gathers the outcome.


Without a framework or some sort of mental model, change management can be very hard. The book presents two frameworks.

Kotter’s 8-step Change model

This was introduced by Dr. John Cotter and holds the following steps:

  1. Create Urgency
  2. Form a Powerful Coalition
  3. Create a Vision for the Change
  4. Communicate the Vision
  5. Remove Obstacles
  6. Create Short Term Wins
  7. Build on the Change
  8. Anchor the Change in Corporate Culture
McKinsey 7S Framework

Tom Peters and Bob Waterman created the 7S Framework in the 1980s.

  • Hard factors
    – Strategy
    – Structure
    – Systems
  • Soft factors
    – Shared values
    – Skills
    – Style
    – Staff

Other valuable information in the book

Blast radius is a model for understanding the consequences of a change before it is introduced. Hypothesis creation template is a you can imagine a valuable help when you create your hypotheses. As you might have understood by now I’m a big fan of visualization and this book holds two more good examples of that:

  • One-Page Change Plan
  • Strategic Change Canvas


First I would like to quote the author:

”My goal with this book is to help other change agents find a more people-centric, and feedback-driven approach to change”.

This book gives great ”tools and thinking” for change.  I believe that I now have everything needed to proceed with the necessary changes in 2015. If you want to know more, you can visit the Lean Change Management website. I also found the following short introduction on YouTube.

I’m writing a book

I like books a lot! In fact I love books so much that I’m trying to write one myself 🙂 I’ve been doing this for a while now,  and I have the text for about 2/3 of it. During the writing I’ve had the pleasure of receiving valuable feedback from a small group of proofreaders. This group of people have really helped me and pushed me forward in this project! Without them I would never have reached this far. Thank you (you know who you are)!

However, there is still a long way to go before the finish line arrives. In this blog post I will tell you a little more about the intended content of the book, and kindly ask for your input to it in the form of stories.


(This is just a working title, it will likely change)


The book has structured itself into three sections:

  • Part I – Management
  • Part II – Methods
  • Part III – Agile anecdotes

This first part is all about management, each chapter focus on a distinct layer or aspect. You can see it as my seven P’s of management:

  • Philosophy
  • Priority
  • Personal
  • People
  • Projects
  • Products
  • Pyramids (organization)

Part two holds explanations and my insights from Agile methods including Kanban and Scrum. The last part will hold real-life stories and examples form the world of Agile. The plan is to include both successes and failures. Why include failures? Because you learn so much more from them! And if you can read about other people’s failures, you can hopefully avoid doing them yourself.

Stories needed

I have pretty good control over the first two parts. But for the third part, Agile anecdotes, I could really use your help! Do you have a good agile story that you would like to share? Contact me via Twitter (PM) and we can discuss, see the About page for more details. As said, it can both by an Agile success story when everything went hunky dory, or a failure (completed with learnings if any where made).

When will the book be done?

When the book will be completed I can’t really say. I’m working with it in my spare time (having a full time job and a family makes it somewhat hard to control ”my own time”). But I can promise that you guys will be the first ones to know about the progress!

Relay baton – Example of one piece flow

4 x 100 Metres Relay

I’m a big fan of sports, athletics included. The 4 x 100 metres relay usually are a very interesting and exiting event at the World championships or in the Olympics.


The current world records (for men):

  • 400 Metres: 43.18 seconds, by Michael Johnson from Sevilla (26 Aug 1999)
  • 4 x 100 Metres Relay: 36.84 seconds, by Jamaica from London (11 Aug 2012)

The relay time by the Jamaican team is 15% faster, but Michael Johnson is one of the best athletes ever lived. How can this be? There are two reasons:

  1. Each individual in the Jamaican team could run at maximum capacity (400 Metres is not long, but it is not possible to run with the same speed as for 100 Metres)
  2. No loss in speed in the exchanges of the relay baton

So in this case 1+1+1+1 don’t become 4, it becomes something even more! How can we translate this to a Lean/Agile context?

One piece continuous flow

In Lean the true ”Nirvana” is one piece continous flow. Where one piece is flowing between the value adding steps in the work process without any waiting time or stocks in between. Like the relay baton! Which of the reasons above can we start to work with? Of course you can (and should) hire the most skilled people and make them perform at their best, but the most interesting thing are the exchanges between the runners. Most time can be won here. In fact a country with less skilled runners can compete and do really well in the Olympics or World Championships if they practice their exchanges to perfection. Usually one of the favorite countries will fail in an exchange and thus be disqualified.

In your organization, do you practice on the exchanges between the steps in your process? Or is your focus only within the process steps?

Let’s say that the ”runners” in the 4 x 100 Metres Relay are represented by:

  • Analyst
  • Developer
  • QA
  • Deployer

How is the exchange of the requirement (= the relay baton) happening between the analyst and the developer? Do the developer ”get up to speed” on the requirement before it is handed over? Do the analyst ”run along” together with the developer to make sure that nothing is lost in the exchange (to make sure that the developer fully understand the requirement)? My guess is that in most of the cases the requirement is queued up in between (for example as a state change in a tracking system with a shift in responsibility).


What is there to learn from this example? First of all we need to practice on the exchanges to make them as smooth as possible. This can’t be done when we are ”in competition mode” (i.e. doing our daily work delivering to our customers). We need to take a step back, reflect on our behavior, and then make changes (to get continuous improvements). Second is the focus and information sharing if you like. All runners are fully aware of what to do and when to do it. They have all the information needed as they can oversee the whole race.

I’ve made a presentation on Slideshare that you can use for inspiration and to generate ”buzz” around this topic.

Dived into Deming

Recently I dived into Deming. If you don’t know who W. Edwards Deming (1900 – 1993) was, he is claimed to be ”the father of quality” and also between the lines seen as ”the man who taught the Japanese to do lean” (at least that is my interpretation). I’ve read the book ”The essential Deming” by Joyce Nilsson Orsini, to continue on my journey to learn more about the ”building blocks” that lean and agile resides on.


The book itself was not so good I must say, it was a impulse buy without any deep research done before the purchase. The book is filled with articles, papers, lectures and notes touching on a wide range of topics. The material has not been edited, so it’s a fair amount of repetition. If Deming had lived today, I guess this book would have been a collection of his blog posts 🙂

Nevertheless, Deming was a statistician and had a lot of clever thoughts on how to use statistical methods for quality control. He also added insights in the area of leadership. ”The essential Deming” holds content about:

  • How poor management infects an entire organization
  • The critical importance of management on producing quality products and services
  • Improving management in any company
  • The effective management of people – the manager’s single most important task
  • How to educate workers into critical thinkers
  • Ways to preserve statistical integrity while dealing with real-world problems

So if you want to know more about Deming, a better starting point may be ”The W. Edwards Deming institute”. Here you will find (amongst others) Deming’s fourteen points for management (also present in the book). To save you some clicking I’ve included them below:

  1. Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs.
  2. Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change.
  3. Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.
  4. End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust.
  5. Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs.
  6. Institute training on the job.
  7. Institute leadership (see Point 12). The aim of supervision should be to help people and machines and gadgets to do a better job. Supervision of management is in need of overhaul, as well as supervision of production workers.
  8. Drive out fear, so that everyone may work effectively for the company.
  9. Break down barriers between departments. People in research, design, sales, and production must work as a team, to foresee problems of production and in use that may be encountered with the product or service.
  10. Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity. Such exhortations only create adversarial relationships, as the bulk of the causes of low quality and low productivity belong to the system and thus lie beyond the power of the work force.
    – Eliminate work standards (quotas) on the factory floor. Substitute leadership.
    – Eliminate management by objective. Eliminate management by numbers, numerical goals. Substitute leadership.
  11. Remove barriers that rob the hourly worker of his right to pride of workmanship. The responsibility of supervisors must be changed from sheer numbers to quality.
  12. Remove barriers that rob people in management and in engineering of their right to pride of workmanship. This means, inter alia, abolishment of the annual or merit rating and of management by objective.
  13. Institute a vigorous program of education and self-improvement.
  14. Put everybody in the company to work to accomplish the transformation. The transformation is everybody’s job.

(The list above taken from ”The Fourteen Points For The Transformation Of Management”)