Microteams for Microservices

Over the course of this year the GoToAssist team in Copenhagen and Karlsruhe has been trying out a cross functional micro-team development process. This post explains what we were doing, what changed, and how it’s working for us now.

At the beginning of 2015 we had a completely new team working on GoToAssist Service Desk and related projects. We were in a new location, co-located and with mostly new members. Yet we were still struggling with the processes that were in place, designed for a small team of remote workers with a long relationship.

Something needed to change, and we were not sure what. So the first thing we did was to remove nearly all the processes. We had one large standup every day, and a subset of the team groomed stories and tasks. We let the chaos begin.

It was a lot easier to be an expert on chaos […] mostly because it made really good patterns that you could put on a t-shirt.

Terry Pratchett

Architecture

At the same time we were discussing new ideas for future architecture. Our new technical lead, Christian, had exciting ideas for a message driven microservices architecture that the new team had bought into. We were talking about isolated services, about not being concerned how each service was implemented so long as we knew the interface. Different engineering groups in the company have their technology preferences, and the new architecture lets us choose the technology, the tools, the method for each service.

The seeds of where we could go with processes were already forming in my mind.

Split by language

“I wouldn’t say we went into this new process thinking it would work.”

When our lack of process became too much for the team and management to bear, we decided to start running sprints again. We knew that a team of nearly 20 was too large. Our first attempt at a split was along domain lines. We had a team of Rails engineers, front-end engineers, iOS engineers, and we were to let the designers continue with their own processes as they were already working well.

So we created 3 backlogs, had 3 sprint planning sessions, and kept the giant standup.

I wouldn’t say we went into this new process thinking it would work. We knew the disadvantages of segregation. Something had to be done, and we couldn’t see clearly how to split into smaller teams. At that time we were mostly working on one project with some major features in the pipeline.

The cracks didn’t take long to appear. We’re still dealing with the fallout of this reorganisation months after we stopped using it. Features fell between the responsibilities of each team, and priorities could not match up.

We fell back into chaos, or should I say anarchy. It seemed to work better. However, during this chaos two things happened that set us on a new course.

Hacking

write (a program) in a skilful or clever way

We needed to deliver a concept feature in a short amount of time to evaluate it’s market potential. To achieve this, an internal team was formed that was cross-functional, including a project manager, designer, iOS engineer, QA engineer, front-end engineer and backend engineer. I wasn’t part of this team, but their success and the way that was achieved really solidified prior thoughts about what we should be doing. This team moved to sit together, and they pretty much excluded all outside influence in order to achieve their goal.

Then we had an annual company wide event called Hack Week. I’ve written about Hack Week before. We had a retrospective with the whole team after Hack Week where we discussed our feelings on how it went. The most obvious takeaway from that was how much satisfaction everyone got from working in a small team that included all the resources they needed.

“Hack week? Are you all going horse riding?” — My wife

Split by feature

It might seem obvious to split up into cross-functional teams that tackle a feature at a time. It’s often been at the back of my mind as an interesting way to work. However, it does not come that naturally. I’m not sure we could have done it sooner than we did; it required a level of comfort in the team, and features that could be worked on separately.

Working on a new architecture has helped a great deal. There’s a really good feeling of co-evolution between the technology architecture and the process.

Externally we have one process now, but internally each team is very different. The teams themselves can decide how to organise. My team has only 4 people, and we sit together. There’s not much need for much formal process, and our stand-ups are discussions. We know what we’re doing.

Another team whose stand-ups I attend could not be more different, and yet it also works well. It is a larger team with members in two offices, so meetings always involve a remote element. They have adopted a very strict scrum process, and they have a strong scrum master (Stephanie) who keeps the team operating smoothly.

The large team had an offsite in Berlin for several days, with everyone traveling to meet up and plan together, to get the momentum going.

My team had an offsite at my house where we had cream teas and drank beer.

Werewolves

Our new way of working is not a silver bullet. Success is still to be decided. It feels like we’re moving forward now, but there have been problems, and there will be more.

First of all, it took perseverance. Not everybody was happy when we split along these lines because they lost a level of knowledge into what everyone was doing. People liked the big stand-up with 20 people, it was fun. We’ve started a weekly catchup breakfast-meeting for the whole team, to try and recapture that.

In the beginning some people had too many responsibilities and were split over teams. We only have one manual tester, and two test automation engineers, and so we did have to rethink our roles a little. We’ve now settled that each person should be involved in no more than two teams, and preferably mainly working in just one.

I would like to see the current teams finish their work and then have us split and reform around new features. That hasn’t happened yet, and I’m sure that is going to be hard the first time. Maybe we’ll have to force that sooner than later, or maybe we’ll wait until it descends once more into chaos.

Conclusion

I believe that people are happier when they have some self-determination. We’ve folded that into our architecture — you can write your services in whatever language you like so long as it interfaces with the rest of the system. If it does not work out, each component part is small enough that we can deal with it.

Now we’ve folded the same principle into our development process. Your team can decide how it works, so long as it interfaces with the larger group. If it doesn’t work out; we can change the team.