When talking about agile practices, the distinction between projects and products often comes up. The idea is that the limited lifespan of projects tends to be pushed onto the delivery team, which leads to the team being assembled at the onset and dismantled when the project completes. Agile practitioners advocate for a product view, where teams are dedicated to a specific product and deliver incremental value at a regular cadence, across initiative lifespans. This usually works really well, and I too favour a similar way of working in most cases. However, I have recently seen various examples of this idea being misinterpreted, which creates a situation in which teams struggle, largely due to their setup.
Why a product view?
When generally good ideas are implemented literally, it is often due to a lack of understanding. Looking at delivery through a product lens - with teams dedicated to that product - enables a whole set of benefits. Subsequent releases are just the next set of features making up the next version of the product. This means that teams stay with the product for a prolonged period of time, benefiting from what they have learnt about the system and the domain over several months and potentially several releases. They have also learnt about each other’s strengths and how to best work best together. All of this helps the team deliver value more effectively. The goal is to optimize the value, the way to do it is to organize the work around the team.
When it does not work
However, when there is not enough product work for a team, a product view can quickly lead to mayhem, especially when not understanding the rationale behind this view. I have seen several versions of having the product be at the center of the work and the team members being assigned to multiple products, sometimes even with its own Scrum setup, supported by product centric task boards. This requires those people to attend multiple planning meetings, standups, team reviews and retrospectives. They need to keep track of tickets or stories in multiple task boards and somehow need to decide for themselves what deserves higher priority than something else. In the end, there is not very much time left to actually deliver value… in spite of best intentions. This can’t possibly have been the idea behind the product view.
Team view to the rescue
Knowledgeable Agile practitioners do not advocate for a product centric view. They advocate instead for a team centric view. What is described above causes waste and stress. No one benefits, not the customer and not the team members. This way of working impedes flow of value and might even introduce quality issues. It’s not the fault of the environment, there are valid reasons for these teams to be responsible for multiple applications, systems or services (e.g. when supporting a variety of SAAS services to enable a business). It’s the team’s reality. Some think that agile practices don’t fit this team, which is also not the case. The challenge for the team is to organize themselves in a way that they can effectively deliver value in their reality, which really is what agility is about.
In a team centric view, the structure and processes are tailored to enable the team in their value creation. The tools are configured to create visibility of all the outstanding work, the work in progress, dependencies and the obstacles along the way. Teams should be able to look at a single task board and understand what is important right now, what needs attention today. Priorities are made visible for the team as a whole, across all the products, systems or services it supports and regardless of the way the work has been identified. The specifics of this setup depend on the type of work, the skillset of the team members and more. However, the principles are always the same: optimize for the team to safely get as much value as possible out the door.
Fit for purpose
When agile practices do not work, it is often because of a lack of understanding where their rationale is misunderstood or the required context is not known. Agility is in the first place about value delivery and continuously learning how to do better. It’s about applying the structure and practices that fit your specific environment and enable your specific objectives. If the practices you apply don’t work for your team, if the team is struggling with process rather than being able to focus on delivering value, then take a hard look at what is happening and explore ways to improve.