--- title: "Good Agile, Bad Agile" url: "https://osherove.com/blog/2006/10/11/good-agile-bad-agile.md" canonical: "https://osherove.com/blog/2006/10/11/good-agile-bad-agile.html" published: "2006-10-11T10:24:36" updated: "2006-10-11T10:24:36" tags: ["Agile", "Agile Related"] author: "Roy Osherove" description: "Steve Yegge, an employee at Google, has a very interesting post where he separates \"Bad Agile\" from \"Good Agile\". I urge you to read this long post as it contains many points that try to explain what \"Bad Agile\" is.…" 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/" --- # Good Agile, Bad Agile By Roy Osherove October 11, 2006 In [Agile](https://osherove.com/blog/category/agile), [Agile Related](https://osherove.com/blog/category/agile-related) **Historical article** · Originally published October 11, 2006; technical details may be outdated. Steve Yegge, an employee at Google, [has a very interesting post](http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html) where he separates "Bad Agile" from "Good Agile". I urge you to read this long post as it contains many points that try to explain what "Bad Agile" is. There's a lot I want to talk about in regards to that post, but first it's important to read it (and it's 180+ comments) to get an idea of Steve's thoughts. Regardless of his thoughts, he describes Google as the ultimate place to work for. The stuff he mentions that goes on there sounds really great. I'd love to take a tour of the place some day. Steve thinks that "Google" is the new "Good Agile", and that the word "Agile" is too overloaded and should be ridden of. Personally I think that he has some valid points, but I tend to disagree with many other points he makes. Funnily enough, he mentions two practices that Agile Advocates use: > "I would caution you to be skeptical of two kinds of claims: > \- "all the good stuff he described is really Agile" > \- "all the bad stuff he described is the fault of the team's execution of the process" > > You'll hear them time and again. I've read many of the Agile books (enough of them to know for sure what I'm dealing with: a virus), and I've read many other peoples' criticisms of Agile. Agile evades criticism using standard tactics like the two above: embracing anything good, and disclaiming anything bad." True, I think this is a real concern. As a pragmatist, I try to be realistic with Agile practices, and I've never seen companies follow an exact methodology to the letter, but instead use a bunch of practices from several places, and integrate them into their teams. It's a much more reasonable place to be than turning your whole world upside down, and you can always add more agility when you need it. I **am** tempted to label all the good things he wrote in that post as "Agile". Seriously, they do feel like it. But just because he said "beware of these claims" doesn't mean they aren't correct. It's a sign of a great writer when he can predict the reactions of the reader and the people reacting to it, and pre-answer those concerns. Do you think he's right? Wrong? both?  Your comments are welcome. I'll be writing more about this in the coming days**.** ## More in Agile [All posts in Agile](https://osherove.com/blog/category/agile) - Oct 15, 2006 ### [MassDataHandler: generate test data to help with data layer testing](https://osherove.com/blog/2006/10/15/massdatahandler-generate-test-data-to-help-with-data-layer-t.html) - Oct 14, 2006 ### [DataFresh - Database rollback library for unit tests](https://osherove.com/blog/2006/10/14/datafresh-database-rollback-library-for-unit-tests.html) - Oct 10, 2006 ### [The Art Of Unit Testing - Download Chapter 1](https://osherove.com/blog/2006/10/10/the-art-of-unit-testing-download-chapter-1.html) - Oct 3, 2006 ### [Avoid multiple asserts in a single unit test: revisited](https://osherove.com/blog/2006/10/3/avoid-multiple-asserts-in-a-single-unit-test-revisited.html) --- ## 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/