Psychology of continuous improvement

Abanico en el mar by Ollui Samall Zeld / CC BY 2.0

I am an engineer! We engineers love well-crafted solutions.

Most of us studied Operations Research: we are excited by finding the optimal solution to problems and we like to fix all at once and even design future-proof solutions.

Sounds great to feel so powerful, doesn´t it?

But why is it so difficult to solve problems when they involve human beings?

Why can’t we make things happen even when the solution and the benefits appear so obvious even without analysis?

For instance:

Why can’t people simply quit smoking?

Why don’t most of us parents manage to get their teen-ager son to clean up his room?

Or why don’t we simply manage to increase the test automation level in our team?

Don´t they look like much simpler problems than many technical issues we face every day?

When it comes to challenges involving people, the issue is that human beings are not as nice creatures or as beautiful systems as the ones addressable by mathematical sciences, such as mathematical modeling, statistical analysis, or mathematical optimization.

God could have done a much better engineering work! Too many bugs J

• We are the least rational creature on earth: we are driven by emotions and gut feelings at least as much as by rationality, but feelings take the lead many times
• When the rational parts takes the lead instead, we usually got stuck in analysis paralysis
• We are reluctant to change: we like our current way of doing things
• We are programmed to save as much energy as possible: changing our routines  requires effort
• We are blinded by cognitive biases: we interpret the reality not for what it is, but by comparing it with the maps we have been creating in our brain since we were born
• We are addicted to the now and not very much used to accept delayed gratifications

So how can we ever achieve anything with such a flawed baseline system?

Imagine when you have multiple individuals together forming a team or even a bigger constellation: an organization!

Still surprised that up to 70% of all change initiatives fails? Can we ever succeed?

The good news is that human beings have also great properties and very effective strengths to use as leverages.

People are able to go straight to the point if they feel that the goal is clear and within reach and can be moved by incredibly powerful intrinsic motivators if they perceive the goal as meaningful and desirable.

All successful football coaches, for instance, know the trick very well.

How many times have you heard a journalist asking about possibilities of a team to win the championship?

And what was the answer from the coach every time?  “We want to play one match at a time”.

Good coaches do not ask their team to focus on the ultimate goal, but establish goals which are within immediate reach and clear criteria for their players to know when they have fulfilled those goals: by playing and possibly winning one match at a time, they get into the habit of winning and eventually win the championship.

Cheap and Dan Heath report in their book “Switch” that psychologist Karl Weick, in a paper called "Small Wins: Redefining the Scale of Social Problems," said: A small win reduces importance ('this is no big deal') , reduces demands ('that's all that needs to be done'), and raises perceived skill levels ('I can do at least that')." All three of these factors will tend to make change easier and more self-sustaining.

That´s why the Lean concept of Continuous Improvement (or Kaizen) is so effective and resonates so much with the way we as humans are wired: consistently taking baby steps in the right directions makes big goals appear more feasible to achieve.

However, being social systems classified as Complex Adaptive Systems, usually it´s not a smooth path of small wins.  More probably it will be about taking one step forward and two steps back, then three more steps forward and then five steps to the side. 

Nevertheless, by taking the vision of what we ultimately want to achieve well defined and in sight and, by coupling Hansei with Kaizen, meaning practicing Continuous Reflection at every step, we are much more well equipped  to achieve anything.

Instead, when a task is too big, the effect on human brain is overwhelmingly scary.

The book “Switch” reports also that Alcoholics Anonymous challenges recovering alcoholics to get through "one day at a time". To an alcoholic, going a lifetime without another drink sounds impossible, but going 24 hours sounds doable.

Small targets lead to small victories, and small victories can trigger a positive spiral of behavior.

Human brain has no trouble achieving baby steps, and as it does, something else happens. 

With each step, you feel less scared and less reluctant, because things are working. 

With each step, your brain starts feeling the change. 

A journey that probably started with anxiety and skepticism evolves slowly, toward a feeling of confidence and pride. 

And at the same time the change is happening, you as a person grow.

Scrum is Lean

I believe that Scrum is the most Lean among all Agile methods. 

scrum by David / CC BY 2.0

And not only because the word "scrum" was first used in 1986 by two professors at Hitotsubashi Univeristy in Japan, Hirotaka Takehuchi and Ikujiro Nonaka, in their famous HBR-published article             "The new new product development game".

In 2003 Mary and Tom Poppendieck coined the term Lean Software Development by publishing a book with the same name and proposing a translation of Lean thinking and practices to the software development domain. Lean Sofware development is based on 7 principles, which may be implemented by means of a number of tools:

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

If you want to know more, Mary and Tom published two more books:

• Implementing Lean Software Development: From Concept to Cash
• Leading Lean Software Development: Results Are not the Point

Now, even though Scrum and Lean Sofware development might seem to have formally nothing in common (different principles and different practices),  I will try to explain why and how I think the seven Lean SW Development principles are somehow mapped (or at least found) in Scrum.

1. Eliminate waste

The book reports seven wastes in SW development: partially done work, extra features, extra processes, task switching, waiting, motion, defects.

I think that the Scrum framework as such contributes to eliminate those sources of waste:

- the iteration-based approach, through the use of the Sprint Backlog, and the focus on doing whatever it takes to get things done and transform the items in the Sprint Backlog into a Potentially Shippable Product Increment, contributes the eliminate partially done work

- the Product Backlog handling, by building first the features which are more valuable for the customer and not spend too much time on the ones that are coming later, contributes to minimize partially done work and not needed features

- self-organized teams, who have the best knowledge, who are empowered to decide how to do the work and who continuously adjust their process through Sprint retrospectives, contributes to remove extra processes

- teams focusing on the Sprint goal minimize task switching

- cross-functional development teams working together side by side and daily with the Product Owner can remove waiting and handover of work items

- high skilled development teams, feeling responsibility for product quality, minimize defects

2. Amplify learning

Scrum is all about seeing SW development as a learning process. The Sprint will help create knowledge both on the product and on the process: the Sprint Review and the Sprint Retrospective are the main points in time where the knowledge on the product and the process are built respectively via feedback loops. The Daily Scrum also creates knowledge about how far the team is from the Sprint goal

Cross-functional teams learn continuously from each other skills and share knowledge inside the team and between different teams.

3. Decide as late as possible

A Product Backlog which is more fine grained on the top and more coarse on the bottom and “just enough just in time” planning via a Sprint based approach, allow a Scrum Team to reduce complexity and defer decisions which are not necessary at a certain point in time.

They can keep instead options open up to the last responsible moment: they can use time to collect more information and learn more about the product and the context in order to take better decision later, based on facts. They will of course learn fast by means of quick feedback loops provided by the Sprints.

This allows a Scrum team to be more flexible to react to the changes that will surely happen in the market and in the technology: they can truly embrace change inside their process of developing SW.

4. Deliver as fast as possible

Short delivery cycles represented by Sprints allow deliver quickly to maximize return on investment, get feedback from real customers and users and reduce risk that you won’t deliver a product that meets customers’ needs, due to misunderstanding or any changes in markets and technology.

A team focusing only on delivering the Sprint backlog will produce potentially shippable SW increments faster.

5. Empower the team

Scrum is all about empowering self-organized teams to find the best way to accomplish work. Self-organized teams can leverage all members’ talents and intelligence in the best possible way to achieve their goal as fast as possible.

Real empowerment is achieved by having the Product Owner to decide the “What” and the “Why” and explicit it by means of Product Backlog items in the form of User Stories: the development team will then decide the “How” and find the fastest possible way to get a User Story done.

6. Build integrity in

In a waterfall approach, piling up code without testing often result in a very expensive re-factoring effort, due to bugs, but especially to requirement change or misinterpretation.

Quality in a complex environment like SW development can be built only via iterative and fast feedback loops. A Sprint provides the main feedback loop mechanism in Scrum. Inside the Sprint there might be other even quicker feedback loops:

- the Product Owner (customer representative) works together with development: they are part of the same Scrum teams and work daily together: they collaborate on the Product Backlog and the real Product and this ensures a continuous feedback loop on requirements and system behavior

- Scrum teams adopting XP practices perform continuous refactoring, continuous testing, and continuous integration, which are Agile ways to build quality in.

7. See the whole

End-to-end Product Backlog items (slicing the product end-to-end vertically and explaining why) and cross-functional teams allow looking at the whole system: they can adapt the work items and the process to maximize the value delivered and achieve the Product Vision in the fastest possible way.

An empowered and self-organized team, working closely and daily with a customer representative (the Product Owner), have the possibility to look at the whole development process, find the weakest link or the bottleneck at hand and do whatever they see as necessary to fix it.

They have enough visibility of the whole to avoid sub-optimizations which typically, in traditional environments, try to optimize some small part of the system, which may not help the whole system.

If you want to implement a Lean thinking in your organization, try to practice effective Scrum first and you will get an extraordinary teacher. Scrum is Agile and Lean.

What do you think? 

Change is optional: survival is not mandatory

As many of you can have guessed, the title I chose for this post is inspired by a quote from W.E. Deming.

When I got to know Deming for the first time, many of his lessons came as a revelation to me: they were kind of resonating with my personal thoughts and reflections, but still they cleared out many clouds.

One of those I prefer is: 

“…most troubles and most possibilities for improvement add up to proportions something like this: 94% belong to the system, 6% are attributable to special causes.” 

I think that this simple sentence can trigger several reflections about how to make things happen and especially how changes can have a chance to happen and possibly stick.

Below are mine, from my personal survival handbook J.

1. Look at the system

An organization, even a single team, is a complex network of people, who are complex beings. If you really want to leverage on all potentials to affect it, you must look at it as a whole system. 

Try to sketch the possible options you have ahead, possible impediments and way to overcome them to reach your goal: you might realize that you need to take many steps, in order to get any progress. 

Prefer actions who affect the environment around or the process to do things, instead of addressing directly a specific problem: they will have a more lasting impact. And, whatever level you want to affect, consider acting also one level up.

“It does not happen all at once. There is no instant pudding.”-W.E. Deming

2. Involve people

Try to understand your team or organization very well. Learn about the invisible networks, the inner relationships among people, who is friend of whom, who is most sensitive to certain subjects and who counts more or is more influential on certain subjects, whether he has a formal power or only a de-facto leadership. Talk to people, with a preference for informal chats (coffee machines are a perfect place sometimes).

“A desk is a dangerous place from which to view the world” – J. Le Carré

Create an alliance: find initiators to support you and involve them in creating a shared strategy for the change. 

Chase innovators eager to try new things out first and learn from people actually doing the work. 

Find also sponsors to support you in difficult situations and leaders who can help with crossing the chasm and reach out the majority.

“The greatest waste … is failure to use the abilities of people…to learn about their frustrations and about the contributions that they are eager to make”- W.E. Deming

Strive for ways how to collect as much feedback as possible, especially from skeptics, but do not spend time in convincing cynics and possible saboteurs.

3. Communicate properly

You cannot just plan your change at your PC, create a slide ware and then ask to deploy it to the whole organization.

How many times have you tried to do that way? How many times did it work?

“Insanity: doing the same thing over and over again and expecting different results.”- A. Einstein

Instead explain the “why” for the change; make people aware of what it might mean and relate the change to their daily problems.

Have people desire the change (what’s in it for me?), support them with the change, provide the necessary knowledge and give them time to learn. 

Offer role models, lead yourself by example and help people with mentoring and coaching on how to change.

“If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.” – A. de Saint-Exupery

4. Reward behaviors not outcomes

When you make a change or learn something new, usually your performances at the stuff affected by the change are getting a bit worse, especially at the beginning. So give room for experiments and possible failures, so that people are not afraid to try new things.

Celebrate short-term wins and success stories; make them visible and share the results with information radiators. 

Publicly reward those who are learning more or sharing more with others, so that the change can go viral. Express appreciation for the right behaviors so that the desire for change is continuously reinforced.

“The most important figures that one needs for management are unknown or unknowable” – W.E. Deming

5. Use an empirical step-wise approach

Before taking any step, try to guess which effect it will have in relation to your goal.

Make a hypothesis and try to validate it as quick as possible with minimum viable actions and fast feedback.

However changes in a complex environment are never a linear process you can plan upfront, set goals and KPIs, deploy it to the organization and track the progress. That’s why sometimes you must simply try things out. That is sometimes absolutely not bad, stated that you try to fail fast and reflect on what you learned to find a different path.

Of course using an empirical process control implies that you can observe your system to be able to inspect and adapt. Therefore enable full transparency; make relevant information visible as much as possible from everybody to everybody to be able to really understand what’s going on and act accordingly. Otherwise your change will degenerate into chaos.

“It is not enough to do your best; you must know what to do, and then do your best.” – W.E. Deming

How much time and effort are you spending really nurturing your system?

How much are you learning from people actually doing the work?

Are you really making changes happen or just increasing the entropy of your system into chaos?

And if don’t mind about change and how to make changes effectively, skip the whole article and just consider that: 

“It is not necessary to change. Survival is not mandatory.” – W.E. Deming

A Lean manager is not a coach!

Or is not only a coach.

Or, even better, is not primarily a coach.

Many times I heard people saying that traditional management style do not apply in an Agile and Lean context and therefore it must be replaced by coaching as THE way to help people develop.

I think this is wrong or at least shows a narrow, easy and fluffy view of what a manager is supposed to do for an organization in the 21^st century who wants to run its operation inspired by Lean thinking.

But let’s have a look at the different Lean disciplines one by one and try to understand better what is the essential contribution needed from you as a manager.

1. Eliminate waste

First step to eliminate waste is to see the waste. So you should know (and know very well) the Value Stream of the product(s) you’re working with and continuously challenge the current practice to identify waste. 

But this is not enough: a Lean manager should help teams remove impediments they are not able to resolve by themselves and systemize solutions in the organizations to prevent the same impediment from coming back again (see more about this in my previous post 3 things we can learn from TPS)

2. Build quality in

This means for a manager working to build a culture of discipline and excellence, that is guide on principles and values instead of giving complex rules, teach people not to cut corners, challenge people to high performance and lead by example. And yes, that implies true leadership.

3. Amplify learning

Most managers face competition with other managers trying to meet locally optimized goals and maybe look good to the next level up. But this wastes a lot of organizational learning, which can be effectively used by pairing up with peers. So building and maintaining a network of peers is essential as well as continuously challenge own management style in the light of Agile and Lean principles (see also Cultural transformation through deliberate practice of behaviors). But amplifying learning also means:

·         concretely encouraging experiments, fast feedback loops and safe/fast failure

·         providing and being open to feedback

·         striving for a radical transparency (as Steve Denning calls it) as the unique way to control the complex system your organization represents

4. Defer commitment

Keep your options open up to the last responsible moment and be capable to live with uncertainty: there’s no other way around (have a look here). Furthermore early commitment could mean discard too early real options which might have provided more value, just not to afford the cost of deferring a decision.

5. Deliver as fast as possible

The fastest way of achieving a goal is to let a diverse team of skilled people self-organize to better judge how to solve the problem. And the best way to have them self-organize is to define what the goal is, make it compelling and clarify what constraint the environment around puts to the direction. Then if you want to help your team or organization to deliver as fast as possible, set a clear vision, explain clearly where to go and why, align all stakeholders around that vision and get fast feedback. Then set specific goals derived from the vision: in that sense you’re the PO of your organization, so write a backlog of stories aligned with what you think is the ultimate goal to reach. And finally give space to your teams to reflect on what they are doing to find ways how to go even faster.

If you're not a front line engineer, there's only one reason for you to exist: help your team move faster - Jan Bosch

6. Respect people

Who dare disagree with this? Actually this apparently generic statement hides a deeper meaning. It stands for: give people the environment and support they need to do a great job and trust they will do their best to accomplish their goal. So it’s not simply saying to a team: Now you’re empowered to do what you want, but putting them into the conditions to succeed. So it’s about staying close to the teams, Managing By Walking Around and Listening (MBWAL instead of MBSR – Managing By Status Report), energizing people around you, assisting on personal development. And yes: that might be teaching, mentoring and coaching as well.

7. Optimize the whole

Optimizing the whole means having an e2e view of your system, product or organization and consequently as a manager selecting the right metrics which can help you improve, measures only what adds value (less is more) and whatever you want to measure, measure it one level up.

Of course, being a Lean manager does not mean taking decisions your team would be able to take themselves, asking for reviews and reports or pushing activities on your people.

On the other hand coaching is all about the coachee agenda, but improving theValue Stream, build the organizational culture, set the direction or define proper metrics cannot be other than about your agenda as a manager.

So were you one of those who thought that managing an Agile and Lean organization meant just coaching?   

What’s your thinking now?

5 things you should know about Organizational Coaching

Some days ago I was having a coffee with one of my colleagues.

While answering to his request of feedback about his work as a Scrum Master, we ended up in talking about what organizational coaching means in practical terms, what it is really and what it takes to be effective.

I cannot report the whole interesting discussion, but here are some takeaways as summary for you: 5 things you should definitely take into account, if you want to become an organization coach.

1. Use a system approach

An organization is a complex network of people, who are complex beings. If you really want to leverage on all potentials to affect it, either to make it better or simply to help your team, you must look at it as a whole system. Try to sketch a strategy of the possible options you have ahead, possible impediments and way to overcome them to reach your goal: you might realize that a single isolated step is not enough, but you need to take many steps, in order to get any progress.

2. Know your organization

Try to understand your organization very well. Learn not only about the official and visible structure. Learn much more about the invisible networks, the inner relationships among people, who is friend of whom, who is most sensitive to certain subjects and who counts more or is more decisive on certain tables, whether he has a formal power or only a subtle influential leadership. You cannot imagine what competitive advantage this will give to your effectiveness.

3. Act on different levels

Challenge the status quo and don’t limit yourself to the most obvious actions. Prefer actions who affect the environment around or the process to do things, instead of addressing directly a specific problem: they will have more and lasting impact.

Talk to people, with a preference for informal chats - coffee machines are a perfect place sometimes :). Try to find initiators and innovators to help you and sponsors to support you in difficult situations. And, whatever level you want to affect, consider acting also one level up.

4. Understand the effect of your actions

Before taking any steps in your strategy, try to guess which effect it will have in relation to your goal. Make a hypothesis and try to validate it as quick as possible. Find even people who to share your thoughts to and get feedback. The sooner you know if your strategy can work well or not, the better it is: you will then be able to adjust it if necessary and speed up the achievement of your goal.

5. Try things out

Finally organizational coaching is not mathematics and the system to act upon is many times far too complex to draft a strategy since the beginning, indentify any viable action or understand the effects of possible actions. That’s why sometimes you must simply try things out. And that's not wrong, stated that you try to fail fast and reflect on what you learned to find a different path.

That’s my experience. What did you learn in yours?

Cultural transformation through deliberate practice of behaviors

This week I was at LESS2012 conference.

The conference overall was really interesting and I would like to start right away to share with you the 3 most inspiring things I brought home with me from the sessions I attended.

1. The first one is from Jurgen Appelo’s keynote.

The whole performance rocked as usual, but I'm sure you will agree that the following concept is really great. He said that the verb “Manage” come from Italian “Maneggiare” and from French “Menage” which originally meant “drive and take care of horses”.

So Management is actually driving and taking care of organizations as they were living beings and they are indeed. That’s why management is too important to be left to managers: we must all lead.

2. The second great quote is from Beyond Budgeting track hosted by Peter Bunce (Chairman of BBRT) and Bjarte Bogsnes.

They echoed Steve Jobs saying: I discovered that sometimes the best innovation is the company, the way you organize the company. 

We need a more self-regulating way of management. We all agree in principle with this, but the problem is bringing this to practical consequences.

Most companies say or write that, but the problem is what we do, not what we say.

There are most times gaps between what we say and what we do and this gap is poison for the organizations.

3. Last reflections come from the other 2 keynotes.

Christopher Avery pointed out that traditional managers are always looking for single point of accountability, but collaboration does not work with single points of accountability.

Esko Kilpi added that from a social business standpoint, the individualistic view is fundamentally misleading: there's co-creation. So is the sense of personal responsibility. The new competitive edge will come from openness, transparent information and collaboration.

Awesome, isn’t it?

On the last day I held my workshop Learning to be a manager in the age of Agile.

The question I put was just the following.

If all the changes above are needed in 21^st century management, compared to current mainstream management (still focusing on the very same practices invented more than 100 years ago with totally a different goal than making our companies responsive, adaptable and innovative), what is a feasible path to get there?

The proposal I made is based on 3 steps:

1. Challenging current management beliefs
2. Challenging your actions in the light of Agile and Lean principles
3. Deliberate practice of functional behaviors in line with the principles

The idea is to break the maps wired so far in our brain by all experiences and beliefs in our life and which we follow naturally like a river bed to interpret the reality. Then build instead, drop by drop, new side river beds, which could allow us to see the reality with new eyes and act accordingly.

After the conference I had the pleasure to discuss this approach with Dawna Jones, who very well pointed out how just focusing on behaviors allows to achieve only short term and not permanent cultural changes.

I agree this is very true and indeed in line with the approach I suggested. Deliberate practice of behaviors (like deliberate practice of technical skills) and continuous self reflection are just ways to understand the values behind. This will allow behaviors to become habits and enter deeper in our brain and heart to create new beliefs, new assumptions, new structures and ultimately a new culture to provide different responses to our evolving reality.

It’s the management Shu-Ha-Ri!

Wearing the right glasses

Last night I made a strange dream.

I was tiny small, while very big words were flying around me and suddenly thrown in a gigantic mixer, which put them out in a changed order, building completely new sentences.

Different kinds of sentences and words were undergoing the mixer and came out changed.

Among the others I saw the 7 Lean Disciplines: they came out of the mixer like this.

- Eliminate quality

- Build Waste In

- Create Knowledge

- Decide as early as possible

- Deliver as late as possible

- Respect the whole

- Optimize people

One of those sounded familiar to me, but the rest? 

Am I seeing right? Am I wearing my glasses?
Were they changed to the "The Fat Disciplines" instead? Was it a dream or a nightmare?

I woke up sweat in the early morning and started reflecting with myself.

I got to compare the Fat versus the Lean Disciplines to evaluate, not which are the most effective, but simply which are the most sensible to really manage the business we're in.

The life would be great if I could give a specification to my team and ask them to commit as early as possible that the project will cost 96.356,55 EUR and will be delivered exactly on October 20th, 2013 at 12.45. Why can't I do that?

Well, just because that's the life.
Most of us might have experienced a certain degree of comfort in having a detailed plan in place and believing to have everything under control...
...no matter if the plan turned out to be no longer valid maybe just the day after.

Yes, but that would be developers' fault who were not precise enough with the planning or want to cheat me. And by the way, they are tremendously lazy.

No, it's just because building SW is a complex system made by teams of people which are a complex system as well: you do not know your final destination and the system is non linear, so how can you predict the exact steps to reach it or when exactly you will land there?
Complex systems have their laws (smell some flavour at here) the same as we are subject to the law of physics.

So why can't I simply decide a plan and stick to it?

Well, because complex systems are not deterministic: things change, there's not full visibility of the whole path, knowledge of the system increases on the way and new things emerge. Having quick feedback loops is the only way for you to learn as fast as possible.

Mike Cohn tells how Trond Pedersen very well describes this subject: "Complaining about requirement change is like complaining about the weather. You can't really change how the world is, but you can find ways to deal with it. Don't make an offering to Thor (the Viking god of thunder) to make the rain stop: get an umbrella".

So it's only your risk if you get an umbrella or not.
It might sound a bit less comfortable, since we must learn to live with some level of uncertainty, but isn't it just more sensible?
And maybe a bit more scientific...

Reflecting around, it was finally time to get ready and go to office. I made sure I get on my glasses.

We might not talk about Agile and Lean in 10 years any more, but they are definitely the glasses to wear to see and understand our business now.

Measures which matter

About one month ago I was following a couple of colleagues discussing on Twitter about measures and specifically about measuring productivity. It was a nice exchange of views on whether development of a new product is production or creativity and what to measure in either case.

I personally think that SW development is most about learning: make an assumption, do the cheapest experiment to validate that assumption and evaluate the results by means of customer feedback. That’s why Agile makes sense.

Now I do not want to come into specifics (I do not know the background of the discussion), but I was thinking: I cannot give THE right answer to the question, but I would put on the table some basic principles about how a good metric should look like.

1. Measure one level up – Whatever you want to measure you might better look at the next level: look at teams if you want to measure individuals, look at the development organization if you want to measure teams, look at the e2e flow if you want to measure the development organization
2. Few, Simple and Visible – Full transparency makes the chosen metric powerful. Don’t over measure.
3. Drive right behaviors – Don’t measure outcomes, but put functional behaviors in place and the outcomes will take care of themselves. You get what you measure.

Some time ago we had an issue about high pressure on teams to deliver (actually from both inside and outside), so that many people (and many influencers in the organization) did not consider important improving as individuals and teams. So management decided to measure teams’ improvement ability.

I’m scared already only by thinking at possible solutions a traditional and bureaucratic organization could have thought about in the attempt of achieving this goal.

We simply tried to apply the 3 principles above and setup a metric called:

Organizational improvement factor = % Total Time dedicated to Improvement actions vs. Total available time. Here is the rationale behind:

1. Measure one level up – We wanted to measure teams, so we decided to measure the development organization: it is not finger pointing to any individual or team, is collaborative and everybody feels accountable for the overall value.
2. Few, Simple and Visible – A unique metric which is simple, updated at each sprint and fully visible on a white board in a common space.
3. Drive right behaviors – Behaviors are a function of people and their environment: this metric resulted to be a good way of influencing the environment and then the teams’ behavior. Everybody feels now that improvements have a recognized dignity.

The same applies when talking about measuring stuff like development productivity or efficiency.

1. What is the next level up which makes sense to measure?
2. How can we make it simple and transparent?
3. What good behaviors should we look for?

In that case I would rather measure organizational effectiveness:

Are we doing the right things and only what is strictly needed? 

How is our Return on Investment?

You will realize that you need to consider delivered value (not only costs) and discover that effectiveness eats efficiency at breakfast every morning: if you drop 50% of the scope because it is not needed,  manage to deliver faster and get money earlier, there will be no cost efficiency program or productivity improvement whatsoever that will give you comparable results.

However, being a team or an organization a complex system of human beings, I would like to leave you with a quote from master W.E. Deming:

97% of what matters in an organization can’t be measured. Only maybe 3% can be measured. But when you go into most organizations and look at what people are doing, they’re spending all their time focusing on what they can measure and none of their time on what really matters – what they can’t measure. Why would we do this? We’re spending all our time measuring what doesn’t matter.

3 things we can learn from TPS

Last week I mentioned my participation to a seminar organized by the Industrial Association of Salerno on Lean Management and Continuous Improvement.

This week I would like to share more about that event, by highlighting what I think we could learn from experiences of organizational transformation and Lean management in other industries together with some (hopefully) powerful questions to facilitate further reflections.

1) Visible problems do not exist: they have been solved already!

One more interesting insight I got from Minoru Tanaka, CEO of JMAC Europe, in his speech about Toyota Production System (TPS) was his classification of problems into 3 categories: potential, invisible and visible. It’s important that potential problems to the desired target are identified as well as invisible problems are made visible and improved immediately. Instead, visible problems do not exist actually, because they have been solved already. 

• How many clearly visible problems are you still stuck with in your organization?

2) Most efficient way becomes standard: standard must be improved every month!

Then Mr. Tanaka discussed about Continuous Improvement, describing that, once a process has been improved in one department, than the most efficient way becomes a “standard”.

When hearing this word, I got disappointed wondering how hell the definition of a standard process could fit into a Continuous Improvement approach.

But then he added: the “standard” must be reviewed every month!

And more: the “standard” is visualized and each manager is accountable to improve the “standard” every month! 

• How much are you still striving to find one-size-fits-all "best practices” to make you move quickly to the next rigid and comfortable status quo?
• What are your managers accountable for? 
• How much are they encouraging the “stop the line” principle?

3) Measure organizational capacity of solving impediments to generate trust

Last enlightening reflection to me was from the local director of a cans manufacturer with around 1500 employees.

You might wonder how cans may be relevant for high-tech industries, but let me continue.

Well, he was describing their transformation journey to Lean and talked about the importance of impediment handling in his organization to be trustable. They have a graph, clearly visible to everybody, with 2 curves: the accumulated number of raised impediments per month and the accumulated number of fixed impediments per month.

The 2 curves must always be parallel, because he said: “If the curve of fixed impediments goes flattish, all my employees will understand I do not believe in what we’re doing and I’m just cheating them”. 

• How is your organization serious with fixing impediments from teams?
• How much are you living the values you’re preaching?