This is a continuation post. In part one we set the stage for a few of the consideration factors in building agile teams. Here we continue to explore more factors…

Do we really need a Scrum Master?

For someone as wordy as I am, the short answer is yes. I even recommend that organizations find a Scrum Master-like person (a coach) for new instances of Kanban. This role, if staffed with the right people and done well, is a game changer in accelerating new agile adoptions.

Do they need to be certified? Perhaps not, but they need experience in lieu of or in addition to certification.

Can you do a “time share” with an internal team member as a Scrum Master? Sure, you can do anything you wish. But I’ve found that part-time (or multi-tasked) Scrum Masters aren’t a good idea. I much prefer to invest in professional and experienced Scrum Masters. And, if ‘m running short of funding, I’ll overload them a bit with two teams each.

Not finding/hiring/training Scrum Masters in your organization is one of the most shortsighted cost decisions you can make when you’re planning for your agile transformation. Yet, I see it all the time – sort of a penny wise and pound-foolish mistake.

And while I won’t get into it much here, taking that same approach with Product Owners is potentially even more dangerous.

Team Size

When considering team size, one of the first things I think about is the general Scrum advice of teams in the range of 7 +/- 2. I’ve found that to be sound size advice for forming agile teams.

I’ve also found that even within that range, smaller is often better. For example, in my experience teams of 5-6 people are a sweet spot from a productivity and efficiency perspective. I’ll give you an example:

I once worked at a company called ChannelAdvisor as a Director and Agile Coach. We had one team that had grown to about 12 individuals. We were growing as a company and we had a habit of growing our Scrums teams with new hires and then, when they reached a certain size, we would split them.

This team was working really well, but it was large. Before we could naturally split it, a business priority shift happened and we split the team to double our focus on another business initiative. So we split them into two teams of six. I’ll never forget this example.

In the first sprint of the original team, their velocity only took a marginal impact, 1-2 points. So we had literally cut them in two, BUT their velocity didn’t reflect a change. How can that be you might ask? We determined that reducing the team from 12 to 6 individuals simplified the communication and their effectiveness – to the point where half the team was nearly as productive as the larger group.

I try to keep teams as small as possible and still contain the requisite skills to get the job done.

Team Cohesion – Does it Matter?

I’ve encountered organizations that move team members around from team to team as if they’re playing a game of musical chairs. Sure, there’s always a reason for it. Often something like – this project is late so we’re reassigning more team members to the project for the next 30 days to recover it.

The people are treated like commodities or as if they’re fungible. They’re not by the way and . But that doesn’t seem stop us from treating them as if they were.

The impact of this can be severe – especially within agile teams. When I’m in a leadership role in an agile organization, the last thing I do is disrupt the cohesiveness of my teams. I consider well-formed, high-performance teams to be a critical aspect of my delivery proposition.

It takes so much time to build a cohesive team that I wouldn’t think of changing it willy-nilly.

So the answer to this question, and I know you realize it to, is YES team cohesion and stability matters. Try to keep your teams together as long as they’re healthy and performing, even when the business pressure is on.

Sitting Together

There is an incredible amount of debate surrounding how to setup your team areas for collaboration. One extreme is to keep team members in cubes or offices that separate individuals and impede teamwork and collaboration. The other extreme seems to be “throwing everyone” into a large room at a single table.

Both of these have a grain of truth in them and the goal should be somewhere in between the two. There is a relatively old convention or tactic within the Extreme Programming community called “Caves & Commons” that makes the point well. It implies that agile teams need both – “caves” for private, individual immersion and work and “commons” for collaborative work.

I believe the best spaces (and team dynamics and results) include both types of space for the teams’ use.

I’ve written about this “space dilemma” before in . And the following InfoQ article does a nice job of exploring the options as well –

Identity & Ownership

I have two loose rules when I’m trying to guide and determine what teams work on. First, I work with the business, Chief Product Owner and the PO team to decompose the business products/projects towards a meaningful set of focused themes.

Then I try to staff the teams to align with these Product Backlog themes. Clearly each stream gets a Product Owner. Not only do I want the team to be staffed in order to successfully deliver on the business expectations, but I want the backlog stream to enable their having an identity and end-to-end ownership of all of the work. By that I mean they own the maintenance, feature development, technical evolution, and future release roadmap for their product or feature area.

I’ve found that giving each team a sense of holistic identity and ownership is key to establishing team empowerment, ownership, and ultimately delivering great results.

Wrapping Up – 4 Biggest Mistakes

To wrap-up this discussion, I believe there are four primary mistakes that most organizations make when building their initial team structures for agile execution:

1. Not engaging their teams in the organizational modeling process;
2. Not viewing their organizational modeling as an iterative, learning process;
3. Not applying appropriate training and staffing of their SM and PO roles;
4. And not leveraging the opportunity for change, at all levels, that an agile transformation offers.

I’ve had the wonderful opportunity of creating a few high-performance agile organizations. The advice I’m sharing in this article isn’t theoretical or academic. It’s based on my own hard-won experience and realization of what works. And yes, I realize how challenging some of my advice will be for most leaders.

Nonetheless, I stand by it and hope you try it. I promise you it will be worth your efforts.

Stay agile my friends,

Bob.

This is an article by Mike Cottmeyer that takes a different approach to constructing your teams. He’s looking at alignment to various business dimensions. I don’t agree with some of the intent behind it, BUT it is an interesting read related to my articles theme.