Date post: | 27-Jan-2015 |
Category: |
Technology |
Upload: | chris-sterling |
View: | 105 times |
Download: | 0 times |
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
How Do Self-Organizing Teams Function?
2Saturday, May 22, 2010
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.” *
3Saturday, May 22, 2010
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
4Saturday, May 22, 2010
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
5Saturday, May 22, 2010
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
6Saturday, May 22, 2010
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.
7Saturday, May 22, 2010
Scaling Patterns
8Saturday, May 22, 2010
Component Team Pattern
9Saturday, May 22, 2010
Feature Team Pattern
10Saturday, May 22, 2010
Team Configuration Patterns
Virtual Architect Pattern
Integration Team Pattern
Component Shepherd Pattern
Team Architect Pattern
11Saturday, May 22, 2010
Virtual Architect Pattern
EnterprisePlanning
12Saturday, May 22, 2010
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
13Saturday, May 22, 2010
Integration Team Pattern
Feature Development
Integrate Features
All features are implemented
and integrated every iteration
14Saturday, May 22, 2010
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
15Saturday, May 22, 2010
Component Shepherd Pattern
16Saturday, May 22, 2010
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
17Saturday, May 22, 2010
Team Architect Pattern
18Saturday, May 22, 2010
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
19Saturday, May 22, 2010
How Does Scrum Fit into the Bigger Picture?
20Saturday, May 22, 2010
Planning at Multiple Levels
21Saturday, May 22, 2010
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”
22Saturday, May 22, 2010
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
23Saturday, May 22, 2010
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
Comm. & Collaboration
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.
Comm. & Collaboration
Platform• UI Consistency
• For all users, improve customization and consistency.
• For Product Owners, improve Roadmap, and Release Planning.
Magnesium
24Saturday, May 22, 2010
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
25Saturday, May 22, 2010
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
26Saturday, May 22, 2010
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!!
27Saturday, May 22, 2010
Sample Release Planning Session
Show Me
28Saturday, May 22, 2010