UW Agile CP202 Adv Topics Class 4 Scaling Multi-Level Planning Portfolio Management

UW Agile CP202 Class 4:Scaling, Multi-Level Planning, and Portfolio Management

Chris SterlingTechnology Consultant / Agile Coach /

Certified Scrum TrainerSterling Barton, LLC

Web: www.SterlingBarton.comEmail: [email protected]

Blog: www.GettingAgile.com Follow Me on Twitter: @csterwa

Hash Tag for Presentation: #swdebt

1Saturday, May 22, 2010

http://www.SterlingBarton.com

http://www.SterlingBarton.com

mailto:[email protected]

mailto:[email protected]

http://www.GettingAgile.com

http://www.GettingAgile.com

How Do Self-Organizing Teams Function?


Self-Organizing Project Teams

* “The New New Product Development Game”, by Hirotaka Takeuchi and Ikujiro NonakaHarvard Business Review, Jan/Feb 1986

“A group possesses a self-organizing capability when it exhibits three conditions: autonomy, self-transcendence, and cross-fertilization.” *


Autonomy

External support is limited to guidance, budget, and moral support

Team is free to set its own direction

Management acts as a venture capitalist to Team

Scrum Teams exhibit autonomy when:

Product Backlog describes the “what” not the “how”

Team delivers potentially shippable product increments each sprint

Team delivers on its commitments


Self-Transcendence

Teams are in a continual quest towards “perfection”

Teams find creative ways to break the status quo

Teams don’t say “we can’t change that”; instead it just might take time to implement some changes

Scrum Teams exhibit self-transcendence when:

Retrospectives lead to changes in process every sprint

Team feels empowered to increase their capabilities and knowledge while delivering product

Organization supports team by removing impediments


Cross-Fertilization

Teams are made up of people with differing personalities and capabilities

Team members find ways to fill gaps in load by cross-fertilizing specific capabilities to other team members

Scrum Teams exhibit cross-fertilization when:

Teams finish Product Backlog items early in sprint cycle

Each Team member has work to do during entire sprint

Specific tasks are NOT expected to be finished by a particular member of the Team


Beginner’s Mind

“In the beginner's mind there are many possibilities, but in the expert's there are few.” *

People open up minds to looking at situations as fresh and new, testing their knowledge and environment

ScrumMasters can help Teams become more self-organizing by challenging what is thought to be known

Ask thoughtful questions to help Team think outside box

Look for times Team is in some discomfort and facilitate them in deriving creative ideas and solutions

Encourage Team to “Pair” on tasks during sprint* “Zen Mind, Beginner's Mind”, by Shunryu Suzuki, Weatherhill.


Scaling Patterns


Component Team Pattern


Feature Team Pattern


Team Configuration Patterns

Virtual Architect Pattern

Integration Team Pattern

Component Shepherd Pattern

Team Architect Pattern



EnterprisePlanning



Pros

Share architecture ideas and needs across teams

Based on verbal communication

Cons

Usually singles out special Team Member role

Could lead to top-down architecture decisions

IT may gain extensive influence and begin to run Product Backlog



Feature Development

Integrate Features

All features are implemented

and integrated every iteration



Pros

Reduces complexity on Feature Teams

Forces delivery from Integration Team instead of interface and deployment designs

Cons

Perpetuates specialized roles

Don’t always work on highest value Product Backlog items



Pros

Share more knowledge within organization to minimize platform experience debt

Work on highest value Product Backlog items

Cons

Not always optimal as using individual knowledge

Difficult to learn multiple systems across Teams



Pros

Team owns architecture decisions

Decisions are made close to implementation concerns

Cons

May not have appropriate experience on Team

Team could get “stuck” on architecture decisions


How Does Scrum Fit into the Bigger Picture?


Planning at Multiple Levels


Product Vision

FOR (target customer)

WHO (statement of the need)

THE (product name) is a (product category)

THAT (product key benefit, compelling reason to buy).

UNLIKE (primary competitive alternative),

OUR PRODUCT (final statement of primary differentiation)

Geoffrey Moore “Crossing the Chasm”


Product Roadmap

• The Product Owner:– Communicates the whole– Determines when releases are needed– Determines what functionality is sufficient– Focuses on business value derived from the releases

• Delivery team – Sees the whole– Learns about the steps– Learns the business priorities– Provides technical input to the roadmap


Product Roadmap – an example

Phosphorus

Agile PM

• Associate Iterations with Releases

System Mgmt.• Hierarchical Stories• Daily Defect Metrics

Comm. & Collaboration

Platform• Tab Customization & Web

Tabs

• For all users, enhance flexibility of requirements

hierarchy• Provide Configurable Editions

June 3, ‘06 July 8, ‘06 Aug 12, ‘06

Agile PM

• Agile Product Manager

System Mgmt.• Ajax-Enabled Detail Pages


Platform• Improved UI Responsiveness• Improved Navigation

• For all users, improve usability, navigation and information

presentation.

Agile PM

• Defect Dropdown Customization

• Task Ranking

System Mgmt.• Defect Close Rate Metrics

Comm. & Collaboration• User Filterable Notifications

Platform• Shared Custom Views

• For Rally customers, implement some of the most

requested enhancements

Aluminum Silicon

*Rally Agile Pro Edition only

April 8, ‘06

Agile PM

• Custom Enumerations• Unified Backlog Planning• New Release Status View

System Mgmt.


Platform• UI Consistency

• For all users, improve customization and consistency.

• For Product Owners, improve Roadmap, and Release Planning.

Magnesium


Release Planning – Getting Started

The Product Owner and the team should:• Complete planning levels 1 & 2 – the product roadmap

– Indicates the focus, or theme, of the next releases• Collect product features in the product backlog• Prioritize the features in the product backlog• Determine when the release is needed• Decide what to put in the release• Prepare to present the product vision• Be open to the negotiations that will occur


Release Planning – Getting Started

The Delivery Team should:• Have a high-level understanding of the features in the product

backlog• Determine a team nomenclature for high-level estimates: Story points

or T-shirt sizing (S, M, L)• Define the team velocity (capacity):

– Three ways to get an initial value for velocity*:•Use historical values (yesterday’s weather)•Run an initial Sprint and use the velocity from that Sprint•Take a guess

* Mike Cohn, User Stories Applied


Release Planning • Conduct a Release Planning Meeting collaboratively with the whole team (product

owner, delivery team, stakeholders)• Plan for a 1-day event (2 days for VERY large programs)• Put each feature on an index card (post-it notes)• Physically arrange the prioritized features into the Releases• For the first release, physically arrange the prioritized features into the 3 or 4

groupings that represent the Sprints • Post all decisions and assumptions on the wall

Biggest risk:Product Owner must have a prioritized Product Backlog!!


Sample Release Planning Session

Show Me


https://dogma/PS/AC/Shared%2520Documents/Course%2520Material/Certified%2520ScrumMaster/Release%2520Planning%2520.mov

https://dogma/PS/AC/Shared%2520Documents/Course%2520Material/Certified%2520ScrumMaster/Release%2520Planning%2520.mov

UW Agile CP202 Adv Topics Class 4 Scaling Multi-Level Planning Portfolio Management

Technology

Transcript of UW Agile CP202 Adv Topics Class 4 Scaling Multi-Level Planning Portfolio Management