Once you’ve worked on a few different software projects, you notice that different processes tend to work better for some and not others.
For example, you may have experienced the pace and immediate feedback of working on a brand-new capability, made possible by the seeming lack of process and a focus on writing “just enough” code to make the feature a reality.
In a different software project, you may have spent time sweating the details and producing code with a perceived high level of quality. You did this because you understood the feature, the goals were clear, and the constraints guided your development.
What’s interesting about these different software projects is that it can be the same team that works on them. Furthermore, we often see that a single project may move through these different phases as we learn more about the product or services we’re building.
Both Simon Wardley and Kent Beck recognised these patterns about eight years ago.
Beck wrote about the Explore/Expand/Extract approach to product development in his blog post “The Product Development Triathlon” in 2016. This approach looks at moving a product from a set of experiments looking for a possible return to dealing with scaling and solidity for long-term supportability.
In 2015, Wardley wrote about “Pioneers, Settlers and Town Planners” as a way of thinking about product evolution and how this impacts teams.
In both cases, the common theme is that different skills, people and processes are needed to progress with products at various stages of their evolution.
What’s interesting from both these pieces is that they both suggest that we need different people to take a product through this evolution successfully. But is this always the case? Or could there be scenarios where one team could successfully evolve a product or service through this lifecycle?
If this is the case, the team must be adaptable. Adaptable in the way they think about the problem they currently face. Flexible in the amount of software delivery process they apply to solve these problems. And able to think about code quality as something they can tune relative to product maturity.
So, can one team do it all?
Achieving this level of adaptability isn’t easy. First, as managers, we must understand that projects at different phases require different mindsets and skills. Then, we must plan for these changes, moving work to more suited teams or adjusting a team’s make-up as the product evolves. Only by doing this can we ensure that we’re successful with our projects as they mature.
