A foundation of team practices for new teams
An opinionated set of practices as foundation for software development teams
It's not everyday that we setup a team from scratch. But when doing so it's interesting to consider what practices to include in the foundation of the team. In the end we still need to listen to the team members and adapt to what works in the current condition. But it can be easier to start from a baseline and make changes than starting from a blank page.
This is an initial post covering the foundation on a high-level. In later posts I plan to dive deeper into the rationale of some practices listed.
Below is an opinionated list of practices that I would include as the baseline of a team. Of course each practice need to be reviewed based on current conditions to make sure they make sense.
Speed of learning, continuous discovery needs to be an integral part of any user facing development team. Team members need to understand the value of learning and how speed of learning needs to be prioritized. A bit simplified but; Is something good enough to uncover new learnings? => Release it
Outcome over output, a feature being released is sure something to celebrate but the aim of the team is to reach outcome. A released feature with no or unhappy users has little to no value.
No estimates, to avoid estimating functionality that we have already committed to building. There's value in estimating on feature/project level to iron out priority but after that we are only getting diminishing returns.
No deadlines, a product development team will not benefit from deadlines so avoid them. Only use deadlines when there is a high external impact that will happen if the deadline is not met.
Kanban, is for most product teams the more suitable way of structuring work. Some iteration cadence is still needed for planning and other ceremonies but what has been completed at the end of one iteration is not the goal.
"Off-board" time, many teams struggle with planning, refactoring and cleaning out tech debt. We know we need to take time to make technical improvements. With off-board time we make sure that a healthy level of technical improvements are always being done. I believe it’s easier for a Product Manager to commit to say 15% time on technical improvements instead of making a decision on a specific technical improvement.
Zero-bug policy, by setting a strict definition on what is a bug and what is an improvement. And, afterwards aiming to resolve all known bugs. This practice makes help us towards higher software quality and how a clear description for how to prioritize bugs.