Welcome to another installment of Ask an Agile Coach. Today’s question centers around how to structure teams in light of constrained skill sets in an organization:
What technical roles, other than QA, can be successfully shared across scrum teams? DBA, UX, etc.? – @jakejgordon
Strive to have people in dedicated teams; only share in order to get work from concept to customer.
Any software application of substance requires a collection of specialized skills. A healthy, cross-functional team will have a pool of diverse talent: programming (in at least one language, but often more), testing (QA), database administrators (DBA), business intelligence (BI), user experience (UX), operations/infrastructure (OPS/INFRA), and others. However, some of these skills are not used enough to occupy a single person’s work from week to week on a single team, so persons with those skills are allocated across multiple teams.
Recall that, with Scrum (and other Agile processes as well, though Scrum is most explicit about it), the process is designed to provide empirical process control in software development. The reliability of velocity as a measure of throughput depends upon the stability of the team. Therefore, an organization should try to structure its teams to consist of people dedicated to the workloads they serve. When team members are allocated across multiple teams, their available hours for each team can vary from sprint to sprint. Since these people are usually specialists like BI or UX, this variation is happening with the most constrained set of hours available for Sprint Planning. Any user story in a sprint that requires these hours is at risk of carryover if the team planned against hours that turned out to be unavailable.
The undesirable result of this variation is an unstable velocity and increased carryover of user stories in sprints. This in turn erodes the reliability of planning and estimation activities. The team shows itself to be unreliable and unable to deliver on commitments, eroding confidence and trust with stakeholders and management.
The primary risk with sharing team members is that Scrum Masters and management often do a poor job of accounting for how those peoples’ time is allocated and managed, which inflames the symptoms described above. Bear the following points in mind when sharing team members:
Include all your cross-functional team members in user story writing, estimation, and Sprint Planning sessions. User stories that account for all the effort needed to go from concept to customer are more reliable and not as prone to surprises during delivery in a sprint. Prefer the bad news of resource constraints over the surprise of planning against naive user stories.
Avoid sharing a team member across more than two teams. Once a person has to divide his or her effort across three or more teams, estimates and available hours become unreliable. Furthermore, the more teams a person has to participate in, the more their time is wasted in switching their mind between contexts. They also end up in recurring events like Sprint Planning, Sprint Reviews, Backlog Grooming, and Retrospectives for each team, leaving a meager number of hours to do actual work. If a person has to be shared across more than two teams, that is a sign that another person with those skills needs to be hired.
Use the valuable information from Sprint Planning and tracking to inform the budgeting and hiring process. Is QA/BI/UX constantly a shortage in Sprint Planning? That is the gentle, loving tap of the clue bat on the collective skull of management to stop hiring more software developers and allocate the salary budget in a manner more appropriate to the actual work being done by the group. Hidden costs of effort are being uncovered as a result of properly applying the transparent, reliable process that is Scrum, and that is a good thing.
Barry Hawkins of All Things Computed provides coaching and mentoring in how to successfully apply the process and technical disciplines of Agile Software Development.
So, your answer to the article’s title question is, “none”?
Hi David, thanks for reading! The short answer is the compound sentence right under the Twitter quote. Put in other words:
If a group decides to share people across teams, know that it comes with a cost. Make sure the cost is justified, and continue to inspect it and ask whether adaptation is in order.
Hi Barry,
I think even sharing team members across two teams is a really bad idea. The overhead of switching tasks is very expensive. The only situation where this works is when the transfer happens when a completely independent tasks is totally finished and the team member is moving to another independent task on another project.
PS: I have published an article a while ago on the trouble with continuous multi-tasking. I hope you’ll get the chance to read it.
I love the idea of having more, smaller teams but am struggling with how to make it work in regards to these more focused skill sets. Adding more instability to our iterations is too risky at the moment so I might have to keep the teams as they are. Thanks again for your time Barry!
Comments are closed.