Stream or Team?

I have been working in a scaled environment for a while and the addition of new teams is a regular occurrence.

Recently I have been seeing that what we call a team is actually a stream. In this context a stream is a priority of work that needs to be done in parallel with another priority of work.

Here are some tests myself and one team came up with to sanity check a new team based on our previous experience.

It's a new team if:

1) The team own their code base and can make technical decisions without upsetting, involving or discussing with anyone else

2) There is a backlog of work and the size of the domain ensures the team will have work for the foreseeable future

3) The team can deploy whenever they need to without needing to plan or consult with anyone else

So let's go through some of the learnings that led us to these statements.

The main part of this is around autonomy and responsibility. Picture a team that realises a significant change to the way they branch their code would solve problems they are having. The empowerment we want to give is that they can act on this insight and change whatever they need to change to make them more effective. It's good for them and for business since they waste less time.

Imagine now that they have to validate this change with some others. Worse they have to persuade them that this will help them too. Decisions by the team need to be backed with the autonomy to make those changes as well as accepting the responsibility for doing so.

If it doesn't work out it only affects the people who decided it and they hold themselves accountable for the decision. This is why autonomy and responsibility are twins - one makes little sense without the other.

A repeating thing I see is the call for feature teams to be spun up to focus on a specific deliverable. This often ignores the longer term effects of this decision, namely who will support this new feature once it has been delivered into production. In my opinion, this requirement is best handled by the team who created it to avoid hand offs between support or ops team that might be present in the business.

Longer term side effects could also see knowledge about the feature lost as the team is dispersed and the feature is no longer actively developed. Different strategies need to be used in terms of documentation and testing as we need to ensure we preserve the feature, do not regress it and are aware it even exists. These all problems get worse with time - the longer we don't work on something, the more it drifts in the realm of fear and 'legacy'.

Ensuring work can easily be deployed into production by a team is fast becoming a standard in fast moving organisations. Allowing teams to do this whenever they need to is a key enabler in them producing high quality software with lower risk. Inferred in this ability to deploy is the ownership of the environments that make up a teams path to live.

Any sort of sharing or gating of systems that help a team get feedback on the quality of their software is counter productive. The team need to own these too, allowing them to change their ideas and strategies in line with the problems they need to overcome. Some gates may be necessary, such as change control or regulatory requirements but they can always be adapted and tuned to help developers as much as possible.

Teams owning their area of the world and knowing there is a vision for them is a powerful thing. It helps us create a sense of purpose and belonging, along with all the disciplines we value in building and keeping this running. Forming a team around a transient feature is not the same, it feels 'different' and can miss the essential sense of ownership and responsibility that benefits the business.

Making sure the area the team work in is actually big enough is key here. Too small and any hope of keeping people challenged is going to be hard. Making it too large will also making it harder to ensure a uniform understanding across the team. Knowledge silo's form easily in larger teams and the effects are subtle. It can go unnoticed that a specific individual is an enabler for others since they are needed to start or complete specific types of work.

Following on with that thought, the architecture of what you are designing will enable or block teams from being able to form. It might not be possible to simply carve up an existing architecture and assign different parts to different teams. There are often shared components or services which do not sit neatly in your new boundaries. There is a reason why discrete, contained microservices have become more an more popular recently....

There are other strategies you can employ but they all have varying pro's and con's e.g. component ownership seems like a good idea until you cannot balance keeping the team supplied with work and building things the business wants - you cannot guarantee that every component has an equal share of new work. Making sure a team has valuable work to do is among the most basic requirements for a team, so having a team structure that does not make this easy does not make sense.

I use these tests whenever there is a requirement to add more people. There is a sweet spot for the number of people in a team but also the number of teams based on your situation. These reflect my own experiences and I'm sure there are stories that conflict. I would love to hear them - how do these tests sit with your own experience?

Debts and credits in your backlog

Once a month I feel like a rich man. On the day I get paid, my bank balance shows the fruits of my efforts in all their glory. This lasts a day or 2 until some bugger comes and swipes the lot!

In reality, I am actually poor. Like most people I have a huge debt in the mortgage on the house that keeps me warm and dry. This is a well-managed debt, lasting years that I nibble away at each month. 

If I were to treat my finances like a business on an extensive balance sheet then I would make my true financial situation visible. It would make me sad obviously, but if I want to know my true position then this is what I should do.

A POs responsibility does not lie solely in serving the customer. They must also align the customer’s requirements with their company’s vision. These are 2 perspectives but the developers give you a 3^rd which is equally important – they can tell you about all the things you CANNOT see and yet still affect your product.

Many POs I have worked with insist that the backlog should not have any stories that describe technical debt since they have no value. I would ask you to consider that the backlog is better seen as a balance sheet – it forecasts the future worth of your product.

So if we treat the backlog as a balance sheet, we can start to attribute the losses of not addressing technical debt against the gains of new features. It is actually the combination of these that describe the true position of your product and its ability to continue making you money. 

Our technical debts are ever increasing – this is either an active process which we decide on or a passive process through neglect.  Just like a mortgage, there is maximum we can afford based on our resources – we cannot keep increasing our mortgage forever.

If we don’t carefully managing our debt we might have to take out a more expensive loan to cover the costs over a shorter term. At worst, this could be one of those payday loans because we exhausted our credit with all other lenders who rely on us being sensible in order to do business with us.

Technical debt provides balance to your backlog. Viewing your debt alongside your credit allows you to make more informed decisions about what to invest in and when.