1. UW Agile CP202 Class 4:
Scaling, Multi-Level Planning, and Portfolio Management
Chris Sterling
Technology Consultant / Agile Coach /
Certified Scrum Trainer
Sterling Barton, LLC
Web: www.SterlingBarton.com
Email: chris@sterlingbarton.com
Blog: www.GettingAgile.com
Follow Me on Twitter: @csterwa
Hash Tag for Presentation: #swdebt
Saturday, May 22, 2010 1

2. How Do Self-Organizing Teams
Function?
Saturday, May 22, 2010 2

3. Self-Organizing Project Teams
“A group possesses a self-organizing capability when it exhibits three
conditions: autonomy, self-transcendence, and cross-fertilization.” *
* “The New New Product Development Game”, by Hirotaka Takeuchi and Ikujiro Nonaka
Harvard Business Review, Jan/Feb 1986
Saturday, May 22, 2010 3

4. 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
Saturday, May 22, 2010 4

5. 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
Saturday, May 22, 2010 5

6. 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
Saturday, May 22, 2010 6

7. 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” Beginner's Mind”,duringSuzuki, Weatherhill.
“Zen Mind, on tasks by Shunryu sprint
Saturday, May 22, 2010 7

8. Scaling Patterns
Saturday, May 22, 2010 8

9. Component Team Pattern
Saturday, May 22, 2010 9

10. Feature Team Pattern
Saturday, May 22, 2010 10

11. Team Configuration Patterns
Virtual Architect Pattern
Integration Team Pattern
Component Shepherd Pattern
Team Architect Pattern
Saturday, May 22, 2010 11

12. Virtual Architect Pattern
Enterprise
Planning
Saturday, May 22, 2010 12

13. Virtual Architect Pattern
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
Saturday, May 22, 2010 13

14. Integration Team Pattern
All features are
Integrate implemented
Features and integrated
every iteration
Feature
Development
Saturday, May 22, 2010 14

15. Integration Team Pattern
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
Saturday, May 22, 2010 15

16. Component Shepherd Pattern
Saturday, May 22, 2010 16

17. Component Shepherd Pattern
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
Saturday, May 22, 2010 17

18. Team Architect Pattern
Saturday, May 22, 2010 18

19. Team Architect Pattern
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
Saturday, May 22, 2010 19

20. How Does Scrum Fit into the
Bigger Picture?
Saturday, May 22, 2010 20

21. Planning at Multiple Levels
Saturday, May 22, 2010 21

22. 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”
Saturday, May 22, 2010 22

23. 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
Saturday, May 22, 2010 23

24. April 8, ‘06
Product Roadmap – an example
June 3, ‘06 July 8, ‘06 Aug 12, ‘06
Magnesium Aluminum Silicon Phosphorus
• For all users, improve • For all users, improve usability, • For Rally customers, • For all users, enhance
customization and consistency. navigation and information implement some of the most flexibility of requirements
• For Product Owners, improve presentation. requested enhancements hierarchy
Roadmap, and Release Planning. • Provide Configurable Editions
Agile PM Agile PM Agile PM Agile PM
• Custom Enumerations • Agile Product Manager • Defect Dropdown • Associate Iterations with
• Unified Backlog Planning Customization Releases
• New Release Status View System Mgmt. • Task Ranking
• Ajax-Enabled Detail Pages System Mgmt.
System Mgmt. System Mgmt.
• Hierarchical Stories
• Defect Close Rate Metrics
Comm. & Collaboration • Daily Defect Metrics
Comm. & Collaboration
Platform Comm. & Collaboration
Platform • User Filterable Notifications Comm. & Collaboration
• Improved UI Responsiveness
• UI Consistency • Improved Navigation
Platform
Platform
• Tab Customization & Web
• Shared Custom Views
Tabs
*Rally Agile Pro Edition only
Saturday, May 22, 2010 24

25. 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
Saturday, May 22, 2010 25

26. 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
Saturday, May 22, 2010 26

27. 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!!
Saturday, May 22, 2010 27

28. Sample Release Planning Session
Show Me
Saturday, May 22, 2010 28