Menu

Is your Agile Team the right "shape"?

Episode 146 - 30 Sep 2020

Does your team have all the right roles, and the correct number of people in each role?

If so, count yourself lucky.

Many teams have to make-do-and-mend.

I call them "real-world" teams. And I have a lot of time for "real-world" teams.

What is the “shape” of your Agile team? Does it have all the right roles? With exactly the right number of people in each role? If so, congratulations, you have a “text-book” team. But the chances are good that Your team does not have all the right roles OR does not have the right number of people Your team is what I like to call a “real world” team. And I have a lot of time for real-world teams. Not too long ago, I worked in a development team in a startup. A reasonably sized team 1 designer 2 data scientists 3 backend 3 front end 1 product owner And that was it. Oh. Did I mention that the team was doing Scrum? If you’re familiar with Scrum, you’ll know immediately that the team was missing a role. A rather key role. The role of Scrum Master. And as time went on, the more we felt that the lack of a Scrum Master was holding us back. Eventually, the lead developers - there were two of them - got together to recommend hiring a Scrum Master. The request… perhaps you can guess, was DENIED! We had no choice but to carry on with a team that we felt was the “wrong shape”. And I suppose at this point we should talk about what is the “correct” team structure. The answer to that question depends on which “flavour” of agile you’re doing. If you’re “doing Kanban” - or even Scrumban - …. Not very prescriptive …. Unless you know something that I don’t. But if you’re doing Scrum, well… The Scrum Guide is pretty clear about the make-up of an Scrum team: To be clear: Exactly one Scrum Master Exactly one Product Owner And exactly one development team. The team I was just talking about lacked the Scrum Master role, And a Scrum purist might say that we should have found a way to get one. Now here’s the thing: Thinking of the non-Team aspects of Scrum: the events, the artifacts. Perhaps you look at the list and thought, oops, we haven’t done a Retrospective for a while. Fixing that is as simple as… holding a retrospective. You could do it today. There’s certainly no need to dispatch two lead developers to get budget allocated for it. The retrospective - like everything else on this list - is entirely under your control. … teams control. But when it comes to team structure… it's a different story. Certainly, you’re not going to fix things today. And in most cases, you’re not going to fix things for free. In many cases - I’d say the majority of cases - you’re not going to fix it at all. You’re stuck with your “real world” team. And do you know what, I have a lot of time for real-world teams. I have a lot of time for what I like to refer to “real-world agile” teams. Perhaps - like the team I talked about early - your missing the Scrum master role. Or perhaps you have a project manager (rather than a product owner). Or more than one product owner. Or more that one project manager! None of these situations is ideal. Teams that aren’t quite the right shape. But are determined to get things done anyway. So I’m curious. What’s the shape of you agile team? Is it “text-book”? Or it … shall we say… more interesting? Tell me about the shape of your “real-world” team in the comments below.