How To Develop a Strong Developer Team Structure

Is your Scrum Team Failing?

When adopting Agile and Scrum, many expansion stage software companies take the appropriate steps, employ the processes and tools, and measure their velocity, only to ultimately fail to deliver quality product on deadline.

Why is that? It’s usually because those companies neglected the Agile Manifesto’s first value: Individuals and interactions over processes and tools. Software companies can do all of the right things, but if they spend very little time examining the people on their product development team, then those companies inevitably violate Agile’s primary principle—and fail.

The people executing the process matter and if they’re not put in a position to succeed, the process won’t produce anything of value. Specifically, management teams need to consider these questions:

• Do we have the right skill sets in place on a particular team to accomplish what they say they’re going to do?
• Are the team’s skill sets highly redundant or complimentary?
• What technologies are required to build this system?
• What do the people on our team know and what are they likely to figure out?
• Do we need to add new people, hire a consultant, or pay for some training?

I think one very good way to think about the composition of your Scrum teams is to consider John R. Katzenbach and Douglas K. Smith’s definition of team from The Wisdom of Teams.

“A team is a small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable.”

There are other variables that can come in to play as well. For example, a Scrum team can be too young and inexperienced. If a company recently added several new developers, it needs to balance out its Scrum team composition with an appropriate ratio of senior or superstar tech leads. For instance, some folks in the Agile community argue that for every four new or average developers, you need one very senior superstar developer to make for an effective  Scrum team.

If senior management failed to ask and address the questions I mentioned above in the first place, then the Scrum team may not have been set up for success. Expansion stage technology companies need to objectively question themselves and rigorously pursue answers to those questions. Without taking that necessary step, all of the most sound processes in the world won’t save a company’s Agile effort.

InfoQ posted a great blog on this topic. Included in that post is a list of nine questions that Mike Cohn at Mountain Goat Software believes every company running Agile should use to assess its team structure. If companies get an affirmative response to all of those questions, Vikas Hazrati writes on InfoQ, then they probably have a well-structured team.

I suggest reading Martin Proloux’s post on “The 7 Dimensions of an Agile Project Team” at Analytical Mind, too. You can read about each dimension on his site, but Proloux suggests that every Agile team needs to possess autonomy, competence, accountability, collaboration, communication, continuous improvement, and the right processes and tools.

Notice that the last dimension in Proloux’s order is processes and tools. They’re obviously important to the success of any Scrum team, but not without the right individuals and interactions — as the Agile Manifesto suggests — making use of them.