Shape of You
How does your development team compare?
This isn’t an article about Ed Sheeran. I’ve never been a massive Ed Sheeran fan, but I do wonder if he’s starting to grow on me. I do like some of the synths he uses :D
With that aside, one of his songs “Shape of You”, weirdly segues onto this week’s topic.
This is how work is divided around our team. Our team shape as such — the shape of us — or you from your perspective.
Our current selection of products used to be managed by 3 teams. Over time the 3 teams were combined and… well there’s just us now.
We’ve got 8 developers (including an Architect, DevOps and an SRE Lead) a Team Lead and myself the Product Owner. 10 people in total.
As the Product Owner, I often lose count of the applications that we look after. It’s about 40–60. A lot of these are small applications, but we have some big beasts. Bespoke HR, Payroll, Rostering and Recruitment systems come under our wing as well.
The standard team size for our department is 6 developers, but we get an extra two more due to our ridiculous support burden!
Support
Due to support being quite a chaotic and stressful experience we rotate the developers through support on a two-week basis. It’s basically jumping into the trenches with an axe and fighting fire.
- The HR system will fall over, and they’ll restart it
- Shifts worked won’t reach the payroll system
- New starters won’t be able to access the rostering system
- Contracts need to be added to the recruitment system
Just because of the large estate, two developers are kept very busy over their two-week tenure.
SRE
So, support have an axe, but the water to put out these fires comes in the form of SRE — Site Reliability Engineering.
Their remit is to reduce the toil of support. Through SRE activities we hope to tend towards one person on support. When this happens, that person will focus on SRE work. Like a nice little wheel of life.
In the rare quiet time that support do have, they can devote their attention to some small SRE tickets before the next building collapses.
Some things SRE do are:
- Add monitoring so we know that an application is down before the users do
- Database & Server upgrades
- Deployment Pipeline upgrades
- Security fixes
- Automating regular support queries
Two people work on SRE at one time and are rotated through in line with support as well.
SRE work is prioritised during refinement using the Foxly Jira Plugin.
Feature
That leaves 4 people working on Feature. These people deliver new requirements and enhancements to our existing systems. Sometimes, new systems as well. Things like:
- New Payroll Holiday Rate Calculations
- Bulk Upload Functionality for the HR System
- Sending data to BigQuery
- Integrations with other APIs around the Business
Feature work is prioritised by me 😉 based on things like Cost of Delay, Business Impact and our team’s mission.
Rotations
As support is rotated through on the two-week cycle — so is SRE — but this also extends to the Feature work. This means that all the developers in the team have the opportunity to do what they view to be the “interesting work”. That’s not always Feature (I do have a lot of bias there). Sometimes, SRE will be the preferred tenure!
The Architect works on Support and the DevOps looks at some coding tickets as well. Only the SRE Lead is exempt from the Feature work rotation.
Push and pull
By design 50% of the team are engaged in Support & SRE work, while the other 50% will be active on Feature work. This percentage can shift in favour of any of the 3 streams.
If there’s a critical business requirement, then Feature can borrow from support. If one of the systems has burnt through all its SRE budget, then SRE will borrow from Feature etc.
We can’t really borrow from support as that could have a disastrous impact on the business.
Issue tracking
We have one project board in Jira. Running Kanban we have the following Swimlanes:
- ForSupport
- Expedite SRE
- SRE
- Expedite Feature
- Feature
The board can get a bit crowded sometimes, but it’s an information radiator!
Process
We have a term norms document that describes our delivery process in detail. As a highlight we have the following columns in our Kanban board:
- Backlog
- Todo
- In Progress
- Blocked
- Reading for Review
- In Review (Review need to be done by 2 developers)
- Ready for Test
- In Test (Test to be done by 1 developer)
- Ready to GO GO GO
- Done
Weirdly back to Ed Sheeran
When I started SRE wasn’t really in the picture. The team lead and I had differing opinions on what should be done (it was a healthy friction).
When SRE became formalised across the department I was initially reticent to be losing some control over the roadmap. Being a developer myself, I’m very aware of the importance of SRE activities and Kaizen. But having the split between myself and the SRE Lead has enabled me to really focus on Feature and what the Business needs.
Because the 50% split is systemically integrated into our process, I can be sure that all our products are getting better over time.
That’s the shape of us at a very high level. Like any team our processes have evolved over time; my expectation is that they will continue to evolve as well.
Maybe a bit like Ed Sheeran’s music.
Thank you for reading this article! Please leave a comment below if you have any questions or feedback.
If you enjoyed this article then please consider buying me a coffee:
Chris Sheldon is a Project Manager for DataArt Ltd. DataArt are a global software engineering firm that takes a uniquely human approach to solving problems.
In his career Chris Sheldon has been a Software Developer, Scrum Master, Development Manager and more. He’s decided that people are harder than process, so this is where his attention is now targeted!
Chris graduated in the UK from Reading University with a degree in Electronic Engineering and Cybernetics.
A bit of a Agile enthusiast, productivity nerd and Wantrepreneur Chris really needs to decide what he wants to do in life and focus.
You can connect with him on LinkedIn, Twitter, Facebook, or by visiting his website, ITsChrisSheldon