You may have been reading the blog posts of my colleagues around continuous delivery including the motivation behind it, our focus areas as we transformed from annual to quarterly releases, and some process improvements that we implemented. Continuing this theme, in this blog I’ll write about one of the most dramatic changes that we underwent as a development team to support continuous delivery – the restructuring of the team itself into a new avatar that we like to believe is more agile and more user focused than it was earlier.

If teams have long running release cycles, it gives people a sort of sense of security. You think you have a lot of time, so you plan big features that span several milestones. A big feature is broken down into stories and tasks, owned by different teams. Each team delivers on its own stories and hands the feature over to downstream teams. People work on multiple features at the same time, and the same people also work on the defect backlog. Each team works on their assigned stories based on the ranking in the team backlog. So sometimes it takes months for a feature to really come together.

The Rational Team Concert (RTC) team was no different. Our development team consisted of several component or functional-domain-specific teams with each working on its prioritized team backlog. People within component teams worked as a unit, but across teams people and priorities were loosely coupled. This sounds good in theory, but in practice it would often mean that the same feature would appear in the Client for Eclipse IDE in an early milestone but in the Client for Microsoft Visual Studio IDE in a much later milestone. Or a cross-functional feature would have a story languishing in a component team’s backlog. With a year to tie up all the loose ends this could work but this was obviously something we had to change if we were going to deliver features every quarter without compromising on quality or content.

We started discussing ways of organizing our teams to meet these new challenges.

What became clear almost immediately was that for this to work, the whole of RTC would need to work on one prioritized backlog of features (Plan Items). Each feature in that backlog would need to be right-sized for a 4-8 week delivery. Each feature would also need to have the same commitment from across all the functional teams that would deliver that feature – a dedicated team in fact, who would focus only on that feature until it was delivered. Delivering a feature would mean design, implementation, testing, documentation, translation, field support guide, demo videos – the works! ‘Feature Teams’ would be responsible for all of that. Having Feature teams would ensure that as a team we were focused on the features we’d committed to deliver.

Once we conceived of Feature teams working on the feature backlog, we had to decide on the other equally important questions around the day to day running of product development: how would we reduce our defect backlog? Who would be responsible for builds? Answering forum questions? Working with support on escalations? Clearly, this too would need a set of dedicated engineers. This would be our Run teams.

If you think about it, this way of organizing teams appears so simple that it’s almost obvious. However in reality it was a huge cultural shift for us and there was the usual angst that greets change. People no longer would just work with the people they knew and were comfortable with. People were worried about being in Run teams, it wouldn’t be intellectually stimulating to just fix defects. People were also worried of being in Feature teams, out of their comfort zone, overly focused on specific features, probably missing the big picture. Some felt that domain specific features would get undermined in the process. There were many discussions within and across teams, and in the end, we decided to give it a shot.

Not surprisingly, it actually worked out quite well. We created some simple rules around Feature teams and Run teams at the start. We added some guidelines as we went along. Here are some of them.

• Run teams and Feature teams would be rotational – so folks who were in Run teams in one quarter would be in Feature teams the next.
• Feature teams could be cross-functional and distributed, or in the same domain and co-located – the important thing is to ensure that each participating location or time zone had more than one member in the same Feature team.
• Run teams could be distributed, but rarely cross-functional. Run teams would rotate responsibilities for builds, forum interaction, inbox management, escalation handling.
• For any release, a Run team would be staffed first, based on the size of defect backlog. The remaining people would then be grouped into Feature teams. This ensured that we didn’t regress the quality of the product by taking up more new features than we could handle.
• Feature teams would have regular scrums, often distributed, to stay on track. So would Run teams.
• Feature teams would have Feature team leads who’d make sure that the feature would be delivered on time and with quality. Run teams would have Run team leads who would make sure that we were on top of our defect backlog and meeting our quality metrics. These were not to be permanent positions or specializations. Everyone would need to play this role at some time or the other, to ensure that our values and processes are deeply ingrained in every RTC team member.

What we saw was that this impacted the team in many positive ways. First off, both the feature backlog and product backlog were managed more predictably, and developers weren’t walking that tight rope with a zillion things balanced precariously. This improved productivity and reduced stress. People weren’t forever rushing from features to defects to escalations, but instead were spending their energies on one thing at a time. Second, it created a feeling of ownership in the team for features rather than domain specific stories – an increased awareness of the product and what it takes to really deliver a product. And finally, with distributed Feature teams, people worked together with people from different geographies and domains – which was great as a trust building exercise across our development team.

So was the picture always rosy? Of course not. There were the usual turf wars especially at the start. It took us a while to work in close-knit teams with people from other geographies and other cultures. It also took us a while to figure out what ‘DONE DONE’ really meant for a feature – the other side of the story beyond just working code. In the end though we seem to have settled down into this new order of things quite comfortably, all said and done!

If you have your own experiences to share, around how you organized your teams to support more frequent releases, we’d be really interested in hearing those. Please feel free to comment below.

Please watch our blog for future posts in which members of some of our Run teams and Feature teams will discuss their experiences with this model of organization.