Working together

Once there where two kids next to each other, playing with toy cars in a sandbox. Their parents were in joy because they saw their kids playing together. But where they? The kids played with their own toys in their own patch of sand. They didn't play together, they just played next to each other.

A couple of years later, the kids sat in the sandbox again, but this time they shared their toy cars and build a road in the sandbox. Now they just didn't sit together, they were actually playing together and had a lot of fun.

Most teams work together as the little kids in the story, they don't actually work together, they just happen to be in the same team. They pull their work individually from the worklog. They are just individuals sharing a desk space. Each morning during standup they tell each other what they did, and no one has a clue about what it exactly is they have done or they don't care. 

Some engineers put their name on a couple of items to claim them as future work. When they have one item done, they move on to the next. Others finish their work and pull stuff from the backlog into the sprint because there are no free items to work on. See where this is going? Not everything the team committed to is done but extra stuff is delivered as well. This doesn't fall well with stakeholders.

What can we do about it? First of all no team member can have more than one story on their name. Second, in the daily scrum we talk about the work that is on the scrum board. From top right: the stuff that is almost done, to bottom left: the stuff that still needs to be done. We ask ourselves: "What can we do today to finish this story". Then we ask if anyone wants to help finish it, together. As we progress through the stories in the end we run out of engineers.

So now we have at least two engineers on one story. We need something to enable us to work together. The idea is that everybody participates in fixing the story. We use pair or mob programming to accomplish this.

With pair programming there is a single driver behind a computer and there is one or more navigator who sit close to the driver. The driver is just inputting in the computer, they put in their implementation. The navigator(s) talk about the problem and try finding a solution. Every once in a while the driver switches with a navigator.

When we use this setting we can skip peer review, we are peering the whole time, so there's no use for that. Because more brains have worked out the solution it is of better quality which result in less incidents. And most importantly we shared knowledge and learned from each other. 

Below are a couple of resources to have a look at, the first is Stacy who talks about pair programming, the second is an article about mob programming on medium.

Stacy Cashmore: How to really work together as a team

Sam Fare: I did mob programming every day for 5 months.

The cascading effect of the DevOps way of working

When you are going to work in a DevOps way it all starts with removing the first silo. This means removing the wall between Dev and Ops by putting them together in a team. The consequence is that the whole team is responsible for change and run. When the whole team becomes responsible, no individual can fall back on their role, they are all committed to the cause. Dev can do Ops, test can do Dev, Ops can do test and Dev and so on. This means more collaboration in the team and less push off of work to another role. As a DevOps team you are all in it together.

Working together is only possible if it is done in a small team, and with a small team I mean no more than five engineers (I like to call all team members engineers and not by their role). I state a team of five is the best, a team of three is minimum. With five it will still be a team, with six it will become two teams of three. Six or seven is still possible but communication and therefor collaboration will become increasingly harder. 

If you have smaller teams, you also need smaller software components and with smaller components you need more interfaces. These interfaces are twofold, one is the technical one with APIs, versioning, release cycles and so on. The other is the communication interface. How do you, as a team, communicate with other teams, how are your dependencies organised? You need to think about hard and soft dependencies and come up with a plan. Hard dependencies are those that make your team wait for work from another team or individual. Soft dependencies are those that interface with another team but don't require any work from another team. One of the goals for a DevOps team is to lessen hard dependencies and turn them into soft ones. This can only be done if it is clear who your teams customers are, which is one thing the team should know and investigate.

Working in a small team means a lot of collaboration, you need to share information and to improve sharing it is wise to minimise the work in progress by introducing a WIP limit. A WIP limit is a limit on the amount of work that can be in progress. If you need to learn a lot, make it a low number, so all team members need to work on the same thing together. One of the most errors I see is that every engineer works solely on items of the backlog not sharing knowledge and information. When two engineers work on the same item, they need to communicate and explain what they are doing, teaching the other one about their ways and maybe even learn something themselves.

It can happen that an engineer can't collaborate and that the WIP limit is reached. The purpose of DevOps is not to be as efficient as possible (max. resource utilisation) but to be as effective as possible (max. customer value). This means that when an engineer isn't working on items on the backlog, they should investigate improvements, refactor or learn.

Investigating the way of working and finding new ways to work leads to better processes and automation. When a DevOps team starts automating, many quirks in the process will be found. By solving these the quality of work and the speed of work will increase. 

So what are the steps to take?

1. Form mixed teams with the disciplines needed to convert customer requests in a usable product or service
2. Find out all the dependencies of the team
3. Make communication plans with other teams, technical and social
4. Introduce WIP limit to increase learning
5. Automate

Let's start doing DevOps!