Agile Project Management

Jim Highsmith

Chapter 9

The Explore Phase

1

Major Explore Activities

Iteration Planning &

Monitoring

• Iteration planning

• Workload management

• Monitoring iteration progress

Technical Practice

• Technical debt

• Simple design

• Continuous integration

• Ruthless automated testing

• Opportunistic refactoring

Project Community

• Coaching & team development

• Participatory decision making

• Collaboration & coordination

2

APM Envision and Explore Cycles (Fig. 9-1)

Product

Vision

Release Plan

Project Scope

and Boundaries

Envision Cycle Explore Cycle

Review and

Adapt Develop

Iteration Plan

3

Complex Adaptive System (CAS)

“… collection of agents who explore to achieve a goal by

interacting with each other according to a set of rules.

CAS experiments with alternatives, selects and executes

viable ones, compares the results against its fitness goals

(the system’s objectives), and adapts as necessary.”

“… the project leader’s job takes on new dimensions – to

constantly help the team articulate and understand the goal

and the constraints, to help the team interact effectively, to

facilitate the decision-making process, to encourage the

team to take risks, to ensure appropriate feedback is being

gathered and incorporated into the next iteration, and to keep

score and deal with reality when things go off track, as every

project does.” 4

Iteration Planning

After the overall “release plan” has been set… the team

develops a detail plan for the next (or the first) iteration.

For each story assigned to the iteration tasks need to be

identified:

List the technical and other tasks required to implement the

story

Re-estimate the work effort and adjust the stories planned… if

necessary

Example:

Iteration 1 Concept Phase – stickies (Figure 9-2)

Task list breakdown for a story (Figure 9-3)

5

Story Progression During an Iteration Fig. 9-4

On Deck In Process Done Done-Done

As a sales associate,

the ability to calculate

the total amount of

the sale

4

As a sales associate,

the ability to calculate

the total amount of

the sale

4

As a sales associate,

the ability to calculate

the total amount of

the sale

4

As a sales associate,

the ability to calculate

the total amount of

the sale

4

As a sales associate,

the ability to calculate

the total amount of

the sale

4

As a sales associate,

the ability to calculate

the total amount of

the sale

4

As a sales associate,

the ability to calculate

the total amount of

the sale

4

As a sales associate,

the ability to calculate

the total amount of

the sale

4

As a sales associate,

the ability to calculate

the total amount of

the sale

4

As a sales associate,

the ability to calculate

the total amount of

the sale

4

As a sales associate,

the ability to calculate

the total amount of

the sale

4

As a sales associate,

the ability to calculate

the total amount of

the sale

4

As a sales associate,

the ability to calculate

the total amount of

the sale

4

6

Iteration Planning - Participants

• Product manager

• Product specialist

• Customers

• Developers

• Testers

• Iteration manager

• Project leader

How long does this take?

– 1 to 2 hours per week of

iteration

– For a 3-week iteration, 3-6 hours

If there are iteration “themes”

spanning a number of iterations,

the related stories in subsequent

iterations should be revisited and

adjusted if necessary.

Teams should be heavily involved in planning, estimating, and

executing the iteration plan… which requires accountability.

Team commitment is critical…

7

Estimating and Task Size

Objective: to match capacity with plans …and try to

increase the capacity through productivity

improvements during the project’s life.

The “right size”?

Guideline example: expect stories to take 20-10 days of effort

and tasks less than 8 hours.

“As long as teams are delivering on their commitments,

they should decide the level of task detail.”

8

Iteration Length

Criteria in setting iteration length:

1. Delivering chunks (stories) of user valued functionality

2. Building and testing the stories (working software) - done

3. Product team acceptance of the stories – done done

Additional factors are release timeframe, exploration factor, overhead and learning needs.

Failing the “user-valued functionality” test

The stories completed have little meaning to the customer team… typically technical stories.

Iteration length must account for the time it takes for unit testing, integration and QA testing… all the necessary work!

9

What does it take to be “done done”?

Criteria checklist (XP): • Tested (all unit, integration, and customer tests finished)

• Coded (all code written)

• Designed (code refactored to the team’s satisfaction)

• Integrated (the story works from end to end – typically, UI to database – an fits into the rest of the software)

• Builds (the build script includes any new modules)

• Installs (the build script includes the story in the automated installer)

• Migrates (the build script updates database schema if necessary; the installer migrates data when appropriate)

• Reviewed (customers have reviewed the story and confirmed that it meets their expectations)

• Fixed (all known bugs have been fixed or scheduled as their own stories)

• Accepted (customers agree that the story is finished)

The Art of Agile Development, James Shore and Shane Warden, O’Reilly, 2008.

10

Other considerations in setting Iteration length

• Release timeframe – longer-release timeframes

accommodate longer iteration lengths

• Exploration (the uncertainty) factor

• Preparation and review time impacts iteration length

Affected by:

requirements definition

iteration planning

backlog management

Review includes times for customer focus group feedback,

retrospectives and technical reviews

• Learning needs

11

Other considerations in setting Iteration length (continued)

Learning needs

Having to do things frequently improves learning

… as well as high frequency forces teams into learning how to

do things quickly.

Immature teams want longer iterations … lacking confidence

But… shorter iterations in the beginning force learning.

Fixed length iterations are necessary to develop “good

rhythm”

Optimal iteration length requires good user-oriented stories,

completion of all work, minimal delays dealing with legacy

code, and acceptance testing.

12

Workload Management

Objective: To have team members themselves manage

assignment of the day-to-day tasks required to deliver stories at

the end of each iteration.

Teams manage their own workload

Each member (and team) are accountable to deliver stories to

which they committed.

How this is done… and which team members take on which

tasks… are left to the team

Team members determine the tasks needed to deliver the

stories and sign-up for those tasks… not project leads

Workload management is also team member responsibility

Project lead intervenes when commitments are not being met.

Project lead coaches/mentors less-experienced team members 13

Project Lead (e.g. SCRUM manager)

Monitors without micro-managing

Establishes and monitors performance goals (stories, quality

targets, required practices)

Leaves management of tasks to individual team members

“… see their role not as a hallway monitor, but as a teacher

who helps with resource, information, or technical coaching.

A coaching leader’s attitude is reflected in the question, “How can I help you

deliver results?” The micro-manager’s attitude is reflected in the question,

“Why isn’t task #412 done yet?”

14

Monitoring Iteration Progress

Iteration managers meet day-to-day with the team… the

daily stand-ups

Examples of reviews using check-off charts maintained

by the team

(Fig. 9-5)

qqq Story 1

qq Task 1

qq Task 2

qq Task 3

qqq Story 2

qq Task 1

qq Task 2

qq Task 3

qqq Story 3

qq Task 1

qq Task 2

qq Task 3

Iteration 4

Story status:

q In progress

q Development Complete

q Accepted

Task status:

q In progress

q Complete

15

Task Burndown Charts

Whole tasks completed on a daily basis… feedback

used by the team… for the team’s self management.

Not to be used by the project leader or iteration

managers… takes away the team’s self management

responsibility

16

Technical Practices

Practices applied generally to many types of products…

Purpose: to keep quality high and cost of change low.

Critical to adaptability:

1. Simple design

2. Continuous integration

3. Ruthless automated testing

4. Opportunistic refactoring

The issue is to control “technical debt”

Its accumulation reduces speed of current development and

adversely impacts the ability to deliver in the future.

17

Technical Debt

How does it accumulate?

Development teams do not focus on technical excellence.

Project & Product managers push teams beyond quickness into hurrying.

Technical debt is the gap between a products actual cost of change (CoC)

and its optimum CoC.

“Rising technical debt is the single largest

impediment to continuing product viability”

“With software that has been around 10 years or

more, developers are loath to touch the now “fragile”

code.”

18

“Increasing technical debt reduces

responsiveness to customers”

Pushing for features … faster and faster … is the root cause…

Without explicit dedication to long-term technical debt

management, developers are pressured into the increasing

technical debt “trap.”

The bigger the “debt” the more expensive to fix, the more

difficult to justify, and therefore the death spiral continues.

At the start, not much incentive to manage technical debt…

“Reducing technical debt, keeping the cost of change low, has to

become an ingrained technical strategy.”

19

Simple Design

Anticipate… if there is a high probability that

something will change, design to easily incorporate the

change.

The effectiveness of simple design and refactoring

indicates to a product team how adaptable its

development process can be.

… coming up with understandable, adaptable, simple

designs takes additional time…

… but should be treated as an “investment” with the

returns accruing when needed changes are required.

20

Ruthless automated testing…

Insurance that product quality remains high throughout the

development process.

… running already tested features every iteration!

The lack of constant testing removes a necessary feedback loop

into the development process.

Wait too long and designs “solidify” … making change difficult.

What involved?

Constant unit testing, integrating quality testing into each iteration

Automating tests for continuous regression testing

“Experience has shown that the biggest difference between mature

and immature agile teams lies in their commitment to ruthless

automated testing.”

21

Opportunistic Refactoring

… continuously to improve the product design – to

enable it to meet the twin goals of delivering features

today and in the future.

… updating a product’s internal components without

changing externally visible functionality.

Refactoring at a cost anecdote… but “living with the

pain of another legacy product for which the ‘technical

debt’ had gotten away from them was something team

members were determined would not happen on this

new product.”

“One of the greatest competitive benefits of software is its

malleability. High technical debt caused by a lack of refactoring

discipline destroys that advantage.” 22

Old axiom: Get it right the first time.

New axiom: No matter how good it is the first time, it’s going to

change, so keep the cost of change low.

Support of product managers is required in order to avoid a “degraded product design”

Understanding the consequences of high technical debt is a prerequisite.

With redesign and refactoring there is a risk of breaking something that already works.

… hence the importance of integrating testing throughout the development process.

… and to avoid the difficulty that developers have in understanding code that no one wants to touch.

Persistence… required after release, iteration after iteration – investment in refactoring, redesign, and testing to maintain a product that responds to marketplace demands.

23

Coaching and Team Development

Agile management is different… not less!

“The manager’s role is to reach inside each employee and release

his unique talents into performance.”

… although there is little evidence that this is management’s

interpretation of their role.

How the project leader contributes…

1. Focusing the team on vison, objectives, and delivering results

2. Molding a group of individuals into a team.

3. Developing each individual’s capabilities

4. Providing the team with required resources & removing roadblocks

5. Coaching the customers

6. Orchestrating the team’s rhythm

24

1. Focusing the team on vison, objectives, and delivering results

“Team members want a boost every now and then, but they don’t

want meaningless rah-rah speeches.”

Key motivators … is understanding what is expected … in terms

of outcomes, not steps.

“If you have the right people, they want to know what needs to be

accomplished and their role, but they want to figure out how to

deliver the results.”

“… facing a two-year development effort seems daunting, trying

to deliver a handful of stories in the next few weeks doesn’t.”

“Define the right outcomes and then let each person find his own route

towards those outcomes.”

25

2. Molding a group of individuals into a team.

“jelled teams” … a well functioning team

How? … not easy

Requires trust, interaction, satisfactory conflict resolution and

participatory decisions making.

Trust… is the confidence among team members that their

peers’ intentions are good, and that there is not reason to be

protective or careful around the group.”

Jelled teams often have fierce debates and conflict over

issues… the focus must be on issues and not individuals.

Project lead needs to be able to manage the “mood” of the

team… IDEO example

“Great managers “know that if, fundamentally, you don’t trust people, then there is

no line, no point in time, beyond which people suddenly become trustworthy.” 26

“Interaction drives innovation”

Team members possess a complex (and unique) mix of

information and talents.

… spending time alone to develop their particular piece

of the product… with face-to-face time with others to fit

the pieces together.

With no iteration, there is not synergy of ideas and

innovation suffers.

Project leads must encourage peer-to-peer interaction,

particularly as pressure mounts and individuals have a

tendency to go “dark”.

27

“Does the team have the self discipline and character

to have successful crucial conversations?”

Each and every member must take the initiative to confront others when they are not performing, or behaving, according to team rules.

no one is exempt!

The conversation must be directed toward getting all the relevant information out on the table.

… otherwise it is a waste of time.

Note: “… a degree of ambiguity and frustration is a natural. Teams are groups of people, who respond to emotions and whose emotions may experience wide swings… over the life of the project.

“Emotional Intelligence” … the leader’s mood and behaviors drive the moods and behaviors of everyone else.

28

Team Rules of Engagement

“… not meant to reduce conflict and contention but to

direct them in positive ways.”

The team should be involved in developing, enforcing and

adapting the rules over time.

Examples:

• Everyone has an equal voice.

• Everyone’s contribution is valuable.

• Attack issues, not people.

• Keep privacy within the team.

• Respect each other and your differences.

• Everyone participates.

29

3. Developing each individual’s capabilities

Individuals contribute by applying their technical skills and

engaging in self-organizing behavior, which includes:

• Accepting accountability for results (no excuses)

• Confronting reality through rigorous thinking

• Engaging in intense interaction and debate

• Working within a self-organizing framework

• Respecting colleagues

People don’t change that much.

Don’t waste time trying to put in what was left out.

Try to draw out what was left in.

That is hard enough.

(Buckingham and Collman, 1999)

30

4. Providing the team with required resources & removing roadblocks

“Moving rocks, Hauling water”

When individuals are waiting for resources, they lose

productivity… time!

Critical dependencies between teams or outside sources must be

managed (coordinated).

Leaders remove roadblocks that impede the team from working

efficiently.

31

5. Coaching the customers

“Many internal IT project have crashed on the shoals of poor customer involvement – for the last 30-40 years.”

Fundamental problem is poor customer / developer partnership… caused by:

• Development’s lack of credibility in the eyes of customers

• Lack of customer involvement

• Poor accountability on the customer's side for making decisions and accepting the consequences

• Long development schedules, exacerbated by delivery of meaningless (to the customer) intermediate artifacts

• Unrealistic project schedules based on poorly articulated requirements

• Lack of acceptance criteria an testing by customers.

32

Coaching the “product team”

Why?

Product team members may not know how to write

acceptance tests or participate in req’ts specification

session or take part in decisions about priorities.

“Customers” must accept accountability for identifying,

defining, prioritizing, and accepting features.

In the Agile context… this coaching and training is the

responsibility of the Product Manger.

33

6. Orchestrating the team’s rhythm

Rhythms of…

Iterations. Alternating between intensity and reflection as

teams deliver features and then pause to reflect and plan.

Daily stand-up meetings and interactions with customer on

story details.

Releases, waves and iterations

Constantly thinking, designing, building, testing, and reflecting

on small increments of work.

Anxiety and euphoria in the process of solving seemingly

intractable problems.

Project leads orchestrate the beat … as a primary responsibility

34

Participatory Decision Making

Goal… provide the project community with specific practices to frame, analyze, and make the myriad decisions that arise during the project.

Note… Collaboration is about decision making!

GE jet engine plant in North Carolina

A, B and C decision's

A: decision made by plant manager, no consulting

B: decision made by plant manager, with input from people affected

C: decision made by consensus by those directly involved

with plenty of discussion

35

As plant manager she makes few decisions…

what then is her value?

The GE example:

“… She does the kinds of things that most managers talk about a lot but that they actually spend very little time on.

… her job is to keep everyone’s attention focused on the goals of the plant:

• making perfect engines, quickly, cheaply, safely.

• make sure the plant as a whole is making smart decisions about talent, about time, and about opportunities for growth

… her role is analogous to the coaching and team development practices

Leadership requires a clear focus on the creation of a supportive decision-making climate

36

Decision Framing

“Managers who make decisions without input from subordinates

and peers make poor decisions.”

“Engineers who make decisions without input from managers and

peers make poor decisions.”

Who makes the decisions is less important than getting

the right people involved in the decision process.

Shared values are essential… the Agile values and

principles.

What types of decisions are needed?

Re-planning at the end of each iteration (e.g. making trade-off

decisions – schedule versus cost versus stories)

37

For each decision type…

Typical framing questions are:

• Who is impacted by the decision?

• Who needs to provide input to the decision?

• Who should be involved in the discussions about the

decision?

• Who should make the decision (product manager, project

leader, the team, the team lead, etc.)

• What decision criteria should be used?

• How and to whom should the decision results be

communicated?

• Who should review the decision?

38

Decision Making

Decision should not result in losers and winners!

Focus should be on win-win.

Based on mutual understanding, not loud posturing.

Understanding, by all, of the underlying issues… all of them

The process can be contentious but civil, based on trust and respect … characteristic of self-organizing teams

The goal is NOT compromise… giving up one idea for another, and doing so in most cases to “go along” in order to “get along”

Any decision making process should be judged against two objectives:

1. Does the process result n the best choice given the circumstances in which the decision was made?

2. Was the decision implemented?

39

Collaboration is hard!

The decision making meeting and Kaner’s

diverge-groan-converge model

Going from diverge to converge explains how team members move from

having individual opinions to having a unified position.

Every person has a different perspective or a different experience…

which brings diversity to the decision making process… but not much

agreement.

The “groaning period” takes time… time for team members to speak and

hear… (trust is important here)

Convergence occurs individual ideas are debated and integrated into a

decision.

All have participated and agree on a unified position on the decision.

(good description of the process… page 242)

40

Decision Gradients tell a story (Fig. 9-9)

Tool for discussion and testing the decision making process

After debate… team members indicate their position.

The team can then address issues … with explanations of why

members voted in a particular way.

The resulting decision can be non-unanimous but OK if…

Everyone had the opportunity to be heard and make their “case”

Consensus does mean unanimous agreement, but does mean that all understood

the decision rationale

No one has been silenced due to fear or intimidation

The preponderance of the votes were in favor of the decision (or in favor, but

with reservations)

No one vetoes the decision (instead, they are “not in favor, but will commit”)

41

Benefits of a participatory process

• As mutual understanding of the context (including the

decision criteria) increases, the time required to make

similar decisions decreases… rapidly.

• Teams that do not take additional time in the

beginning to fully understand each other’s

perspective on some issue… will constantly argue the

same points meeting after meeting.

42

Decision Retrospection

• How do you get better at decision making unless you

understand which one worked out well and which did

not?

• “… few organizations want to examine decisions in

any depth, which is probably corresponds to the

general lace of interest in decision making” … the

process.

• Lack of retrospective analysis might result in making

the same types of mistakes over and over…

43

Leadership and Decision Making

“A good project leader has to be a visionary, a teacher, a motivator, a facilitator, and other things… a decision maker.”

Can’t the project leader’s decision making damage a self-organizing team?

What causes loss of respect for the leader?

When unilateral and seemingly arbitrary decisions are made… and less participation with the team.

Highsmith’s guidelines:

One unilateral decision every month or two

Three to four decisions per moth with team involvement

Delegating “hundreds” of other decisions to the team

Good leaders earn the credibility to make decisions… knowing when to step-in and take charge and when to encourage the team to take charge.

44

Set- and Delay-Based Decision Making

Criteria for decision making that encourages experimentation

Point-based engineering views design as a series of decisions in which each decision narrows the options for further decisions… with the product progressing from its initial abstraction to the final product.

Toyota and Set Based Concurrent Engineering (SBCE)

Postpone design decisions as late as possible

Maintain “sets” of design solutions throughout the majority of the design process

Reasoning and communicating about sets of ideas leads to more robust, optimized systems and greater overall efficiency… rather than working with one idea at a time.

The point: “There are always multiple design options… the larger the product, the more likely that early design decisions will lock the team into suboptimal decisions.”

45

Encouraging Collaboration and Coordination

Through: – Daily stand-up meetings

One objective: peer-to-peer coordination through information interchange.

“… not to be used to solve problems, only to identify them. When problems are identified, the team members get together to solve them after the stand-up meeting.”

Tool for self-organization… assist team members in coordinating their work and solving their own problems.

– Daily interaction with the product team

– Stakeholder coordination

46

Stand-up Meeting Guidelines (Fig. 9-10)

• The meetings are held at the same time and place every day.

• The meetings last less than 15 minutes

• All core team members attend the meetings.

• Product and project leaders attend as peer participants (not to gather status).

• Other managers usually do not attend these meetings, and if they do, they are observers, not participants.

• A team member, iteration, or project leader facilitates the meetings.

• The meetings are used to raise issues and obstacles but not to pursue solutions.

• Each participant is encouraged to address three questions:

What did you do yesterday?

What are you planning to do today?

What impediments are in the way

47

Daily interaction with the Product Team

Recommended…

… ensures the development efforts stay on track to meet needs

and expectations of customers.

When dealing with uncertainty, risks, requirement changes,

technical “frontiers”… product managers need to fully involved

in identifying stories, specifying requirements, determining

priorities, making key tradeoff decisions (cost, schedule, etc.),

developing acceptance criteria and tests, … etc.

48

Stakeholder Coordination

• Responsibility of project leaders.

• What you don’t want… is to be blindsided by an

ignored and therefore angry stakeholder.

• Important note… the project leader is responsible for

sheltering the team from crazy politics of stakeholder

coordination.

49