Which Teams Work?

Although writing software can be an introspective and individual pursuit in a commercial setting its generally developed by teams of people.

Different functions exist within the team all of which hopefully come together to form an effective code delivery unit.

In large organisations multiple teams will be born in an effort to further expand an engineering capability. This growth will usually involve decisions being made around the make up of teams and the division of responsibility.

What category of teams are available to choose from and what are the relative merits of each?

I think this very much depends on maturity, both as an organisation and of the product you are building.

Platform Teams

A platform team is focussed on delivering one entire tranche of an overall system. This may represent a channel by which you are in contact with your users, for example having a team focused on mobile development or one focused on a retail website.

This may also represent an essential sub-system, one that may not be directly visible to users but is essential to the success of your organisation, such as your customer database or you billing platform.

When your organisation, and its software base, is young and underdeveloped this concentration on building fundamental building blocks can be essential to developing something beyond vaporware and ensuring a focus on the definition of a robust and scalable architecture.

Developing in vertical slices may have its benefits in terms of delivering fully fledged solutions to customers, but some thought must also be given to scaling horizontally and joining up the components being built.

Feature Teams

When your organisation becomes more mature and you have a base of software that delivers the functions you need to deliver value then the platform model can becoming limiting.

It can create a bottleneck of dependency on certain critical components and act as a handbrake on teams that need to source functionality from these important sub-systems.

Feature teams look to break this dependency by creating cross-skilled teams that are comprised of expertise in many different areas that are brought together to achieve the delivery of a feature to end users.

In crude terms it brings experts in the necessary front end and back end technologies together to work under a single team umbrella, rather than requesting work from each other they complete stories together collaboratively.

Using feature teams can indicate a shift inside an organisation from constructing building blocks to trying to do something productive with them. But it can also put strain on maintaining a consistent architecture and is particularly resource heavy when multiple teams require a particular expertise.

Consultancy Model

I think there can be a third option to try and draw the benefits of both approaches whilst trying to limit some of the drawbacks.

I will refer to this as the consultancy model.

In this model a core platform team is responsible for providing continued development of a platform, they have an emphasis on progressing architectural concerns and ensuring the overall quality of the code base.

Aligned to this team are a group of consultants, they have an equal understanding of the platform as the core team and are equally invested in the same technical goals.

It is these consultants that are aligned to feature teams and work within them to ensure the platform they are an expert in can be utilised to deliver a feature, potentially making changes to it to facilitate this happening.

This consultancy model acknowledges that the collaborative agile nature of feature teams is a captivating proposition that can yield a lot of benefits.

It also acknowledges that someone must be thinking about the architecture and technical development of a platform, constantly modifying something to suit a particular need or developing in isolation and hoping for an architecture to emerge are potentially both recipes for a mess.

It probably doesn't solve the resourcing issue that can become prominent in a feature team model but at some point a realisation must be reached that there is only a certain pace of software development that it is practical to maintain.

It is possible under this model to move development resource around based on what is currently perceived as the most pressing need, either to facilitate feature development or to mature the platform and concentrate on sustainability.

As with many things you'll need to find your own way and discover what works for you and your organisation, the only important thing is to realise its something worthy of your effort to think about and plan for.