For the last 6 months, I’ve been focused on putting some work into revamping my team’s development workflows.
I lead the AffiliateWP development team (Team Alf) at Sandhills Development. In the past 6 months, we’ve grown from three developers up to five and most recently back down to four when one of our seniors left to lead development full time on another Sandhills product, the Payouts Service.
Growing pains
With the personnel changes came growing pains that have ultimately tested the viability of our development workflows. Turns out that while the gap between three and four developers might seem small, it actually is much more difficult to manage.
One of the ways we’ve seen our development workflows tested is in the code review space. When the team was two seniors and I sharing the work, me keeping up with code reviews was manageable. When we jumped to five (three seniors, a junior, and me), things soon became untenable.
For instance, we quickly realized the single point of review wasn’t going to work any longer. Turns out I can’t stay on top of four other developers’ code reviews and simultaneously make myself available as a support resource. At least not without working a whole lot more hours in the evenings and weekends.
Sandhills believes it doesn’t have to be crazy at work, so throwing more of my time at the problem wasn’t really an option.
Working on how we work
The team growth began to surface other problems as we went on, particularly in the area of managing our resources. At any given time, the team is typically juggling the next major or minor core release, various add-on updates, and other projects.
As I mentioned in my post yesterday about writing APIs, Team Alf’s sole focus right now is finishing the first release of our new Affiliate Dashboard pro add-on.
In theory, the four of us on the development team are effectively dividing the work. In practice, however, the three developers are largely dividing the main tasks and I’m pitching in where needed, shipping releases and generally picking up the slack.
Collaborative development workflows
Oh, and I’m still doing code reviews, but not like before. For example, we recently started to experiment with promoting more team collaboration:
- Each major task is scoped for 4-5 days of work max
- Each task has an “owner” but sometimes multiple people working on it
- Every task gets reviewed and tested by every developer
So far this approach seems to be having positive effects, which is encouraging! More eyes are on what’s changing than ever before, and confidence in meeting our deadlines has never been higher.
Managing the management
In addition to task management changes, I’ve been looking inward at the work I do. I’ve been playing around with handing off some of my responsibilities to other developers on the team. That effort of lifting others up seems to be going well.
I can now be more available to work with my team instead of my team working with me.
I’m no longer herding cats 24/7 and the team is better for it. I can now be more available to work with my team instead of my team working with me.
I’m certain problems large and small will continue to crop up as we go. Moreover, I’m confident we’re on the right track to finding development workflows to work for us, instead of the other way around.