Great software development teams don’t just materialize as if beamed in by a Star Trek transporter. They can’t be formed by managers who hand-pick the “best and the brightest” to work on a critical project either. Great teams form when people are challenged and have to think for themselves.
Here’s a simple example. Let’s say we have a team following Scrum principles. They have a well-groomed and prioritized sprint backlog. Well into the sprint, one of the software developers finishes working on a story. There are more stories in the backlog and plenty of time left to work on them. What should the developer do?
He might simply access the sprint backlog and select the story at the top of the priority list. Makes sense, right? There’s nothing wrong with that approach, however, it doesn’t do anything to encourage teamwork and collaboration. It’s simply a lone developer doing his thing.
Leverage the Opportunity
What if he asked his teammates if any of them needed help? — Is anyone stuck? Is anyone falling behind? — Ideally, the Scrum Master should already know the answers. In fact, everyone on the team should know via the daily standup meetings. The general idea is to get stories through the development process as quickly as possible. Having lots of stories in progress is inefficient and wasteful. The Scrum Master needs to keep things moving.
Another possibility is to have the Scrum Master consider the developer’s strengths. For example, if this developer excels at writing efficient database queries and one of the in-progress stories demands this skill, maybe having the story handed-off to this developer will help the team best. You could also consider having the developer pair with the one implementing the (query) story to take advantage of a learning opportunity.
Swarm Problems
Similarly, great teams solve problems together whenever possible. They don’t dump problems on outsiders and wait for a fix. They don’t expect team members to solve problems in isolation. Instead, they openly discuss problems, impediments, bottlenecks, etc. and brainstorm ways of handling them. Again, the daily standups are the right place to raise awareness of issues. (Brainstorming needs to be done outside of the standups as you know.)
Managers and others in leadership roles often want to jump in and solve problems. That raises two concerns. 1) The team members grow increasingly dependent on such behavior and don’t learn good problem-solving skills. 2) Forcing a solution on the team may result in backlash and unintended consequences. Solutions need buy-in. The best way to get buy-in is to have the team solve its own problems.
Get the idea? Great teams don’t blindly follow procedures. They exercise good judgment and have a genuine interest in helping each other. This doesn’t just happen. Scrum Masters, Product Owners, and organizational managers need to encourage collaborative behaviors.