How the ResDiary dev team is accomodating rapid scaling
As a company, we want, and need, to grow. For the development department at ResDiary, this means constantly evaluating our processes to make sure we can scale our output without compromising quality or the happiness of the people involved.
It is possible to increase the short term output of a department in bad or unsustainable ways, such as overtime, reducing quality or outsourcing. Cracks rapidly start to show after implementing these short term measures, however, and eventually the physical and technical debt built up will become overwhelming. At ResDiary, we believe that fostering a culture of autonomous teams, and putting a framework in place to support that culture, is the best way to grow.
Part 1 — Team Structure
We currently have a number of mature, well-functioning teams with extremely talented members. Everyone is co-located and there is a good distribution of experience levels, so we had a strong base to work from. We are hiring aggressively, but we’re also doing it sustainably so wanted to avoid pre-optimisation. For example, mandating the creation of Chapters and Guilds, ala the Spotify model, would have been pointless because our numbers aren’t large enough to warrant or support them. The question, then, was how could we keep the benefits of traditional fixed teams (team dynamic, shared ownership, technical oversight) while also being fluid enough to give responsibility and autonomy to their members. For ResDiary, the answer has been Feature Teams.
Feature teams have become our core concept when we are considering our ability to scale. A feature team can be viewed as a mini-team formed of members from a larger fixed team. This mini-team has total responsibility for delivering a piece of work from requirements through to production. The composition of a feature team varies depending on their goal but generally follows:
Feature lead
The Feature Lead is responsible for organising planning and estimation, the kick-off meeting, reviews and, in short, making sure the work is on track.
- In our case this is usually a senior developer. This works best for us as the developer knows when they’ll be able to start work and can schedule the kick-off meeting accordingly. This role could also be taken by a designer, product manager or tester
- An additional benefit of using a senior developer as a feature lead is that they gain experience organising work and mentoring others on a manageable scale. This supports skill development and career progression to Team Lead if and when the time comes
At least one more developer
The developers on the team carry out the work under the direction of the Feature Lead. We aim to have a mix of experience levels.
- Even if the work is small or simple, having at least one more developer increases quality and introduces an element of resiliency
Designer
Once the designs have been created, the designer’s role with a feature team is to provide design and user experience support.
- The designer may float across multiple feature teams or be dedicated full-time to one, dependant on demands on their time
- It is essential that the same designer sees the feature through to release. The valuable understanding and insights learned from being involed at the start of a project will be lost if another designer is parachuted in at a later date to take their place
Product Manager
The product manager has responsibility for requirements gathering and/or idea inception. The rest of the team uses them as a consultant, constantly validating their solution to ensure it meets the user requirements
- As with the designer, it is imperitive for the quality of the solution that the same product manager is involved throughout the process
As well as feature teams, which have their own Feature Lead, we still have traditional Team Leads who act as technical guides, are responsible for oversight of work that goes into the backlog, into sprints and for assigning work to feature teams. They remain largely hands-off once a feature team has kicked off. It should be noted that the Team Lead can and will also act as a Feature Lead.
The optimal number of developers in a team seems to be around six — this allows for a number of workable feature team configurations based on the size and complexity of work: 3 teams of 2, 1 team of 4 and a team of 2, etc.
Part 2 — Development Process
Having a workable team structure in place is only half the battle. An efficient development process that guides the production of quality work in a timely manner is just as important.
Feature kick-off
There are a whole host of things that happen before work ends up in a team backlog, but for the purposes of this article, let’s assume the team have a healthy backlog of prioritised pieces of work. About halfway through their current sprint, the team will hold a backlog conditioning meeting where they get a shared understanding of what’s coming up next. At this point, the Team Lead assigns a Feature Lead and one or more devs to each piece of work, then it’s up to the Feature Lead to organise a kick-off meeting. Kick-off meetings are where everyone involved in the work — the devs, designers and product managers — get together to discuss the work. The team are encouraged to read the spec document (we use Confluence) before the meeting and to bring any questions they have. The typical agenda is:
- The Product Manager talks through the user stories to give an overview of the problem and answer any questions
- Any mockups that have been created are discussed
- Obvious technical or design blockers are discussed
After the kick-off meeting, the designer can start finalising the user journeys and user interfaces ready for the development work to begin.
Starting the sprints
We currently only use sprints as a way to help break work up into managable chunks. This forces us to stop and take stock of what we’re working on. We’ve found sticking dogmatically to sprint delivery isn’t helpful to us, so if something needs more time to be done properly, it gets more time.
Automation, automation, automation
From a technical point of view, automation is at the heart of any efficient development process and we strive to automate as much as possible. We have:
- Automated continuous integration that runs our tests after every pushed code change
- An easy and reliable deployment process (we’re not quite at the point of continuous delivery)
- Releases and branch creation are handled via a short interaction with a Slack bot
It feels pretty good to schedule the release of 7 solutions over 5 availability zones and 2 service providers by talking to a Slack bot.
Future Challenges
As the team grows, it’s naive to expect everyone to know about every aspect of the architecture and codebase, yet we need to ensure there is ownership and that quality standards are maintained. We’ve considered using the open source model, where a team owns a particular part of the product (e.g. the API team) and any team that wants to make changes to that do so through pull requests, and we’ll look at implementing that more closely as time goes on.
