When the impact a team can make diminishes
Long-running agile teams continuously improve a service addressing user needs but what happens when the impact of each improvement starts to diminish?
For organisations that are struggling to shift to more continual improvement of their services, it might be hard to imagine that the long lists of opportunities they aren’t getting to might one day be solved and their service is providing excellent value for users.
But for many user-focused organisations, this is where we eventually arrive. It may at some point seem adequate for a team to understand the users they serve well and to iterate on opportunities to address their user needs.
For the sake of example let’s think about a team tasked with improving an important part of the user experience. Let’s call them Team Fantastic. For software-as-a-service (SaaS) it’s common for teams to use the usage patterns of their user base as an indicator of what is working and what is not.
In the early days, Team Fantastic periodically would stumble upon an improvement which results in significant positive uplift in the critical success measures they have established as leading indicators they are serving their users successfully. This might be as more users start using the service or existing users get more value from the service.
This might be the pattern for a long period of time, especially in globally relevant, sophisticated services with many possible opportunities to improve the value for users.
In organisations with multiple long-running agile teams, there may be teams with different groups of users they are serving or the same users but different parts of the experiences they are consuming from your platform.
Assuming the team is productive, adequately resourced, and capable of learning what is working quickly will reach a point in time. At this point in time, the opportunities in front of them may offer less improvement than the opportunities in front of other teams.
It’s not uncommon for teams to continue addressing the opportunities they find. After all an improvement is an improvement, isn’t it? The trendline for all the important metrics may continue to lift, just more gradually and by ever smaller increments. I call this phenomenon ‘death by incrementalism’.
Competition suggests that this situation won’t continue forever. It’s just that the areas where an organisation needs to compete aren’t always going to be in the same areas.
This scenario suggests there’s a valuable relationship between how the organisation manages its strategic objectives and progress and how that interplays with the opportunities each team is focusing on.
It’s a rare organisation that is not constrained in some way by the resources it has available to bring to bear towards achieving its imperative. How the organisation signals where its most critical areas for improvement are and how it understands how well it is doing in the marketplace and in addressing the needs of the users they serve is critical to its effectiveness.
Incrementalism is not always bad. Agile and Lean software product development are systematised approaches which often take the form of incremental improvement. Of course, agile value delivery doesn’t have to be limited to only incremental improvement of value, there are many different ways to slice the value a team delivers to validate they are on the right path. The change they seek may still reflect a leap. Anyway, that’s probably best kept as the subject for another post but I thought it’s important to acknowledge that agility is not only synonymous with incrementalism.
When incrementalism becomes a negative is when the improvements are largely immaterial to the users and their needs may be in areas outside the remit of the team. Team Fantastic are not making fantastic improvements anymore. Something needs to change. There are many different ways this could manifest, beyond the scope of this post.
In the ideal scenario, the team itself has enough context about the organisation’s strategy and is making adjustments to pivot before devolving into a pattern of diminishing returns. Occasionally it may be the natural lifecycle of a service where the investment in the service is no longer a relevant part of the value the organisation provides its users. No team or service lasts forever. Teams disband, find new missions, and move on to the next opportunity to do something meaningful.
Have you experienced this at an organisation you were at or within a team you were part of? How long before something changed? What was the catalyst? Share your experiences in the comments.
Much better terminology for what I am describing and where it leads here: https://medium.com/@ElizAyer/enshittification-as-overproduction-in-software-part-2-overproduction-in-the-product-lifecycle-99584e8da458