Tag Archives: Theory of Constraints

  • -

What is Systems Thinking Leadership?

Tags : 

A Rube Goldberg Machine

A Rube Goldberg Machine. Photo by freshwater2006

The conventional wisdom is that leadership is associated with a role. It is something to be left to Bosses, Managers, and those who have authority. This model worked fine when markets moved slowly and competitors had the same leadership model. Today, business is very different. Markets change very quickly, competitors continually try to take your customers, and the lifespan of companies has shrunk . “The average lifespan of a company listed in the S&P 500 index of leading US companies has decreased by more than 50 years in the last century, from 67 years in the 1920s to just 15 years today, according to Professor Richard Foster from Yale University. Today’s rate of change “is at a faster pace than ever.” If companies are to survive, they will need a model for leadership that is different than in the past, because, as the accelerated corporate death rate shows, relying on the old methods of leadership has Darwinian implications.

Leadership must move out of the hierarchy and to the front lines. It must move from one or a few brains, to all the brains in the organization. In 2016 Leadership is not a role, it is a task, best accomplished by the person with the most/best information at that time. In most organizations, the person with the best information is rarely the Boss or the Manager, because almost all of their information is second hand. Leadership needs to be delegated from Bosses and Managers to the people doing the work who have the best information. This has implications for everyone. It means that positional power is not as important to company survival, but too much positional power can threaten company survival. So how do we enable Leadership at the front lines? Training? Coaching? Empowering? While all those things can help, the answer is NO. If you want a company that survives and thrives in 2016 and beyond, then focus on Organizational Design. The structure of your organization defines how decisions are made, how people are rewarded, what positions have power, what policies are enforced and by whom. Changing the organizational structure with the specific goal of enabling Leadership at the front lines is a crucial step building a company that will last. This is Systems Thinking Leadership. #Scrum #Lean #TPS #LeSS #LeanStartup #CustomerDevelopment #Neuropsychology #NeuroLeadership #Holacracy #Sociocracy #Valve #WLGore #Semco #Facebook #TaichiOhno #JeffSutherland #PeterSenge #JohnSeddon #CraigLarman #DanPink #DavidRock #SteveBlank


  • -

How can a CEO make software development teams deliver more features, faster?

Tags : 

I recently provided some free advice on Linkedin about software development. A manager had recently implemented Scrum to improve their development process.

While things are better, the CEO, who doesn’t really care about what methods they use, was not satisfied. He wants more features, faster. In this organization they have a lot of legacy code, so implementing new features is slowed by the complexity of the code base.

The CEO wants a solution that will speed up development. The CEO has proposed taking the best developers from every team and putting them on one team where they will create designs and prototypes of the new features that will be implemented by the teams.

The CEO thinks this approach will speed things up. If we assume the teams in place today are competent, the CEO’s proposed approach could really damage the delivery organization’s effectiveness, morale and really slow things down. I hear this kind of thing regularly, so here is how I think about this problem.

Update: I received feedback from a reader that I should explain why the CEO’s proposal will not work. I skipped this explanation because it will take more time and take away from the point of the article. The situation is similar to a person who doesn’t understand cars trying to fix one. They can spend lots of money replacing car parts and never fix the problem.

Here is my analysis of the risks of the CEO’s proposal. Feel free to skip this specific analysis if you want focus on the solution

In this specific case the solution proposed by the CEO is to take the best developers from the current teams to create a new “super” team. The “super” team’s mandate is to create designs and prototypes for the other teams to implement. So the “super” team won’t actually deliver new features customers can use. Every design decision the “super” team makes now needs to be conveyed to the other teams. This “super team” idea increases communication overhead, slows delivery of new features, takes the most productive developers and stops them from delivering features. The “super team” also breaks the currently functioning teams by removing their best developers, making the teams less productive. The intellectual capacity of the team members is wasted because now they only follow the “super” team’s orders (designs, prototypes, etc). This reduced autonomy reduces intellectual capacity of the organization and decreases morale. The staff on the “super team” are also likely to be frustrated, since they are no longer delivering valuable software features, and the work they enjoy the most will be done by others. The people on the “super team” have little experience working together so they will be slow as they figure out how to work together and become a team. The “super team” will spend most of their time communicating instead of coding. The “super team” will likely suffer from departures as the “best” developers, increasingly frustrated with the lack of programming and increased communication overhead look for other jobs. The CEO thinks his proposal will create a team of heroes that will speed up the process. However the solution actually increases communication overhead, increases length of feedback loops (features working or not), slows down the teams, decreases morale, increases waste and creates frustration. Given the information we have today, that the main problem is a legacy code base that is hard to work with (not staff competency), the “super team” solution does not address the core problem.

The organization has a certain speed at which it can produce new things, and the CEO wants the organization to produce faster. Well, every CEO wants that, so nothing new here. The solution proposed by the CEO will not speed up delivery of features, it will slow down the system. The only way the CEO will get an organization that delivers faster is if he pays very close attention to HOW the company builds products, specifically how work flows starting with a new feature request to completed features in production. One can’t fix a system without first understanding how the system works. By paying attention to how work is done, the CEO and every manager can then lead the organization by asking for regular improvements in the process. There are many thinking tools from Lean, the Theory of Constraints, etc. that can help management and teams find problems and solutions.

Getting features out faster is usually the second thing to worry about. Most software that is built is never used. This has been shown in study after study for more than a decade. The only way the CEO will get more value delivered from the organization is to pay close attention to what is being built and ensuring that only the most valuable and important things are being built. This means really understanding what a customer needs AND what they actually use (vs what they think they want). Lean startup provides lots of practical advice to solve this problem of building the right thing.

Since the biggest fastest improvement is achieved by simply not building crap your customers will rarely or never use, I recommend the CEO and the management team together:

1. Change what you are working on to maximize value

Learn: Watch Agile Product Ownership in a nutshell

Read The Lean Startup by Eric Ries (they will enjoy it, written by a tech executive)

Take a 2 day Certified Scrum Product Owner or Lean Startup course from Robin Dymond Contact Us.

Act: Remove as many features as possible from the product backlog (nice to haves, not needed now, not sure who needs it), and harshly re-prioritize the rest of the features.

For example one management team I worked with used the following prioritization scheme:

    1. 1. We’ll go out of business if we don’t have [Feature]
    1. 2. It will cost us lots of money but we won’t go out of business if we don’t have [Feature]
    1. 3. Everything else
    With this re-prioritization the management team discovered that they could get all the 1 and 50% of the 2 priority features done by the deadline. These priorities cut the delivery time by 50% and ensured that the fraud detection system for a major U.S. bank would not hold up a very large re-platforming program. The rest of the 2 priority features were mitigated with manual processes and delivered after the re-platforming.

Apply and Improve: Implement Lean Startup thinking to product feature discovery, prioritization and product feature validation.

2. Change how you organize work to maximize learning, collaboration, and effectiveness of the organization

Managers and leaders:
Learn: Read and study about Lean, Theory of Constraints (TOC), Scrum Velocity
Take a 2 day Lean and Agile for Managers course on these topics from Robin Dymond Contact Us.
Apply: Value stream mapping and Lean tools, TOC.
Hire a Lean Agile consultant to help management and the organization transition to Agile, Lean and TOC management principles and practices. Innovel consultants specialize in this area. Contact Us.
Improve: Measure your starting baseline, including value stream, bottle necks, information silos and velocity. Incrementally improve the value stream, remove bottlenecks, remove silos, and improve flow.

3. Change how you practice design, coding, and testing to improve quality and speed

Teams:
Learn: Take hands on training in Agile engineering practices and Agile testing.
Apply: Hire a technical consultant to help teams apply Agile engineering and Agile testing practices in their day to day work. Innovel consultants specialize in this area. Contact Us.
Allow time for new practices to be learned and mastered.
Improve: Measure baselines for unit and functional automated test coverage, and code quality. Invest in improving these metrics over time.

Teams working with Legacy code and using Agile face specific challenges. Team members and managers should:
Learn: Read the PDF Working Effectively With Legacy Code and then read the book Working Effectively with Legacy Code
Read about “Technical Debt.”
Apply: Measure baseline technical debt in your system, long term and short term debt. Develop a strategy for paying down technical debt.
Improve: Implement the technical debt strategy together with teams and management and actively manage technical debt.

Metaphor for management: “Does shoving more paper into a printer make it print faster or make things worse?”

smoking printer

Happy New Year!!


  • -

How Spotify Works. Agility with 1 product and 1200 people

Tags : 

Scaling Agile at Spotify. What True Organizational Agility Can Look Like.


Henrik Kniberg and Spotify released an illustrated video on how Spotify is Scaling Scrum and Agile from a 1 team startup to a 1200 person powerhouse of the online music industry. Spotify is a disruptive force in the music industry, forcing record companies, radio stations, and artists to rethink their business models. Spotify is also an Agile company from the ground up. Spotify got its start using Scrum with one team, so there has been no “Agile Transformation” for the company. Instead the company faced the problem of how to maintain the Agility they had with one team while growing quickly.

The video describes their team structure, the organizational structures that span multiple teams, and the key principles that guide their decision making. I think it is fantastic that Spotify was willing to open the Kimono and show the world how they work, and that Henrik, as their Organizational Coach was able to present it is such a compelling visual way.

This is the cutting edge of organizational agility. For most companies, this kind of organizational model is a fantasy, it is so far removed from their current organization’s structure. If I were a music company executive, I would be scared as hell. Instead, I look forward to continuing to help companies achieve their own improvements for Agility in their own business context.

Part 1 of How Spotify’s Engineering Culture Works


  • 1

Eli Goldratt, a brilliant contributor to making work and life better. 1947 – 2011

Tags : 

“I smile and start to count on my fingers: One, people are good. Two, every conflict can be removed. Three, every situation, no matter how complex it initially looks, is exceedingly simple. Four, every situation can be substantially improved; even the sky is not the limit. Five, every person can reach a full life. Six, there is always a win-win solution. Shall I continue to count?”

Dr. Eliyahu M. Goldratt 1947- 2011


Eli Goldratt When I first read Eli Goldratt’s book The Goal, it was in 2005. I had been using XP and Scrum for 3 years and understood the value of good process improvement ideas. I was stunned after reading it. Not only was the book fantastic, I was shocked: this book had been written in 1986?!?! I felt embarrassed that I had never known about these ideas. In 1986 I was still in engineering and these ideas were cutting edge at that time. Is Theory of Constraints taught in engineering schools 25 years years later? A search of goldrattschools.org reveals 9 affiliated universities, and google searches are not filled with education institutions teaching Theory of Constraints (TOC). It seems most people learn about Theory of Constraints through direct efforts of Goldratt’s various institutes, the Goal and subsequent books, and word of mouth. I have told many people about and given away copies of the Goal, creating numerous converts to Theory of Constraints thinking. Goldratt’s ideas provided many insights into systems thinking and process improvement. As a software development manager who had already transitioned from more traditional management to Scrum and Extreme programming, I found TOC provided another set of thinking tools to analyze a work system. These tools complimented Lean and Agile without reducing their value or conflicting with those ideas. For example Theory of Constraints provides a way to prioritize process changes found using Lean tools or impediments found by the team using Scrum. However the biggest change was that TOC made me think differently. It changed my perspective on systems, on software development and work in general. Like Lean thinking, TOC colors my thinking about any system and gives me greater insight into the natural properties of systems.

Ours and future generations are indebted to Goldratt’s ideas and his insights into people and systems. His ability to write about these ideas using non-technical stories was almost as important as the ideas themselves. His writing allowed many people to pickup his books and within a few hours understand the core concepts of Theory of Constraints. The appeal of TOC ideas caused them to look for ways to apply TOC to their work, while his easy and accessible style created powerful incentives for people to learn more.

I am truly sorry to hear that a genius such as Eli Goldratt has passed away at the relatively young age of 64. I am grateful to have been a student of his ideas and hope to carry on the work of spreading the ideas of TOC and its applications in software development and knowledge work.

From the Goldratt Schools website:

Dr. Eliyahu M. Goldratt spent his entire adult life fighting to show that it is possible to make this world a better place. We must have the honesty to see reality as it is, we must have the courage to challenge assumptions, and above all, we must use the gift of thinking. Having applied these principles to various management fields, he created the Theory of Constraints. His concepts and teachings have expanded beyond management and are being used in healthcare, education, counseling, government, agriculture and personal growth – to name a few fields using TOC. His legacy is invaluable. On June 11th, 2011 at noon, Eli Goldratt passed away at his home in Israel in company of his family and close friends.

The strength and passion of Eli allowed him to spend his last days sharing and delivering his latest insights and breakthroughs to a group of people who have committed to transfer this knowledge to the TOC Community during the upcoming Theory of Constraints International Certification Organization Conference in New York. It was Eli’s last wish to take TOC to the next level – truly standing on the shoulders of the Giant he is.

Robin Dymond