Agile Development Teams: Scope and Scale with Mike Cohn
Summary
TLDRIn this episode of 'Software Conversations', the discussion revolves around scaling agile methodologies to large teams, contrary to the common perception that agile only works for small teams. The speaker emphasizes that agile can be effectively applied to large projects with hundreds of people by employing a hierarchical structure with a 'chief product owner' at the top, cascading down to various product owners for different components. The episode also touches on the importance of cross-functional communication and the challenges of estimating and planning in agile projects, advocating for relative sizing and velocity-based predictions for project duration.
Takeaways
- 😀 Agile methodologies can be applied to large teams and projects, not just small teams as often depicted in literature.
- 🔍 Large-scale agile projects may involve multiple teams, potentially hundreds, working in coordination rather than a single massive team.
- 👤 The role of a 'chief product owner' or equivalent is crucial for maintaining the overall vision and guiding the project at a high level.
- 🏢 In large enterprises, agile can be scaled by having a hierarchy of product owners for different components of the project, similar to how Microsoft might manage different parts of Office suite.
- 🔄 Agile scaling involves both vertical alignment of teams and horizontal communication across teams to prevent silos and ensure knowledge sharing.
- 💬 Encouraging communication among large groups, such as 400 programmers, can be achieved through formal and informal means, tailored to the project.
- 📈 Agile estimating involves relative sizing of tasks compared to one another rather than absolute time estimates, using units like story points.
- 🚀 Agile planning starts with estimating the size of tasks and then considering the team's pace to derive a duration, similar to estimating a real-world trip.
- 🔢 Teams use abstract units for estimating (e.g., story points, gummy bears, Cheez-Its) to establish relative sizes of tasks within a project.
- 🔮 For projects that require upfront estimates without the benefit of an existing team's velocity, more complex techniques are needed, which may be detailed in the books mentioned.
- 🌐 The script suggests that scaling agile to very large projects is challenging but possible with the right structures, like chief product owners and cross-functional teaming.
Q & A
What is the common misconception about agile teams according to the transcript?
-The common misconception is that agile teams are only effective with small teams, like the original XP team at Chrysler, and that larger teams of 50-200 people in Fortune 500 companies are a precursor to failure.
How does the speaker describe the scaling of agile methodologies to larger teams?
-The speaker explains that agile scales up well, with large projects involving multiple teams that coordinate their work rather than a single large team. The concept involves a hierarchy that understands the vision, with a 'chief product owner' at the top passing the vision down to sub-teams.
What is the role of a 'chief product owner' in a large agile project?
-A 'chief product owner' has the overall vision for the project and is responsible for passing that vision down to sub-teams, ensuring alignment and coordination across the various teams working on different aspects of the project.
How does the speaker use Microsoft Office as an example to illustrate the agile scaling process?
-The speaker uses Microsoft Office as an example to show how a visionary might have a vision for the entire suite, with 'product owners' for individual applications like PowerPoint, Excel, and Word, each with their own vision for their respective products.
What is the importance of cross-functional communication in large agile teams?
-Cross-functional communication is crucial for ensuring that different teams, such as client-side and server-side developers, are aware of each other's work and can coordinate effectively, avoiding silos and promoting standard practices across the board.
What does the speaker suggest as a method for estimating software projects in an agile context?
-The speaker suggests estimating software projects by first estimating the size of the task and then considering the pace at which the task can be completed, similar to estimating real-world activities like driving a certain distance at a certain speed.
How should agile teams estimate the size of tasks in relation to each other?
-Agile teams should use relative estimates to determine the size of tasks in comparison to others, using abstract units that are meaningful in terms of relative size but not specific time units.
What is the purpose of using abstract units like 'Cheez-Its' or 'gummy bears' in agile estimation?
-These abstract units serve as a way to provide relative estimates that are easy to understand and compare, without being tied to specific time units, which can be misleading or difficult to estimate accurately at the outset of a project.
How can teams gain predictability in their agile projects after starting work?
-Teams can gain predictability by observing their pace of work after starting the project, using the actual progress made to estimate how long the remaining work will take, thus providing a more accurate forecast of project duration.
What is the challenge when estimating before the team has started working on a project?
-Estimating before the team has started working on a project is challenging because there is less information about the team's pace and capabilities, which requires more complex estimation techniques that may be detailed in the speaker's book.
What are the three things that teams need from the company according to the first article on scrum?
-According to the first article on scrum, teams need money, moral support, and guidance from the company to be successful in their agile processes.
Outlines
😀 Agile Teams in Large-Scale Projects
The first paragraph discusses the scalability of agile methodologies in large projects, contrasting the traditional small agile teams with the reality of large corporations that may have hundreds of people working on a single system. It emphasizes the importance of maintaining agility in large teams by breaking them down into smaller, more manageable units, each with a clear vision and purpose. The speaker also touches on the concept of a 'chief product owner' who is responsible for the overall vision of the project and how this vision is cascaded down to individual teams working on different components of the project, such as different applications within a suite like Microsoft Office.
😀 Scaling Agile: Communication and Coordination
The second paragraph delves into the practical aspects of scaling agile methodologies to accommodate large teams, such as a 700-person project. It highlights the challenges of facilitating communication among large groups of developers and suggests both formal and informal methods to encourage interaction. The speaker uses the analogy of organizing a conference to illustrate the complexity of managing such large teams. The paragraph also discusses the importance of having cross-functional teams that work in alignment with the overall project vision, ensuring that all team members are aware of and contribute to the project's goals.
😀 Agile Estimating and Planning
The final paragraph shifts the focus to agile estimating and planning. It emphasizes the importance of relative estimation over absolute time estimates, using everyday examples like driving a car to illustrate the concept. The speaker suggests that teams should estimate the size of tasks relative to one another and then use their velocity, or pace of work, to predict how long the project will take. This approach allows for more flexibility and adaptability in project planning, as it accounts for the variability inherent in software development. The paragraph concludes with a brief mention of the challenges of estimating before the project has begun and hints at more advanced techniques for such situations, which are explored in the speaker's books.
Mindmap
Keywords
💡Agile Teams
💡Extreme Programming (XP)
💡Fortune 500 Companies
💡Scaling Agile
💡Chief Product Owner
💡User Stories
💡Estimating
💡Product Backlog
💡Scrum
💡Vertically Aligned Teams
💡Orthogonal Teaming
Highlights
Agile teams are often associated with small teams, but the concept can scale to larger teams within large organizations.
Large companies like Anderson, Accenture, or Ernst & Young can implement agile methodologies with teams of 50-200 members.
Agile methodologies can be scaled up for large projects with the help of a Chief Product Owner and a hierarchical vision passing.
The concept of scaling agile involves coordinating work across multiple teams rather than a single large team.
Agile scaling can be achieved through vertical alignment and crosscutting dimensions across teams.
The importance of establishing a vision and passing it down through sub-teams in large-scale agile projects.
Use of the term 'Chief Product Owner' for overseeing large-scale agile projects.
The example of Microsoft Office to illustrate the hierarchical structure of product owners in a large agile project.
Agile teams require money, moral support, and guidance from the company to function effectively.
The role of wine product owners in owning specific components of a product within a large agile project.
The need for communication and coordination among teams, even in large-scale agile projects.
The challenge of encouraging communication among large groups of developers in agile projects.
The use of scrum as an agile process and its emphasis on the needs of teams for money, moral support, and guidance.
Agile estimating involves estimating the size of tasks and then estimating the duration based on pace.
The importance of relative estimating in agile projects, comparing the size of tasks to each other rather than absolute time units.
The process of using abstract units for estimating in agile projects, such as 'gummy bears' or 'Cheez-Its'.
The method of using the pace of work done to predict the duration of a project once the team has started working.
The difficulty of estimating before a team has started working on a project and the need for more complex methods.
Transcripts
[Music]
welcome to on
software conversations with thought
leaders in software
development brought to you by
a lot of times switching taxs just a
little bit you mentioned you know coming
into your agile team MH uh a lot of
times when you hear people talking about
agile teams when you hear people talking
about like for example the original XP
team at at Chrysler and so forth uh
they're talking about relatively small
teams right right and then you walk into
some of these Fortune 500 companies
where they've got like a Anderson or an
Accenture or you know ernston young or
whatnot and they have these 50 100
200 man teams working on some large
system right um is that just a precursor
to failure does an agile team have to be
less than a dozen people less than a
half dozen people you know how well does
does this notion of agility in large
project space user stories in large
project space how well do these go
together right well there was a real
danger in a lot of the agile books it's
very tempting to write this way to
describe agile for a loan team on a
desert Island right our our little seven
or eight person team on a desert island
and it's it's a great way to explain
some things right you know here's how it
works but then you have to make sure
that if you're if you're writing a book
or an article on agile that you explain
well that's not all there is here's the
other things that have to happen right
and one of the things that agile authors
the very beginning did the earliest
agile books that 99 to 2001 or so books
did was really stress that hey here's
the context I've used this on and they
were small projects and now somebody
these days comes along reads that book
and says oh it's only useful on small
projects right and no it was just more
the uh the honesty of the authors's
writing a book saying hey I've used this
on five and 10 and 20 person teams no
bigger right go try it if you want and
let me know how it goes that was the
attitude at the time and we've since
learned that agile scales up very well I
was uh with a company last week that is
uh embarking on a 700 person agile
project now they're not going to have
700 people in one room one team that
might be 100 teams it might be 80 teams
but it'll be a lot of teams it have to
coordinate their work rather than one
700 person team so how do you scale it
up I mean just in a nutshell how do you
take a 700 person project and run it as
a 100 teams of seven without having five
levels of management in between the guy
in charge of the whole thing and the
individual programmers we're not going
to you know I'm going to start out with
the with the with the Assumption there
uh the guy in charge of the whole thing
right there really is no the guy in
charge of the whole the whole thing
there is probably somebody with the
overall Vision somebody establishing a
vision for what we need um I like the
scrum terms for most of these things i'
would be somebody called a product owner
on a big project like that we'd probably
call them a chief product owner
different companies all have different
names for this um I just like Chief
product owner is the most generic of
these um that person has the overall
Vision what are we trying to establish
they're going to have to pass that
Vision down to uh to teams uh sub teams
in ways and they'll do that so they'll
be typically a hierarchy that
understands the vision there um let's
just use Microsoft Office as a wonderful
example because it's product everybody
understands so we might have a Visionary
that understands where are we going with
with office and then underneath there
there might be what we'll call a wine
product owner wine product owner might
own PowerPoint another wine product
owner would own Excel another for word
something like that those people then
have a vision for what needs to go in
those products they'll have product
owners underneath them so these people
are not running the project they're just
kind of the the person with the vision
we're going to scale that up by having
teams Associated down those same
hierarchies um but the teams coordinate
their work in ways that they determine
uh I really like the uh the very first
article on scrum came out in 1986 scrum
is one of the agile processes and it
talks about that teams need three things
from the company it said they need money
moral support and guidance I need money
need to get paid things like that need
moral support you know encouragement
when things are going poorly things like
that um and we need guidance so that's
what these product owners are there to
do provide guidance well I want this
feature or I prefer this over that that
type of setup we scale the project up by
then uh setting up different teams
giving them these guidance say going
after these these features but agile
teams on their own are not enough I like
to think of the agile teams as being
vertically aligned I want to take some
kind of crosscutting Dimensions across
those teams I don't want to have a 700
person team with let's say 400
programmers and the programmers never
talk so I want to set up some orthogonal
teaming structures across there and say
hey 400 programmers go talk sometime
right and that'll be some responsibility
for the wine manager maybe there's a a
technology director who runs that 400
person group make sure they're talking
doing things in standard ways it's
almost like organizing a small
conference with 400 programmers yeah
yeah I mean that's got that's got to be
a fairly intimidating idea of trying to
get 400 people to talk to one another
you know about whatever about you know
language or or feature whatnot I mean
how do you encourage that kind of
communication uh well it can be it can
be established formally it can be done
in formally however is appropriate for
the project right I mean we're using the
700 example because that's where I
happened to be last week right more
realistically would be be probably
talking about an agile team that's
scaling up in the 1 to 3 400 range I
those are much more common and you might
be talking 50 60 70 programmers um even
them they may split into two categories
real easily right we've got client side
server side so I don't necessarily have
to have all 400 talking to each other
right okay so it's you know it's the
typical challenges that faced a typical
development director VP development with
a a medium to large group so you
mentioned that you've done two books and
we've been talking about user stories uh
estimating and planning right once I've
got my stories in place I mean this has
always to me been the hardest part of
any programming job you know your boss
comes to you and says we here's here's
what you need to do how long will it
take you um you know just in a nutshell
right give me give me like the the two
sentence uh story around agile
estimating and planning how do you do it
in two sentences two sentences no more
than that so I don't have to buy the
book I'm teasing I'm
teasing uh two sentences I would say
that uh I don't if I have exactly two
but the the idea for me is to estimate
software projects in the way that we
estimate real world activities and to do
that the best example of that is that we
we estimate the size of something and
then we think about how fast we can do
that thing and then we convert the we
can put those two together to come up
with a duration so let's suppose that we
were to drive from here in San Jose
today and we wanted to drive to Austin
Texas well we might think about that if
we had to estimate that drive we'd kind
of visualize a map think about that I
have no idea how far that is I'm just
going to make up some easy math in my
head let's say it's 1,200 miles right we
would think about it being 12200 miles
then we'd think about our Pace say well
I bet I go 60 M an hour on average right
I got to stop every now and then I'm
also going to be going 70 during those
empty parts of Texas or 80 or 90 well
I'm not going to say that on tape I'm
going to go 60 maybe 70 and uh I'm going
to divide the 12 1,200 mil then by the
60 M hour come up with around 20 hours
as my estimate that's a real world best
practice way to estimate estimate the
size of something and drive the duration
so when uh I want teams to estimate on
on software projects I don't want them
to go to the first principal question of
how long will this take right how long
will it take to add tables to a word
processor again for example um I want to
think about how big it is right what is
the size of this task compared to others
right and so for example it's estimated
a word processor right now something I
don't think either of us have worked on
so if uh you know if we think about uh
putting bold text into a word processor
I don't know how long that'll take but I
bet it'll take the same amount of time
as italicizing text does inside of a
word processor so I'd put that same type
of number on there so I want to put
these relative estimates on there rather
than absolute estimates that that mean a
Time unit so we go through a uh the
entire list of features to be added uh
call that a product backlog typically on
an agile project we' estimate the size
of things so now I'd have all these
relatively uh valid but somewhat
meaningless numbers know this one's a
five this one's a 20 all that means is
it takes four times longer and then we'd
get started so these aren't necessarily
an hours they're just
abstracts absolutely absolutely they
I've seen teams estimate them in what
they they'll call them gummy bears I've
seen teams call them uh Cheez-Its uh
just you know they they called it Cheez
itss based on like the number of boxes
of Cheez itss that they thought one of
their main developers would eat in a
particular day uh or while doing that
feature so they'll be meaningless units
but they're they're relatively valid the
20 is about four times as big as a five
a one is a fifth of a five and teams
will add these up and say well we have a
thousand points to do or a thousand
cheit to do I no idea how long that's
going to take you but then we get
started on the project we run the
project for a couple of weeks see how
far we've got done and then we can take
that pace that we're getting done and
divide it into the uh the total size of
the project starts to give us some
predict ability that's that's far more
than two senses but that's a simple
version of it the where it gets harder
is where teams have to estimate before
they've started right there are times if
we're doing a contract for example I
can't let the team get started for two
weeks right I have to estimate before I
do that that's you're going to have to
buy the book for I can tell you but
that'll be that'll be that'll be harder
to fit into two te that's the point
that's the teas there are ways to do
that so this is not valid only when you
have an existing team that's already run
a little bit um there are ways to do it
uh even without that but they're they're
harder to
explain for more information visit onp
podcast weekly.com And subscribe to all
our
podcasts brought to you by the
publishing imprints and information
portal of Pearson Education
[Music]
[Music]
Ver Más Videos Relacionados
What are Story Points and how are they used in Jira | Story Points vs Hours estimation
HOW TO USE JIRA | Free Agile Project Management Software (Jira tutorial for Beginners)
It’s time to move on from Agile Software Development (It's not working)
Must-Have Skills For Agile Project Managers
1-2 Why learn Software engineering
What Is Agile Model In Software Engineering? | Agile Methodology Explained | Simplilearn
5.0 / 5 (0 votes)