Team structures

The last 11 years we have tried out different setups for the development teams, looking for the one right setup. Actually, now, I think the right approach here (borrowed from others) is to address team structures as a product development. In particular, to do incremental adjustments ('developments', 'experiments') a keep track of these through release notes and retrospects.

This is an attempt to (posthumously) create these release notes/version history.

Version 1

We were three developers and we split the responsibility based on architecture. There was no over-all lead, but we had an IEEE requirements document that we with others had created.

This was a time where responsibility was very clear and code-ownership strong.

Transition driver: It did not make sense to drive all projects with a single developer owner, it would be too slow. New functionality needed to be implemented by a group.

Version 2

We instigated Scrum, we had the product owner and scrum-master roles. A single team.

I think everyone felt good about having clear task lists. Also clearing responsibility for non-code work, such as doing meeting notes, setting up and maintaining the development stack, taking budging decisions.

Transition driver: We started a new code-base, a new issue tracking project, and dedicated split of the developers. But kept the single Scrum team structure. The thought was that it would create too much over-head having two teams, also we thought the knowledge transfer would be best served for both groups to continue working as a single unit.

Version 3

It became obvious that during planning, demo and retrospects half the group kept silent while the other group went through their development and visa versa. Time was being wasted, people were bored. So we split into two Scrum teams although keeping a single product owner and scrum-master.

Transition driver: We started getting more and more load from the service department and we were starting seeing more customer specific development projects. We started out by allocating fixed amount of time and a dedicated developer for 3rd level support issues. We called this role "batman" at first and later "the hat", it rotated between the developers, one having the role for the full sprint.
It was rather artificial allocating a fixed time slot for 3rd level support since it was rather unpredictable how much time would be needed. Frequently this would mess up the burn-down chart and could deteriorate the commitment of completing sprints.

Version 4

We created a specialized 3rd level support + custom development team, called Quicksilver. We pulled out all bug and custom development issues from the Scrum boards and put it on Quicksilver's Kanban board. We populated the team with the two most senior developers. They also got the go-ahead to do the refactoring they thought necessary to ease the future maintenance burden.

Transition driver: The developers on the Quicksilver team resigned. 

Version 5

We restructured the teams into three. This was actually the second attempt where we went from one product owner to three. We discussed quite a bit if we should do this split based on code-bases/architecture or if we should try to do it based on cross-code-base features. The first option won because we thought code ownership was more important then having more flexibility in creating teams around end-to-end functionality. We were still doing quite allot of maintenance and that usually meant going into closely contained areas of the code. However, the latter option has a greater appeal to top-management because they figure that it will give them greater throughput of new (sell-able) features.

There are some versions missing, one is where we when for the first time from a single product owner to three. And first placing them within the teams and later moving them into the sales department putting greater responsibility on the teams. The distribution of responsibility between product owners and the teams is a topic belonging to a blog of its own.

Also missing are our attempts in incorporating testing into the development, by letting the developers do it, to having a tester picking up issues as they complete within the sprints, to have complete sprints tested. This is also a topic that requires a dedicated blog of its own.

Lastly, there is also how the team organizes its work internally. Should everyone be able to do everything, or does it make sense to have some specialization, if, then to what degree? We have done some experimentation here as well. Blog++.