In a recent post I talked about why salesforce.com chose to go with a unified development team approach from the very beginning. After getting some great feedback, I thought I’d follow it up with five quick tips about implementation. If you’re thinking about implementing unified teams into your business’ workflow, hopefully these tips will help.
1. Keep your quality team separate from your product management team (this is critical for the growth of the quality engineer).
This is one of the unique things we do here at salesforce.com. While we don’t have a separate quality assurance team, our quality engineers report to a separate unit of management than our software engineers do. Over the years we’ve realized that quality engineers need different mentoring and career advice than software engineers do. Having them report to a separate unit of management allows them to advance more effectively than if they were reporting to development managers.
2. Encourage role challenging. If you have quality engineers who want to be full-time software engineers — and vice versa — encourage it.
Traditionally, software engineers and quality engineers have operated separately. And because of this, quality engineers have often been treated as second-class citizens. With unified teams, of course, this is completely different. Quality engineers are integrated into the software development team. They’re involved in the design process and design reviews, and they coach engineers who may not have a strong quality mindset. They’re basically software engineers who have a particularly strong focus on quality. In other words, the boundaries between the software engineer and the quality engineer become fluid, and that fluidity is something we encourage. We want people to develop their strengths and follow their interests.
3. Don’t be afraid to change and tweak the approach.
We live in an agile world, which means you can’t be afraid to fail. If you have something that doesn’t work, just learn from it, change it, and move on. The unified development teams at salesforce.com have evolved over time; it’s not like we just decided to do this and it worked well from day one.
4. Have strong individual contributor leadership in place for your quality engineers so they have someone who’s not only a mentor, but keeps them on the rails as well.
Some quality engineers may lean more toward product development and get distracted from their quality goals. If that happens, you’re going to be stuck with a condensed testing schedule or worse, shipping a sub-par product. We’ve found it’s best to have senior individual contributors help guide individual contributors — not the team as a whole. These mentors can keep an eye on them and make sure everyone’s on the right track.
5. Have open communication and collaboration. Your team members have to work well together.
Unified development teams will only ever be as good as the team members; you have to have the right team members involved. Once you have that, a lot of problems will take care of themselves. This is why we take a very hands-off approach with our teams. We try not to be too prescriptive. We have so many different Scrum teams that dictating a standard just wouldn’t work.
When you’re building a unified development team, watch out for engineers who aren’t willing to think in a unified way. If you have a software engineer who is never going to write a unit test or who views quality engineers as second-class citizens, not only is this person going to have a difficult time functioning within a unified team, but the team is going to have a hard time functioning as a whole. You have to overcome those challenges or, in certain circumstances, replace those people.
Whether you’re just thinking about implementing unified development teams or already in the thick of it, I hope these tips will save you some trouble. Remember, unified development teams are not a one-size-fits-all solution. Your mileage may vary. And if you’ve found certain strategies that are particularly useful for your teams, let us know! We love learning new things.
