How to structure a software development team

Here at Fluent we regularly juggle multiple projects across several products for a range of clients. We have learnt (often the hard way) the value of a well structured development team, guided by an efficient project management function and would like to share some of our findings in this series of blog posts.

So if you are struggling to deal with bugs in an agile workflow, have too many tech leads but not enough developers or can't tell your epics from your features then read on.

Fluent is a software development agency based in Cambridge, UK. We are a team of designers, developers and project managers building software, apps and websites for a broad range of medium to large organisations.

Projects vs Business As Usual

Whatever your terminology, software teams always struggle to balance the delivery of project work (new features) with day to day maintenance work (keeping the lights on)

There is an inherent tension between new features and old fixes, the important versus the urgent:

• New features give visible results - and the business likes results - so it can be prioritised or better funded.
• Project members may prefer to work on new features because they are exciting.
• Bugs may be in "someone else's code"  - so responsibility is blurred.
• Fixes and enhancements can get approved quicker than big ticket items - so product people try to use it as a backdoor for getting features built.

Without due care and attention given to both sets of priorities, there is a risk that functionality is lost or new features never arrive.

We find it helpful to create distinct work streams - which may include seperate contracts or budgets, personnel and release processes. For example:

• Project team(s) - focused on building the next new shiny thing.
• Maintenance team(s) - looking after Business As Usual - fixes and enhancements to support everyday usage.

Project teams

This can be one or more teams each with a Technical Lead and a Project Manager (more on roles in a later post). The project team should adopt an agile scrum approach to development, with the features clearly defined by the Product Managers and organised for development by the Project Manager into stories.

Project teams need to support the new features through development into production (including defects not live bugs).

Maintenance team

Usually only one team per product, this team is responsible for proactive maintenance and analysing and fixing bugs in the live environment. Issues are managed in a kanban style - prioritised by a project manager - and can be raised by customers via a helpdesk for triage by the maintenance team.

Bug fixing does not need to be planned, bugs shouldn’t be estimated, there is no sprint. The benefit of kanban means a constant stream of fixing the most important issues, shipping frequently and independently of new feature releases.

Some points to consider when resourcing a maintenance team: 

1. It is a good way for newbies to learn the ropes, because issues may occur in any part of the system.
2. It suits those who like a light, transactional relationship with their workload. Issues can be picked up and completed indviudally without requiring a larger investment in team building.
3. Working in maintenance for too long can dull your creative edge, so consider resourcing your maintenance team as part of a wider rotation with product teams.

Project Management Systems

There are endless systems on the market which promise Project Management (PM) nirvana. Safe to say, a poor system used well is better than a great system used badly.  The key thing we find is to consider who will be using them. In the context of software delivery, a system like Jira for example is the right tool for project managers and developers and the wrong tool for product management. To capture business requirements and refine them to workable stories, then consider a separate high level tool to manage this.

Development teams often struggle with the volume of activity in the backlog -  the noise often drowning out what is important. Don’t let the backlog become a dumping ground for ideas, ensure that new feature requests only come from the Product Managers and that the detail is imported from their own Product Management tools so you know the requests are genuine, well thought out and approved to go.

Here are the fundamentals required of any system to successfully deliver code.

Product or project

Most management systems start with a product or a project. These should be as distinct as possible, always aim for fewer high-level products / projects and use other tools (see below) to distinguish between different areas. For example, a big application with a CRM, public-facing website, payment system and reporting suite should all fall under one product / project i.e. Product x, and the various areas can be distinguished by using labels or components. This is because all these areas have dependencies and interactions with each other - they are not independent products or systems.

Backlog

A backlog exists per product and contains all of the individual pieces of work that need to be done (often called issues) in priority order. Review the backlog weekly in conjunction with Product Owners to ensure the next phase of work can easily be planned by taking the top priority issues from the backlog.

Boards

Whilst a backlog is a priority list of all the work to do in future, the work currently in progress is shown on a board. In an agile world that is either a scrum board or a kanban board.

Issue types

A simple tag that identifies the type of ‘issue’. Often these are the best way to segregate workload between new feature and maintenance teams. For example:
A maintenance team kanban board should contain all issues with the issue type of:

• Bug
• Maintenance task

A new feature team scrum board should contain all issues with the issue type of:

• New feature
• Improvement (to an existing feature)
• Defect (an issue identified in code still under development)
• Task
• Epic (see below)

Epics

In short, an epic is a “New feature” issue type but one that the team feel cannot be completed within a single sprint. It acts as a parent case to collate together smaller new feature tasks that will end up delivering the epic. If a standard issue is a short-term task that stays around for a few weeks, then the epic is a medium-term issue type, one that will be completed but may take longer.

It is likely that the Product Management team will focus on epics, and once all of the user stories for the new feature have been gathered, the Project Manager may wish to list the stories individually and link back to the epic. Occasionally an issue may be considered a new feature until the sprint planning meeting where the developers all agree it is actually a much bigger piece of work than originally envisioned and it becomes an epic at this point.

Components

A handy tag that can be added to issues to identify what part of the product the issue relates to. For example, payment processor, public website, database. Using components wisely prevents the need to have multiple high-level products.

Labels

Often useful for tagging an issue by any means other than the above, for example:

• The type of work that is needed - Dev, UX, Design.
• The issue source, i.e. helpdesk, UX workshop.

Roadmap

Having said that the chosen software PM tool is the remit of Developers and Project Managers and not product people, it may be useful or sufficient to collate current and future epics in a report or in a high-level board of its own. This will give the development team visibility of what’s coming up next and act as a point of quick reference for observers.

Conclusion

In summary, keep your maintenance and new feature workflows separate, rotate team members between the two, make sure you have a well-structured workflow system that the team understands and communicate.

Next up

In our next blog post in this series we will focus on roles and responsibilities within a software development team. For more information and advice on how to structure an agile development team and project, please get in touch.

Want more tips on digital product development from people at the cutting edge? Follow Fluent on LinkedIn and keep learning