What is the shape of your Agile team?
Does it have all the right roles?
And do you have exactly the right number of people
in each role?
If so, congratulations.
You have what I would describe as a textbook team.
But the chances are good that your team does not have all
of the right roles or does not have the right number
of people in each of those roles.
Your team is what I like to describe
as a real-world Agile team.
And I have a lot of time for real-world Agile teams.
(whooshing)
(buzzing)
Not too long ago I worked in a development team in a startup
and it was a reasonably large team.
One designer, two data scientists,
three front end engineers, three back end engineers,
one product owner, and that was it.
Did I mention that the team was doing Scrum?
If you're familiar with Scrum, you'll have spotted already
that the team was missing a role, a rather key role,
the role of Scrum Master.
Now it wasn't a conscious decision
not to have a Scrum Master,
was just the way the things had worked out.
But the more that we worked together,
the more the time went on,
the more we felt that the lack of that role
was holding us back,
and actually it got to a point
where the twin lead developers on the team went
to talk to management about bringing on board a Scrum Master
of our very own.
Long story short, the request was denied,
or rather, it's not something that we do now,
but something we look at in the future.
So we had no choice but to carry on
in a team that we considered to be, well,
ever so slightly the wrong shape.
And I suppose at this point,
we should talk about what is the right shape
for an Agile team.
And the answer to that question depends a lot
on the flavor of Agile that you are doing.
Neither Kanban or Scrumban are very prescriptive
about the shape of the team.
That is unless you know something that I don't,
and if so, please let me know in the comments below.
However, if you are doing Scrum, well,
you will know all about the Scrum guide.
And the Scrum guide is extremely prescriptive
about the shape of team that it expects.
And I quote, "The Scrum Team consists of a Product Owner,
the Development Team, and a Scrum Master."
Just to be crystal clear, exactly one Scrum Master,
exactly one Product Owner,
and yeah, exactly one Development Team.
The team I was just talking
about did not have exactly one Scrum Master.
And I guess Scrum purists might say
we should have found a way to get one, but here's the thing.
If we look at a different aspect of Scrum,
for example, the events.
The events are the sprint, sprint planning,
daily scrum, sprint review, sprint retrospective.
Perhaps you looked at that list and thought,
"Oh dear, we haven't done a retrospective in a while."
And if so, well, the fix is pretty easy.
You could hold a retrospective today, tomorrow, certainly.
You certainly don't have to dispatch a couple
of lead developers to talk to management to get it done.
The retrospective, and indeed everything else on that list,
is completely within your,
or at least within your team's, control.
But when it comes to team structure,
it's a different story altogether.
You're very unlikely to fix things today,
you're very unlikely to fix things for free,
and in many cases, you're pretty unlikely
to fix things at all.
You're stuck with your real-world team.
And I have to say
that I have a lot of time for real-world teams.
You are aware that perhaps your team is a little misshapen,
but you're not going to let that stop you
from getting on and getting things done.
And that is something, I think,
to be admired and celebrated.
So I'm curious.
What exactly is the shape of your real-world team?
Are you missing the Scrum Master role
like the team that I talked about before?
Perhaps you have a product manager,
rather than a product owner.
Perhaps you have more than one product owner,
or more than one product manager.
Whatever it is, I would like to hear about it.
Let me know about the shape of your hero real-world team
in them the comments below.
Thank you very much for watching.
I'll see you again very soon, cheers for now.