As “agile” and “product” development permeates more and more of mainstrain software development, I wanted to write about the prevalance of two team archetypes that appear (when things are functioning well… dysfunction is a whole other topic!). Outwardly, they appear to be made of similar roles, can actually end up with very different outlooks to delivering that software and are useful in different situations. This can make comparison hard and explaining the difference between the two difficult and less easy to understand.
In my experience during a ‘transformation’ (digital/agile/product/etc) there are many stages organisations, teams and individuals go through on their journey. On that journey, to what I would describe as a ‘product’ teams, a lot of teams and organisations get stuck in ‘delivery’ teams.
Firstly, lets take a model for the activities involved in defining and delivering software. At ThoughtWorks we often use the “double diamond”
Delivery Teams
The first step on your journey is probably to move a certain population of your users from role based teams to a form of cross functional team. What I would describe as a Delivery team. The first roles on this journey are often Delivery, Dev and Test followed by BAs, Product then UX. Which means you have a team who can effectively execute a solution.
If a team stays in this phase or this is considered the “end” of the transformation things can get very difficult. The Delivery team don’t really understand why they are building what they are building, even if they become very good at building it. Pressure to blur the boundary back towards the right increases so that teams don’t ‘build the wrong thing’ again so processes are setup and theatre between these two sides increases. The “define strategy” phase can happen months if not years before the “execute solution” phase meaning more and more boundary crossing and more and more pain when the solution is actually explored.
Good Delivery teams also understand the systems they build and how they fit into processes. They understand what the system is trying to achieve for their user. They can run, maintain and expand those systems.
Product Teams
Product teams can take responsibility for the whole “double diamond”
This can be quite an uncomfortable step for an organisation to take on its transformation journey. This is because all of a sudden we are facing into the chaos of the unknown and forcing the organisation to deal with the fact that a lot of what it did before was theatre to give the illusion of certainty. However, this step is the most important and the most valuable to organisations.
Often we describe this as “becoming user focussed”.
Good Product teams understand what their user wants to achieve and create a holistic process sympathetic to them and their needs as well as those of the organisation.
When I work with clients I often have to split these two diamonds up into “Discovery” and “Inception” phases. This is to allow for the necessary cross pollination of skills and domain expertise to happen. However, within a genuine product team, these diamonds should be happening constantly. At a micro level within tickets, at the macro level on the roadmap and in the middle with delivery of a feature.
If we are using something like a Lean Value Tree to understand our work, then its important that a Product team can get through a “bet” in around a month.
This means significant differences to how most organisations understand and break down problems that take multiple years to resolve which can be very hard to handle at an organisational level if it is not setup to cope with this change.
Summary
Transformation is a constant journey, and so its useful to be able to understand where you are and where you want to be. If you find your self ‘stuck’ in a Delivery team and unable to change things its important to understand whether this is intentional or by accident. You can then start pushing in the direction you wish to go.
In reality Delivery teams should be highly transitional (but often aren’t) and should either be working towards becoming a Product team (because the situation is such that this is valuable) or if there work has genuinly already deeply understood be working to understand how they can transfer their work to a commodity provider.
Appendix
Signs you are in a Delivery team
Often created by the first few steps on the agile journey, this team will have close collaboration between Delivery, Dev and Test. Dev’s will understand the importance of quality and will take responsiblitly for automated testing. Test will take responsibility for exploratory testing and will be able to generate risk based approaches to testing any solution or service.
Teams are responsible for a system/service or set of system and services. Often a complete user journey is spread across multiple teams. Operational roles have been taken on by the team, they will ideally look after their service 24/7. The team can help people understand the problem of technical debt. They may have 10 or 20% time in which to explore new ideas which are shown to people higher up in the organisation. They may have a good relationship with UX roles especially the more design orientated roles. BAs are often responsible for helping the team understand requirements and by the time a developer or tester first looks at a ticket a lot of work will have already gone into it.
User research often happens months in advance. The dev and test roles rarely if ever go to events that involve their user. The roadmap is often defined past a year in the future. The team have very little say over the large piece of work they are working on, but as that works break down they may have more and more say over how it is achieved.
The board used to visualise work is often split into multiple swimlanes so that high priority items can flow quicker. The columns are often based on roles or environments the code has to pass through. It focuses on ‘development’ and ‘test’ and so does not contain the entire value chain, often missing out the ‘ideation’ phases of work and the ‘observation’ releases meaning that some work is happening ‘off board’ and can be hard for the team to understand. A ticket is often “done” but not “done done”. Tickets often represent a slice of a set of tasks that a single role can achieve rather than a piece of value delivery to a user. Retrospectives often focus on the impact of other teams on this teams work which means sometimes retros can fall flat as the ability to change is limited.
NFRs/CFRs are often considered but then treated somewhat seperately by the team. Sometimes this delineated by environments (ie performance testing) and other times it is dileneated by dealing with another team (ie security or documentation tickets). Often the team has to produce documentation after the fact for some gatekeeper roles including (but not limited to) Architecture and Security. They may have to coordinate releases with other teams or be part of a schedule (like a release train).
People are often paid different amounts depending on the role within the team and their individual performance reviews are not intentionally linked to the teams goals. Individual contributers often generate prolific amounts of output, creating knowledge silos and reliance on specific team members for specific tasks.
Signs you are in a Product team
They have complete control of their own backlog. The backlog is no larger than a months work and it is relentlessy pruned and prioritised. Because of this retrospectives focus on what this team can change and actions are prioritised against all other work. The roadmap is only relatively certain for the next 3 months. The roadmap consists of a series of ‘bets’ rather than requirements and it is understood that each ‘bet’ can be scrapped as its picked up by the team.
Teams are responsible for the service design, delivery and operation of an end to end process or user journey with no handovers to other teams in that process. A deep understanding or production is encouraged across the team, and the events that happen in production regularly help form the backlog.
The team is free to use solutions built by them, other teams within the organisation or external providers.
At particularly gnarly points in time, especially were something is not very well understood the team often ‘mobs’, this can be on any type of task not just “typey-typey”. Alignment of vision is valued in the long and short term, the team actively work to compromise the tradeoffs between upfront design and delivery. Upfront design is mostly done ‘Just In Time’ and is immediately followed by attempted delivery of that design. This alignment is valued by the team as a way to achieve autonomy. Any technical debt can be assigned value in the same way as a feature and so can be prioritised accordingly.
The work is visualised on a board and the columns represent value add activities. Where they don’t the team are able to change their process as they need. There is only 1 swimlane. Everyone on the team understands how to get a ticket from begining to end and regularly takes responsibility for this. The board includes “ideation” and “release” phases. Releases are actively monitored and observed to understand the effect they are having. Releases happen independently of any other team.
Tickets often represent a piece of value to a user. Any key gatekeeper teams (like architecture and security) are actively involved during the key discovery and solution phases the team goes through. This means that NFRs/CFRs are integral parts of the individual tickets. It is unlikely that a ticket could be solved by a single person. The person responsible for getting a ticket through the board will have to bring in a variety of roles at different points to make it happen successfully.
User research happens consistently and regularly and the team are actively involved. The research that is happening is relevant to either something that has just been released or something the team wants to do next.
People are often paid similar amounts regardless of role within the team and their individual performance reviews are intentionally linked to the teams goals. Whilst individuals bring key skills to the team that no single other person brings, the culmination of skills from the rest of the team can cover that individuals abscence. Where knowledge silos occur, the team actively work to break them down.
Links used in article and as inspiration
The Double Diamond: Strategy + Execution of the Right Solution
https://medium.com/media/3ca50a105cac63b20d5b0952d7d84886/href
Top comments (0)