--- title: "The Chaos Addiction" url: "https://www.5whys.com/articles/the-chaos-addiction.md" canonical: "https://www.5whys.com/articles/the-chaos-addiction.html" published: "2011-08-07T22:18:00.006000+00:00" updated: "2011-08-10T17:33:59.563000+00:00" tags: ["Anti Patterns", "First Steps during chaos"] author: "Roy Osherove" description: "How survival mode becomes a self-reinforcing addiction that cuts quality and learning time, and why a team leader must take a risk to break the cycle." usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # The Chaos Addiction I'm convinced more than ever these days, that [being in chaos](https://www.5whys.com/articles/the-3-maturity-stages-of-a-software-team-and-how-scrum-fails.html) is a self perpetuating state of being, unless drastic measures are taken. It is a pattern of _addiction_, in that it reinforces the bad habits that lead to even more chaos (less time to learn), while reinforcing the belief that those bad habits are the only way to solve problems in the short term, wihtout a long term view. Jerry Weinberg's book "[Managing yourself and others"](http://www.smashwords.com/books/view/39685) describes this type of "addiction" nicely. Below is a paraphrasing of that idea. A quality addiction cycle goes like this: ## There is an inner - reinforcing loop: 1. Team/Leader are pressured to fix an influx of problems under heavy time pressures 2. Team/Leader decide to "skip" some important measures that will provide quality control (testing, reviewing) 3. Team releases product 4. TeamLeader get a reinforced feeling that getting rid of quality measures was a good idea (and over time, that those practices just take time they don't have) 5. The next time the same scenario shows up, they are more likely to re-create the same solution ### There is an outer - reinforcing loop: 1. Because of the team's decisions to let go of quality practices (technical debt), quality goes down 2. amount of bugs or customer complaints rises 3. amount of pressure to fix said bugs complaints, in the shortest time, rises 4. The team is now under even more pressure to get into the inner loop of death - letting go of quality practices to "put out the fire" # What about the chaos cycle? Reminder: Chaos is about the team not having enough time to learn (slack). ## Inner loop: 1. Team has tasks to do and is under pressure to complete them in a schedule that'e either impossible, or close to that 2. Team doesn't complete tasks on time, or barely on time 3. Team sees that the way they are currently working seems to have "made good" on their promise to fix X amount of work 4. Team is reinforcing its belief that there is no time to learn, or they won't make their commitments ### Outer loop: 1. Team commits to X tasks and does no learning 2. The lack of learning means that the team is not learning new ways to optimize or improve their work or quality, so their output stays the same, or gets worse based on the changing conditions 3. The pressure on the team remains the same, or worse, based on their 'standard' or worse, performance. 4. Team believes even more that learning time is the last thing they can afford. Breaking the chaos addiction is also very scary for a leader - they have to take a personal risk and remove promises from their backboard so they can make time to learn for the team. they have to actually take a stand for the team's way of work, and to promise that the new way of work with be better for the organization. The team leader may lean back into chaos, because It's much more comfortable to just say nothing and continue the cycle of comfortable, whiney, addiction to over-work. It's much harder to break this cycle because the belief is that learning time is not possible, and the risk of 'losing face' in front of management is high, when fighting for learning time. it is a sort of placating to upper management - the team blames itself  for even needing time to learn or for not doing a good enough job to have time to learn after the work is done. instead of insisting that it is a blessing to have a learning team, for everyone's sake.  It is almost always an issue of personal self-worth on the side of the team leader, who may be silently disagreeing with management, and feeling powerless, when in fact they are being paid to do those tough things like taking a stand for breaking this cycle of addiction. > A team cannot become truly self organizing without learning. learning takes time, and to get time, you have to make time for your team by breaking out of chaos. ## Read next - [12 Behavior Anti Patterns You Will Face As a Software Team Leader](https://www.5whys.com/articles/12-behavior-anti-patterns-you-will-face-as-a-software-team-l.html): Twelve team member behavior anti-patterns and three outside disruptions a software team leader faces in survival mode, with how to respond to each one. - [On time, with quality - why is this mostly failing?](https://www.5whys.com/articles/on-time-with-quality-why-is-this-mostly-failing.html): Why teams fail to ship on time with quality while stuck in chaos, and why team leaders must remove commitments to make time to learn and practice. - [Step #4 - Start doing code reviews – Seriously](https://www.5whys.com/articles/step-4-start-doing-code-reviews-seriously.html): A team leader's guide to serious code reviews: what to look for, reviewing every check-in yourself at first, then training the team to review its own code. ## Topic - [Survival Mode](https://www.5whys.com/topics/survival-mode) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/