Your SlideShare is downloading. ×
UW Agile CP202 Adv Topics Class 4 Scaling Multi-Level Planning Portfolio Management
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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


Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 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: Email: Blog: 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