Agile Project Management

Jim Highsmith

Chapter 11

Scaling Agile Projects

Scaling Problems

Expected success rates on small (< 10 people), short (3

– 6 months) projects is high.

Success rates on large(1,000+ people), long (> 18

months) projects is much lower.

Problems with large projects:

Increased bureaucracy

Excessive paperwork

Unmanageable communication networks

Inflexibility

“Management expertise has become the creation and control of constants,

uniformity, and efficiency, while the need has become the understanding and

coordination of variability, complexity, and effectiveness.”

Dee Hock 1999

Scaling Factors

Given two teams… one a 6-person collocated team and

the other a 100-person team divided into eight feature

teams.

Task:

Setting up and maintaining the process and tools for Build,

Integration, and Testing (BIT)

How does the 6-person and the 100-person team handle BIT?

6-person team:

Handled collaboratively with the entire team making the decisions and

sharing knowledge would be informal and interactive.

Team members would rotate BIT maintenance activities informally

100 person-team and Build, Integration, and Testing tasks

A part-time BIT team of 3-5 people would be drawn

from feature team members who had expertise and

interest in BIT

BIT team would discuss issues, do research, & propose

the process and tools.

The proposal would be discussed with feature teams,

with team members providing feedback

BIT team would make final decisions, set-up the BIT

environment & document the process.

BIT team members would provide guidance

Support of BIT would be done by a rotating team

Collaboration and Coordination

For an organizational perspective, agilists view all

interactions as collaborative.

Collaboration (working together to make a decision) is

expensive… the BIT team collaborates to make

decisions then coordinates those decisions with the

feature teams.

“Interpretation of Agile principles” … but as projects

get larger, appropriate interpretation and application of

the principles becomes difficult and more critical to

success.

A 100-person team will never feel like a 6-person team, but each can definitely be

agile. The key is appropriately applying agile principles to organizational design,

decision making and collaboration/coordination design.

Uncertainty and Complexity

• Uncertainty comes from issues such as market

uncertainty, technical uncertainty, number of

customers, and project duration.

• Complexity comes from factors such as team size,

team location, dependencies, and domain knowledge.

• Key questions…

Should the project be agile?

How should we adapt agile practices for this type of project?

and… do we have a culture that capable of applying Agile

principles to their project work and responsibilities?

Organization

Product

Management

Team

Release/Project

Management

Team

Feature

Team

Product Backlog Process

Agile Values

Business Goals

Capability 1 Capability 2

Feature 1 Feature 3Feature 2

Story 3

Story 1

Story 2

Story 6

Story 4

Story5

Story 9

Story7

Story 8

ProductRoadmap

ReleasePlan

IterationPlan

Figure 11-1 An Agile Scaling Model

Building Large Agile Teams

Bigger teams involve the need for more communication, more decisions, more meetings, more documents, and more politics… all of which are of value to the development of the project.

Concerted effort in 4 areas is a perquisite:

1. Organizational design

2. Decision-making design

3. Collaboration/coordination design

4. Applying Agile principles

Collaboration, coordination and knowledge sharing can result in too much communication, endless meetings, tons of documentation and emails.

Organizational Design

Hierarchical structures and not compatible with the core values of a “adaptive” workplace.

“The political agenda was furthered d by the hierarchy chart, which had little to do with dynamic, highly functional information management teams.

Hierarchical IT infrastructures established an atmosphere where politics flourished and collaboration floundered.

Hierarchies also let to an embedded culture that fostered adversity and encouraged the consolidation of individual power gases, as opposed to delivering quality information to the enterprise.

As power gases enlarged, struggles ensued and adversity grew. You soon had an environment where 80% of workers’ time was dedicated to working around the system, and only 20% was focused on doing their job.

Hierarchical management structures are also a classic way to punish those that refuse to play the game and to reward those who know how to manipulate the political machinery”

Feature Teams

A-N

A Network Organizational Structure Figure 11-2

Collaboration / Coordination Design

What makes communications design so difficult…. is that it

rests on a foundation of relationships… of trust, respect,

appreciated cultural differences and shared context.

A team “in sync” can get away with lower effective means

of communicating because they have good relationship

contexts for sharing information.

Reference… to an approach to implementing large self-

organizing teams.

Simple set of collaboration guidelines • Use a wide variety of interaction modes

• Match interaction needs with collaboration practices

• Use lower-cost modes to the extent possible

• Use higher effectiveness modes on critical, higher-risk

activities.

“Traveling pairs”

“Every other iteration, a pair from one feature team

could travel to the second site where they then pair with

developers from the second team.”

… transferring knowledge about the team’s features at a

working level.

“No matter how good the architectural decomposition of

a product, two distributed teams working on the same

product need a certain amount of working-level

conversation and collaboration.”

“Exchanging people will be much more effective than

exchanging paperwork.” … or emails

Decision-Making Design

When there is high risk, lots of coordination and collaboration is needed.

Framing questions for decision design:

• What task are being accomplished by each feature and specialty

team and what key decisions need to be made to complete these

tasks?

• What other teams are impacted by the decisions?

• Do any of the impacted teams need to be involved in the

discussions about the decision?

• Who should make the decision (the feature/specialty team, the

iteration manager, the product manager, the project leader, the

project leader with the team)?

• How and to whom should the decision results be communicated?

• Who if anyone, should review the decision?

Feature team guidelines:

“If in implementing a story the team abides by guidelines established (architectural decisions made by the preceding process, for example) and that implementation does not appear to impact any other team, then the feature team is delegated the right to make all decisions relevant to their story.”

“Decision-making design should be part of the working agreement that all agile teams develop.

Teams should not make unilateral decisions on items that impact another team without engaging that team in the decision process. So, for example, a team could not change an interface design without coordinating it with other teams that use the interface.”

How is a large agile team different from a large

traditional team from an organizational perspective?

1. A large agile team has a flatter, less hierarchical structure – fewer layers of managers.

2. To the extend possible, decisions are pushed out to the feature teams or specialty teams.

3. Feature team members participate in specialty teams to ensure their input is heard and to take part in the decisions

4. Team decision making, whether project or technical decisions are being made, are accomplished in a participatory fashion.

5. Specialty teams are encouraged to issue guidelines, not fiats, and furthermore – like managers – they are encouraged to make as few decisions as possible.

6. Peer-to-peer (feature team to feature team) interactions and dependency management are encouraged. For example, rather than having a project leader manage inter-team dependencies, the teams themselves manage them through mechanisms such as Inter-team Communication Stories (ICS)…

7. The team embraces agile principles.

Knowledge Sharing & Documentation

Agile Documentation Guidelines

• The fundamental issue is knowledge transfer – understanding, not documentation.

• Knowledge transfer requires person-to-person interaction, particularly as the complexity of the knowledge increases.

• Documentation should be barely sufficient, but not insufficient: User overviews rather than try to document all the details.

• High-quality readable code and test cases, particularly when the test cases are automated, may be adequate for detailed requirements documentation.

• Models are a form of documentation. Keep them light and barely sufficient also. Develop only those models that are useful to the development team, and develop them “with” the team.

• Documentation should be as informal as possible – while boards, flip charts, digital pictures, wikis, etc.

Agile Documentation Guidelines (continued)

• Interactive, dynamic documentation is important in agile projects:

Wiki, Web 2.0

• Working software is one goal of development, enabling the ongoing

enhancement of that software is a second. Think about the barely

sufficient documentation to support both.

• Documentation requirements vary by industry, company, and

project.

• Permanent documentation is hat which as organization is will to

spend the money, and time, to maintain. Working papers are

documents that are used during a project (and may be very informal)

but are not maintained. Don’t confuse these two types.

• User documentation should be identified as a story and prioritized by

the customer team just as software stories.

Self-Organizing Teams of Teams

Large agile teams consist of multiple feature and specialty teams… individuals are the agents in teams, whereas feature teams are the agents in a larger project.

A network replaces the common hierarchical structure…

Decision making and collaboration must be carefully designed… with discipline reflecting the rules of engagement across teams.

What is needed:

– The right leaders

– Articulating the work breakdown and integration strategies

– Encouraging the interaction and information flow across teams

“The project leader’s role should be to facilitate the

interactions between the teams, not the specific activities

each team uses to produce deliverables.”

Key inter-team task is managing dependencies, a task frequently

relegated to the project leader…

All to often dependency management falls into the same

traditional trap… management by documentation and not

conversation.

Each project is unique… leadership needs to experiment with

interaction practices just as it does with technical practices.

Similarly, establishing inter-team rules of engagement and

accountability are important.

Example Rules of Engagement (Fig. 11-5)

Feature Teams

• Shall have input to, and

participate in (the number of

participating teams may be

limited) architectural decisions

that impacts tier work

• Shall have the right to assess

the impact of any architectural

change and adjust estimates

and schedules accordingly.

• Shall have the right to request

that the project leader review

any architectural decision in

which the team’s objection is

overridden.

Architecture Team

• Shall receive prompt

information about and

feedback on proposed

architectural plans.

• Shall expect prompt

notification of problems that

feature teams encounter in

implementing architectural

decisions.

Team Self-Discipline

Individuals have responsibilities to their teams… teams

must be self-disciplined in working within a larger self-

organizing framework.

Team behaviors closely parallel those of team members:

• Accepting accountability for project results.

• Engaging collaboratively with other feature teams.

• Work within the project self-organizing framework.

• Balance project goals and team goals.

“When a team estimates how many stories it can deliver in an iteration, its

members must factor in time to coordinate with other teams because team

members will undoubtedly serve on specialty teams.”

Process Discipline

Larger teams and excessive process … problems.

Example

End of wave… integration of several modules causes a few days of extra work.

Typically, the problem leads to additional meetings to correlate the work.

The meetings may take more time that fixing the problem… as well as unanticipated consequences of implementing the fix.

So… the issue is not to react and attempt to anticipate “every” problem and establish processes to do this… it’s cheaper and faster to fix problem but not spend time anticipating them.

I’m not sure how Highsmith’s rule “Don’t always fix things that are broken” applies to this example.