Developer Team Structure

The Agile Manifesto’s first value is:
“Individuals and interactions over processes and tools”

And so I am not surprised when expansion stage software companies adopt Scrum as part of their product management and development process, do all the steps, measure their velocity, and then fail to deliver quality product on time because they spent very little time looking at the people on their product development team.

Specifically, management does not ask questions like:
Do we have the right skill sets on this team to do what we say we’re going to do? What technologies are required to build this?What do the people on our team know?What are they likely to figure out?What do we need to get elsewhere?

Are the skill sets highly redundant, or are they complimentary?

After all, the definition of a team from The Wisdom of Teams from Katzenbach and Douglas, tells us that: “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.” 
Is our team too young and inexperienced? Especially if we just added a lot of new developers, do we have a high enough ratio of senior, super start experienced tech leads? Some folks in the Agile community say that, in a resource constrained world, one very senior super star developer combined with 4 average or learning developers should make for a pretty good Scrum team.

Beyond the key Scrum roles, do we need other roles on this team?Is everything covered? Are people stretched too thin?

Unless senior management teams at expansion stage technology companies ask these questions, objectively and rigorously answer them, and take the necessary next steps, all the process in the world won’t save you.

Lots of other people have written on this topic. I recommend you take a look at this blog from InfoQ and, more recently, Martin Proloux’s post on “The 7 Dimensions of an Agile Project Team” at Analytical Mind.