Typically, leaders see the signs of dysfunction. The business is not happy. They complain about cost and schedule and quality. The developers blame the business. “They don’t know what they want” or “They are always changing their minds”. You hear these comments in spite of the years of effort and training to implement project management.
The most common reactions are “What or who do I need to change to fix this?” “Do I need to provide better training?” “Is it the staff we have?” “Is the organization not following the processes?” Do you notice a pattern here?
It is everyone else’s fault but the leaders! The focus is elsewhere and not with the root cause.
This reaction is a long standing one and widely shared. Deming encountered it when he began to teach his principles behind “Lean Management”. In fact, after executives in the US turned a deaf ear to his principles, he traveled to Japan. The Toyota Product System (TPS) is largely built on his teachings. As a result, Toyota has gone from a small insignificant player to a global leader of transportation engineering and manufacturing.
How did this happen? Were the Toyota leaders focused on what changes the staff needed to make or did they first transform themselves? Deming stated that 85% of the dysfunction of an organization is rooted in the processes of the organization. He called it the system. It is the leaders that have primarily put the system in place.
Lean Management is fine for Japan but it will never work here. That was General Motors response to Toyota when they offered to help GM. With American culture and unions it is not possible they said. Toyota asked GM to give them their poorest performing plant. They did. One year later, Toyota turned GMs worse performing plant to their best. Did General Motors rush to convert their other plants? No! Instead they ignored the results and continued with their ways. Change is hard. It is even harder when you are the one that has to change.
In recent years a movement called Agile has emerged. It has primarily been a bottom up movement. Engineers, frustrated with the way corporation built software decided to take action. They were tired of the frequent failures encountered with traditional project management. They gathered to find a better way.
From their efforts, the agile movement was born. It has literally transformed the way software is being built today. This is in spite of the majority of executives not grasping why it works or their role in leveraging Agile effectively.
Agile and Lean work well together. Agile flourishes where Lean is understood and practiced. Lean, unlike Agile, started from the top. It’s about executives taking ownership for the system. Once accountability is properly placed, the leadership can teach themselves how to monitor the system, establish feedback loops, plan change and measure its impact. This is the “Plan, Do, Check, Act” pattern of continuous improvement. The focus is on improving the system, not blaming individuals.
Today, organizational transformations are underway. It starts with leadership taking accountability for the organization’s effectiveness. It is about leadership investing in their understanding of the lean and agile principles. Only through personal transformation can they become effectively leaders. They must lead by doing. They share accountability in results. There are invested.
Common principles shared across Agile and Lean:
- Self-directed teams – Lean recognizes that those closest to the work are the one best to define how to do the work. Agile is an advocate of self-organizing teams. Both require clear goals set by the leadership. Not objectives but goals. Effective organizations are not hamstrung by micromanagers.
- Pull based scheduling – Lean uses Kanban to ensure work is only done when needed; there is no sense building inventory upstream when there is no demand downstream. That is waste. Agile has teams pull cards from the backlog, one per pair, only when they finish the work they have. Pull based schedule maximizes the flow of work through the team consequently it is much more effect than push based scheduling practiced by traditional project management.
- Continuous improvement – Lean uses the shewhart cycle of “Plan, Do, Check, Act” via Kaizen to continually tune the system to maximize the quality and flow of work through the system. Agile uses a number of feedback loops included in Daily Standups, Retrospectives, Show and Tells and Test Driven Development (TDD) to continually improve the workflow and quality of the product.
- Visual Management – Lean use Andon boards to signal when an abnormal condition is recognized and help is needed. Agile uses Big Visible Charts (BVC) to make transparent the current state of the work for a team. Calling out issues brings support not blame from management thus issues are never hidden.
- Mistake Proofing The Work – Lean uses Continuous Improvement to identify how to eliminate mistakes in the process to begin with. Agile uses Pairing and Test First or Test Driven Development. By pushing defects to the left (i.e., find them earlier or eliminate them altogether) waste is eliminated and high quality emerges.
- Root Cause Analysis – Lean uses techniques such as the “Five Whys” and Fishbone Diagrams to identify the root cause of issues. Only when root cause is identified and the cause remedied does the system improve. Agile teams are encouraged to do the same via retrospectives.
By now, it should be clear that unless a leader understand why lean and agile work, they are likely to cause harm. For most, it requires a fundamental change in the way they manage and incent their organizations.
Ask yourself, do you manage by using Management by Objective. If so, what evidence do you have that the targets you put in place can be achieved by your current system? Instead, provide clear high level goals and monitor the trends for your organization. Is your organization trending in the right direction?
What do you use to measure the effectiveness of your business? Do you use Key Performance Indicators? They are point in time. What do they mean? Compared to what? Instead use trends. It is the direction of the trends and not a point in time snap shot that provides you the better insight.
How do you respond when an issue is brought to you? Do you look for someone to blame? Do you micromanage by adding weight to a bloated process? Instead determine root cause not blame. Once root cause has been identified and fixed, monitor trends for impact.
These are but a few examples of why it is essential for a leader to transform first before attempting to transform an organization. One of your biggest challenges will be to gain trust of your organization. Don’t expect the organization to become open quickly. After all, for years they have been trained to game the system. They have been given targets that were often arbitrary and tied to their compensation. This is an open invitation to “fudge the numbers”. You gain neither insight nor provide motivation.
They will watch your response. When issues arise will you blame or will you address the root cause. Will you support the organization by removing blockers or will you use the carrot and stick?
As you can see, you have many old habits to change. The first step to transforming your organization is to transform yourself. The change is well worth it. The impact will be larger and longer lasting than you could have imagined.