Developer Silos Suck! 6 Things We Did To Remove Them — Pt 2
Anyone who has been in software development has seen it. A bug or task comes in and is assigned to the developer who has spent the most time working on that product or codebase.
This makes sense, right? Why not assign the work to the developer with more domain knowledge and who can get it done faster? It’s totally more efficient……or is it?
This is not only the opposite of efficient, it’s actually holding development teams back. This approach is nearsighted and can hurt the team’s morale. Always giving tasks for a specific product or code base to the same person lowers team accountability, stifles team work, creates jealousy, promotes favoritism, squashes career advancement and can ultimately lead to people leaving, or worse, not loving their job.
As a company grows, silos seem to naturally grow. Smaller companies are usually faster paced and need to iterate quickly. As a company matures, old ideas and process tend to stick around, like where the idea that every feature and bug should be added and fixed, instead of weighting the features and bugs with the biggest impact. To speed up implementation of every idea that pops into someone’s head, we naturally hand tasks to people who can implement the quickest and who have the deepest domain expertise.
Time for a little time travel! 7 months ago, the developers were cranking out projects and tasks, and delivering them on time. Each product backlog had its own sprint backlog, with a developer assigned to each. Each developer could work in 1–3 sprint backlogs during our 2 week sprint. The developers stayed mostly within their realm of expertise, and we got stuff done.
“What, pray tell, is so bad with the setup?”, you may be asking yourself. From a productivity standpoint, a developer, is forced to manage multiple backlogs. The developer will have to jump around from sprint to sprint to access their work. This also raises the question of priority. If a task in one sprint is higher priority than another in a different sprint, how does the developer know? What if a developer goes on vacation or heaven forbid is hit by a bus? Work on a product could easily be stopped, and the person could feel remorse for taking some much-needed vacation. We also have the problem of the team. Each person on the development team is not able to easily see what peers are working on. A team should work together to complete the team’s goals. One developer who finishes their sprint work early should be able to see that another developer is swamped and offer assistance, if possible.
“The way a team plays as a whole determines its success. You may have the greatest bunch of individual stars in the world, but if they don’t play together, the club won’t be worth a dime.” — Babe Ruth
We decided it was worth trying to solve some of the inefficiencies. If we made things worse, we at least had some fun and learned the other way was better. We made small changes and continue to hold retrospectives to ensure the changes were effective and reevaluate them if needed. Below is what we’ve done so far.
1One Backlog to Rule Them All! In order to provide visibility within the team, we created one sprint backlog that all product backlogs fed into. Developers continue to work on the products they were familiar with, but now they could see, on a single board, the workload and priorities for each developer and for the team as a whole. We went from the image above to the one below.
2Shared Ownership: Typically, in sprint meetings, each developer would take turns grooming the backlogs they were assigned to. When it wasn’t their turn, they would work on other tasks or emails. In order to expose unfamiliar products to other developers, we started doing story point estimations. This required each person to listen as the product owner and lead developer explains the task.
3Product Trainings: The product owner and lead developer train the team on what each product is, its history, an in-depth review of its code, its architecture, its database schema, and its infrastructure. We knew most of the information wouldn’t stick but felt the exposure was needed. So far we’ve completed 3 training sessions and the team has been very receptive to it.
4Redundancy: Our next step was to provide developer coverage on all our products. Our goal is to have at least 2 developers assigned to each product. They are included with all meetings and decision making. They are encouraged to split up work so each person has exposure to the code. This has been working out really well but we still have a few products that without coverage.
5Pull Requests: The team decided we should set up guidelines and encourage peer pull requests for each feature. Apart from enforcing code quality standards, this has been great for keeping developers up to date on what their teammates are doing and exposing them to less familiar projects.
6New Product Assignments: Working on the same code base over and over can get stale. We want to challenge each developer on new systems and give each product a fresh pair of eyes. Transitioning projects and systems from one developer to another has not been easy, as it takes time to learn new systems and transition the point of contact. We understand that switching things up lowers productivity, but we hope it will help with coverage and skill development and the return on investment will pay off.
This hasn’t been easy. It has taken 7 months to get to this point. There has been a lot of planning and a lot of iteration as we learn. Though frustrating at times, overall it’s been a blast. The team has been super supportive and regularly provides feedback and recommendations which has made all the difference.
Do you agree or disagree? Have you tried any of these steps or other things? Let me know what’s worked or hasn’t for you and your team.
Part 1 — We just want to be agile
Part 3 — The Sprint Process (Coming Soon)
