Ch11

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?
Figure 11-1 An Agile Scaling Model
Business Goals
Organization
Product
Management
Team
Release/Project
Management
Team
Feature
Team
Product Backlog
Capability 1
Process
Product
Roadmap
Capability 2
Feature 1
Feature 2
Feature 3
Story 1
Story 4
Story7
Story 2
Story5
Story 8
Story 3
Story 6
Story 9
Agile Values
Release
Plan
Iteration
Plan
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.
2.
3.
4.
Organizational design
Decision-making design
Collaboration/coordination design
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”
A Network Organizational Structure
Figure 11-2
Feature Teams
A-N
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.
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.
Reference… to an approach to implementing large selforganizing teams.
“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 selforganizing 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.