The definition of insanity is doing the same thing over and over and expecting different results.
variously attributed to Albert Einstein, Benjamin Franklin, Mark Twain, and probably others.
You've likely heard this quote before. It's a phenomenon that I see regularly with my clients. Growing teams are often stuck in the spot where they know what worked previously--and they know it's not working now--but they don't know what to do instead. So they continue to do the same things because one of two things is true: Either they don't have any better ideas, or they have plenty of ideas but are stuck in analysis paralysis and don't know how to proceed.
Worse, it can be a compounding cycle. If your team is having trouble shipping code, that usually leads to pressure to work harder, faster, longer hours, whatever it takes to just GET IT DONE and out the door. Now even if you have ideas for how to fix the system, you don't have the time to devote to them. It's like trying to drive a car with a slipping clutch by mashing harder on the gas. If you're just trying to make it a few blocks to the repair shop you'll probably be fine. If you're trying to get from Berkeley to Sacramento (to pull a real example from my past), you're going to end up on the side of the road.
It's important to make sure that you have a system and capacity for innovation within your team. You can run long, prescribed, capital-R Retrospectives that follow a script and take two hours or more. These can be very valuable, but quite daunting if you haven't done them before.
Instead, start small. Put a 15 or 30 minute block of time on your team's calendar for voicing concerns and evaluating solutions. This can be a part of an already-occurring meeting, such as a Monday morning huddle. Ask three questions of your team:
- What did we do well this week, and should continue doing?
- What didn't go well, and could to be improved?
- What concrete ideas do we have for improving the items in question 2?
The key is to try something. Discuss the items just enough to determine what's simply worth trying. You're not looking for the perfect solution, just something that could potentially move the needle. At the next meeting, evaluate those efforts and their payoff. Figure out what worked and what didn't, and if any improvements can be made to what's already in progress.
Developers, by their nature, want to optimize things. If your team can build structure and focus around that tendency, you'll see a positive feedback loop emerge. The strongest, most performant teams are those that share a culture of team ownership and continuous improvement. Trust each other that you'll be able to evaluate your own efforts and improve their effectiveness over time. You don't need the perfect solution at the outset, you just need to take a step in the right direction.
Next time, I'll provide a strategy for identifying potential solutions to the problems you've identified in step 2.