Agile Development Teams: Scope and Scale with Mike Cohn

Summary

In 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

00:00

😀 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.

05:00

😀 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.

10:00

😀 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.

Keywords

💡Agile Teams

Agile Teams refer to groups that follow the Agile methodology, an iterative approach to project management and product development that emphasizes flexibility, collaboration, and customer satisfaction. In the script, the discussion revolves around the scalability of Agile Teams, questioning whether the methodology can be effectively applied to larger teams within Fortune 500 companies, as opposed to the smaller teams often described in Agile literature.

💡Extreme Programming (XP)

Extreme Programming (XP) is one of the most popular Agile frameworks, which was originally developed for small teams. The script references the original XP team at Chrysler to illustrate the traditional Agile approach that was initially designed for smaller groups, raising the question of how well these principles can be adapted to larger teams.

💡Fortune 500 Companies

Fortune 500 Companies are a list of the 500 largest companies in the U.S., ranked by total revenue. The script uses these companies as an example to discuss the challenges of implementing Agile methodologies in large organizations with potentially hundreds of team members, contrasting with the smaller team sizes typically associated with Agile practices.

💡Scaling Agile

Scaling Agile refers to the process of applying Agile methodologies to larger projects and organizations. The script discusses how Agile can be scaled up to accommodate larger teams, such as a 700-person project, by organizing them into smaller, more manageable units that can coordinate their work effectively.

💡Chief Product Owner

A Chief Product Owner is a role in Agile project management, responsible for maintaining the product vision and ensuring that the product meets customer needs. The script mentions this role in the context of scaling Agile to large projects, where a Chief Product Owner would oversee the vision and delegate it to sub-teams or product owners for different components of the project.

💡User Stories

User Stories are a technique used in Agile development to capture a description of a feature from an end-user perspective. They are a key part of Agile planning and are discussed in the script as a component of Agile estimating and planning, where they help teams understand and prioritize the work to be done.

💡Estimating

Estimating in the context of Agile development refers to the process of predicting the effort and time required to complete a task or feature. The script discusses the importance of estimating in Agile projects and how teams should approach it by comparing the size and complexity of tasks rather than focusing on exact time frames.

💡Product Backlog

A Product Backlog is a prioritized list of all the work items (features, requirements, improvements, etc.) for a product, as seen by the Product Owner. In the script, it is mentioned as the list of features that Agile teams estimate in size, helping them to plan and prioritize their work.

💡Scrum

Scrum is an Agile framework for managing and completing complex projects. The script references the first article on Scrum from 1986, highlighting its principles that emphasize team autonomy, support, and guidance, which are crucial for scaling Agile to larger projects.

💡Vertically Aligned Teams

Vertically Aligned Teams in Agile development are teams that are organized around specific features or components of a product, as opposed to functional silos. The script discusses the importance of having such teams to ensure that work is coordinated effectively across different areas of a large project.

💡Orthogonal Teaming

Orthogonal Teaming is a concept where teams are organized in a way that allows for cross-functional communication and collaboration. The script mentions this as a strategy to encourage communication among large groups of developers, such as the 400 programmers example, to ensure that they are working in standard ways and sharing knowledge.

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]