Stop me if you’ve heard this one. A product struggles with quality and stability, and a mandate comes down from on high that quality is now Priority One. Checks and balances are put into place, cultural adaptation begins, and slowly quality and stability become a point of pride instead of pain.
In the process, innovation and creativity are compromised.
This is an acceptable balance during the time when the product quality was the major concern. But as quality disappears as a market differentiator, new features and organizational agility take over.
People may be used to slowing down change as a way of preserving quality, and we as managers are now asking them to speed up change (while still preserving quality).
In a recent hallway conversation, I referred to these change-resistance behaviors as anchors. Left unchecked, these anchors can paralyze your product development. Here are a few I’ve seen over a handful of product releases on different teams.
Scary Estimates
Years back, a team I was on had posters up defining what “done” meant. It talked about code reviews, unit testing, integration testing, documentation, etc. It reminded people of everything involved in turning their code into a product, to increase accuracy of estimates and improve predictability.
You can spot a developer from those days because they’ll ask you, “Do you mean ‘done done‘ or just done?”
Now, maybe all you want to know is how long it would take to code up a prototype, but you’re still getting a “done done” estimate. Or maybe everyone in your organization is padding estimates for fear of being too optimistic.
Challenge your estimates, so you can understand them. Make sure everyone is speaking the same language, even across team boundaries. If one team is talking “done” and the other is talking “done done” you can run into some real friction.
Handoff Halts
As a way of forcing communication between teams (and introducing accountability), an organization may enact heavy-handed handoff processes. If you find a lot of “I can’t work on that until I hear back from XYZ team,” this may be an undesired anchor for you.
Do you need a fully functional unit-tested API before you can begin coding, or can you make some progress with a header file? Do you really need the specification approved by that entire list of people before you can begin prototyping? Can you stub out functionality you don’t need and get some advance testing while still wrapping up coding?
Handoffs prove that teams are fulfilling obligations, but they shouldn’t disable progress. Sometimes it takes someone “outside the process” to recognize the difference.
The Churn Defense
Towards the end of product development, even well-intentioned changes are often rejected because they cause code churn in well-tested code. This makes sense, even if it’s unpleasant when it happens. But when you start hearing the churn defense at other points in the life cycle, your team may be overcompensating.
Especially in an environment of solid testing, refactoring should be welcome during good chunks of your development cycle. The payoff is generally worth the risk. Don’t be afraid to say, “We have enough time to do it right.” A manager I used to work with had a very measured way of saying this, forcing everyone to recognize that we weren’t quite in panic mode yet.
Intentional Anchors
I’ve described a few ways a team can get held up by unintentional anchors. There are more (but this post is already long), and I welcome comments on them!
There’s another issue, though – by introducing these anchors into the system, your organization has given everyone the ability to halt undesired change. Some people may abuse that ability to “covertly” influence the direction of your product. This, obviously, is a much bigger danger sign. You’ve got a broken process that people feel the need to work around instead of with. And that’s an entirely separate issue requiring a lot more investment on your part….
