Features, Quality, and Cycle Time

It's no secret that I'm a big fan of adaptive leadership principals and techniques. Here's a great talk by Jim Highsmith from last year on continuous delivery, metrics, and measurement.

Jim makes a great case for the importance of quality and the inherent flaws in trying to balance business outcomes against technical outcomes.

Hiring into a Flawed Culture

When it's time to hire software engineers, we don't often stop to take a look around. In some cases there are dirty dishes in the repository, laundry piled up in the build system, and neglected broken tests strewn about the front yard. Beyond the obvious technical debt, that's not going to help attract your next best engineer.

For new hires getting acquainted with your codebase and practices, they start by ramping-up a development environment for themselves. They want to know where to find development data. They wonder about coding standards. They look around the codebase. They are assessing where the bar is set within your engineering team, and more importantly, on what level they need to perform to not disturb the development culture of the team.

Will they find broken windows? Even one developer throwing rocks at windows and ignoring the disrepair in your team ensures a steady increase in software entropy. Perpetuating that practice with new hires will likely, over time, destroy much more. Without a healthy development culture within the team environment, there's a high likelihood of new hires poisoning the team's efficiency further. The team management needs to break that cycle and address the issues head-on. There's never a bad time to look around, do the dishes, put away the laundry, and cleanup the broken tests!