Just Telling Teams to Self-Organize Doesn’t Work

Added to People

“Continuous attention to technical excellence and good design enhances agility,” is one of the principles of the Agile Manifesto. In retrospect, at their ten-year reunion, at least some of the original authors of the Agile Manifesto felt they didn’t state this strongly enough.

I believe technical excellence doesn’t just enhance agility, it enables it. Cobbling code together in iterations the way most developers write code in a traditional development environment, with little attention to technical excellence, can incur so much technical debt that development grinds to a halt. I’ve seen many teams get into this situation, not right away, but by their fourth or fifth year into development things slow way down.

What is technical excellence? Given the state of our industry and the low success rates reported by study after study, I’d say that most developers don’t know what technical excellence is. This isn’t their fault. We haven’t been taught these things in school and we don’t generally agree on a core set of standards and practices.

self-organizeSo asking teams to just figure it out and self-organize can often set a team up to fail. But this is what Scrum says and many ScrumMasters are under the illusion that developers can just figure this stuff out, even though much of technical excellence is in direct opposition to what they were taught in school.

Whenever I get to teach for one of my clients on the East Coast, who hires a lot of entry level developers, I can always see some of my newly graduated students chuckle in the corner when I tell them that excessive “what” comments (comments that explain what the code is doing) can be bad because the code itself should express what it’s doing. They’re surprised. They say they were told by their professors that as long as every line of code has a comment explaining it, even if the code is obvious (like “x++;”), then it doesn’t matter what the code says. But professional developers know this to be a bad practice.

When I ask developers, even senior developers, what the SOLID principles are or what methodologies they follow, I often get blank stares. These ideas should be top-of-mind and considered with every line of code we write. I’m not talking about volumes of information, just a few dozen core principles and practices. But these things aren’t universally known in our field. So asking developers to “just figure it out” may not work as well as management might expect and that’s the case on many of the Scrum teams I’ve observed.

Instead, give them the resources to be successful. Build a library of useful books (there are many). Bring in a class. Hire a consultant. Find someone who’s been there and done that so you can learn from their mistakes without having to “reinvent the wheel.” It’s true that this is what I do for a living but I’m not just plugging my services. There are plenty of other sources to get a team headed for technical excellence. One good and free option is to keep reading this blog as I cover several aspects of technical excellence in my posts.


David Scott Bernstein is the author of the new book Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software. His consulting company, To Be Agile helps teams adopt technical practices such as TDD, refactoring, and emergent design.

About the Author

David Bernstein has coached and trained more than 8,000 software developers from several Fortune 500 companies in the course of his 30-year career. His new book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software (http://BeyondLegacyCode.com), covers the core technical practices for developing software. A longtime special consultant to IBM, David trained IBM software engineers around the world, giving them the skills to write the next generation of applications and operating-system software, and earning one of the highest satisfaction ratings in the history of IBM corporate education. He is the creator of a wholesale bank-accounting software program that has become the de facto standard across the globe, as well as econometric software used to invest trillions of dollars. Over the past five years, David has coached and trained thousands of developers at Microsoft, Boeing, Vanguard and dozens of other companies in Agile development practices. David is the founder of To Be Agile, a Registered Education Provider for the Scrum Alliance, and trains Certified Scrum Developers in Scrum and XP development practices. To see a list of pubic classes offered by To Be Agile, go to http://ToBeAgile.com/training. You can contact David Bernstein at (206) 792-9700 or visit http://ToBeAgile.com. David’s blog can be found at http://ToBeAgile.com/blog. You can follow David on Twitter under his account @ToBeAgile (http://www.twitter.com/ToBeAgile). - See more at: https://www.scrumalliance.org/community/profile/dbernstein#sthash.td91w4KW.dpuf


This is an Agile Alliance community blog post. Opinions represented are personal and belong solely to the author. They do not represent opinion or policy of Agile Alliance.