High Performing Teams: Where do the Risks come from?
Learning experiences from Lean Software Development
In this issue we’re exploring risk areas that can slow down your team’s development process. This is a combination of expectation management, building trust with business stakeholders and lack of experience.
Product and Engineer team relations are a mixed bag of unresolved tension, imposter syndrome and lack of trust. You need to be a good poker player and negotiator to navigate it.
Fear of Rejecting Features
Developers make an important decision every 15 minutes. If they multi-task, those decisions get spread around a lot. And forgotten. And re-discovered. When the team lacks radical candor to be direct or honest about the capacity of the team they will agree to anything when backed into a corner. They will lie to make the meeting end sooner.
This is a serious problem and possibly the most common in my coaching practice.
Solution: Read Radical Candor and Don’t split the Difference. They are short books. Learn to negotiate. Ask what the consequences are for rejecting a feature.
Producing Features That have no Market Value or Demand…
There are two types of developers. What I call “Hobby developers”— enthusiasts who have made their coding skill a viable job and care about the artistic temperament of bringing something to life. Similar to a hobby-baker, they care about the flavour and presentation of their bread.
The other type are the business software engineers. They look at their craft like a profession. They think about the cost of materials that goes into producing something and how much they can sell it for. Programming skill meets business understanding.
The same goes for Product Managers. This particular risk appears when the hobby developer and a hobby product owner experiment on the market without being clear about boundaries. They aren’t out to build the best product like Steve Jobs. They are focusing on nice and tasty.
When this kind of experimentation goes under the radar it can spam your production pipeline with cruft, gunk and balast.
Solution: Make the market value explicit for features and stories— This is for client X. This is for pitching Y.
… And Not Removing Old Ones That Don’t
And often this has happened while you weren’t looking.
And you found out.
What are you going to do about it?
50% of the developers I coach have source code deletion anxiety. They want to remove unused features. But they can’t. They won’t. They are worried.
Solution: Remove code as a team activity. Seek to shorten, simplify or eliminate unused and obsolete parts of your code as a pairing exercise.
The Speculative Bubble
Business speculates on what target markets they want to enter—plural. Product speculates on the amount of features they’ll need to do that—wish lists included. Engineering speculates with abstractions required for future problems that might appear on the horizon.
I call this a bubble because it keeps getting exponentially bigger with each step of speculation.
Solution: Ask to have your team included in the first step of research and cut features aggressively. Every company I coached so far vastly over-estimates their need and ability to deliver on their feature plans by a factory of 3x.
No Ownership of Feature Maintenance and Longevity
Your team’s execution pipeline isn’t all about creating new features. Every existing feature has to be maintained. Kept up-to-date. Revised. Support and operations are an on-going upkeep to any seasoned team and that’s without counting the.
Every feature you add to the team’s repertoire will is cruft. It creates friction. New features will require more effort based on the amount of cruft. Worse even if the old features are badly maintained and lack quality controls like automated tests and acceptance coverage.
Solution: It’s easy to miss this when planning roadmaps. Keep a clear eye out as the team’s leader for when this happens and highlight the current operational overhead for keeping the lights on when offering the team’s availability for new features, experiments or operations.
Too Many Parallel Tasks Split the Team
This one hurts the most. When senior managers or founders disagree they create parallel value-streams that they want to explore. Without a clear merging of intentions and planning budgets managing this split becomes the responsibility of the team that executes on them.
This is difficult, especially when the team is already managing a high amount of cruft for its size or is understaffed. Parallel streams are most easily identified by some members of the team following a different board or set of priorities of if there are different modes of “busy” and unavailable.
A common anti-pattern is certain developers within a team not being allowed to pair or collaborate on certain tasks. This is commonly known as micromanagement by remote control.
Solution: Keep the team unit. When managing strategic plans ensure the team remains as a single unit without entertaining per-dev planning. When parallels are requested, let the team self-manage them by highlighting how the streams are connected and what external deadlines or dependencies drive the urgency and value.
The Team has Skill-Gaps
No team has uniformly distributed knowledge, experience and skills for each individual. When a team lacks a certain skill— or a skill is made unavailable by micromanaging someone away from the team— they will have to interrupt someone from another team and bring them on. This leads to waiting times which cause unnecessary delays on both teams, creating huge amounts of phantom costs and unfinished work. More on that in the previous issue:
