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?

Future Trends - Part 1

I like imagining what might happen next. I'm terrible to watch films with - you tend to get a running dialogue!

Recently I have be applying this past time to my day job, imagining what might influence what I do and the teams I work in. I have a somewhat quirky, vivid imagination so some of the things I muse on are possibly the stuff of films rather than reality.

At the same time we all know that much of what ends up in films becomes real at some point too, which is the loose premise I am going to stick with for the time being.

Bold statement No. 1 - 'virtual world' development environments will become the mainstream

So what do I mean by this.... basically the VR technology we are using will be used to develop software. The virtual worlds we see in MPRG's will be used for developers to collaborate on software using avatars and systems will be represented as 3 dimensional structures in the virtual development environment, allowing visualisations of architectures. Groups of avatars collaborate by converging on a shared space to allow them to share the same view of the virtual world. People can zoom into a structure to see the code that makes it work.

Part of this thinking was inspired by a talk from Jamie Knight, who works at the BBC. Jamie is non-verbal and described how communication works in his teams. Since he uses tools to type and speak, conversations are limited by technology. To combat this, he has found that if everyone else use's the same technology then it makes the communication easier.

I started to think about the limiting factors for teams in successful companies and realised that the physical location was probably the primary one. Your staff need to be in the same area as you in order to turn up to work everyday, tales of serious competition for candidates are not uncommon as companies tend to group in local areas.

Played out on global scale, this is massively limiting. The best person to work for you might not even be in your country! When we think politically, they may not even be allowed to move to your country - with realisation of Brexit, this could impact the UK in future years.

If anyone has been working with a fast growing company, you will know the massive nightmare that it causes when you need to find (and house) a large work force. The physics becomes the limiting factor - you can't find the people fast enough and if you can, you can't keep adding people to the space you have. And we know how everyone just loves an office move...

On the flipside, anyone who has worked with a remote team or team members knows the associated issues - we see problems with communication, collaboration, ownership and culture. It is such a well know problem that we simply advocate co-location of teams since this basically gives you a massive advantage.

For me, taking the entire development environment into a virtual world actually starts to make sense:

• Everyone would have the same level of communication and visibility, so it is up to the individuals to make this work. By giving people the same tools, we level the communication playing field - the location is no longer a factor
• You would also be free to employ people from where ever you chose - reducing your problems to timezones and language, something which international businesses have previous experience with.
• By allowing people to stay in their native country, businesses have the potential to offer much more competitive wages as it's actually the cost of living that they must meet
• We know this scales massively (look at gaming) - it is only how we organise and communicate that becomes the limiting factor.

So why is a Scrum Master seemingly committing heresy by talking about such a thing?

Teams are key in this world I am describing - it is the whole reason why I have thinking about it. For starters, this would need to operate in a high trust culture - which get's me interested. It is entirely possible you may never meet the person you employ. They may also be protected by local laws that do not match your jurisdiction. That requires a level of trust that is hard to find in most companies.

Many of the interactions I take for granted can't be applied in this world - eye contact and body language would cut down my levels of feedback, meaning I would need to think differently.
All interactions with my team would now be virtual:

• What would interactions between virtual team members look like? 
• Would we still use boards (with virtual stickies, obviously) to organise ourselves? 
• Would we create entirely new ways of visualising our work, leveraging our virtual world's unlimited flexibility? 
• What would stand ups look like? Would we need them?
• How does the communication scale - would we have virtual replacements for messaging and chat or something new?

What about the 'feelings' of our teams? In this world people who are frustrated or annoyed are easy to spot - a virtual world allows people to edit their emotions, even block them entirely:

• How can we create a culture of trust that would encourage people to display their feelings given that this would be optional?
• How would we build lasting relationships? Do our team building techniques travel in a virtual world?
• Would a lack of 'real' human interaction be depressing?
• Would it be hard to get people to work together given that they are not?

There is no doubt this could be massively empowering. Small companies could grow exponentially and we could always hire the best. Having people in multiple timezones could create a naturally longer day maybe having multiple stand ups to coordinate work between them. 

People could spend more time with their families and have greater flexibility as we build our businesses in environments that are as flexible as our creativity. Where people need to come together, they could choose to meetup at co-working spaces or any other space they deem appropriate.

Wouldn't these be the real internet companies?

Also See:
http://liberumvir.com/2013/07/08/a-wholly-immersive-dev-environment.html
https://ghost.org/careers/
http://www.ibm.com/developerworks/library/ws-virtualspaces/