Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Scaling Agile - Multiple Team Dynamics

•Download as PPTX, PDF•
•
VersionOne
VersionOne

As more organizations begin to adopt agile on multiple, interdependent teams, how do we ensure that the success within a team can translate to success at the enterprise level? Presented by: Sanjiv Augustine, President of LitheSpeed

1 of 25
Scaling Agile Presented by Sanjiv Augustine Sanjiv.Augustine@LitheSpeed.com April 07, 2010 Multiple Team Dynamics
• Basic Adoption Threshold • Multiple Team Dynamics o Preparing for Multiple Team Rollout o Adoption Management o Team Management o Program Management • Q&A 2 Agenda Small is Beautiful “…for a large organization to work it must behave like a related group of small organizations.” - E. F. Schumacher, Small is Beautiful Image source: http://practicalactionconsulting.org/?id=is_small_beauti ful;
BasicAdoption Threshold
Traditional Silos Customer BA Designer DeveloperPM Core Team (EXAMPLE) BA / Tester BA Tester Product Owner Developer Designer Developer / BA SM Release Manager Capacity Planner Prod. Architect Tech Ops Business Sponsor Risk Assessor Security Dedicated, Integrated Scrum Team 4 BAAnalysts DeveloperDeveloperDeveloper Designers Tester The Core Project Team ideally consists of 5-9 dedicated members (7 +/- 2). The Extended Team can contain many additional members, each playing an important role, but they are typically not dedicated to the effort. TesterTestersDevs
Sprint “Ready” and “Done” Discipline What must be in place at the beginning of the Sprint for your project team to have a productive Sprint? What must be in place at the end of a Sprint to have a deployable product increment? Ready In Process Done 5
Agile Engineering Practices allow teams to move fast, be flexible and deliver high quality software: • Automated Builds & Continuous Integration reduce time and effort associated with manual builds, and risk from big-bang integrations • Simple Design & Refactoring keep incremental development from leading to poor architectures • Multi-Level/Automated Testing & Test-Driven Development reduce testing time and effort and allow developers to make changes with confidence • Pair Programming increases software quality without impacting time to deliver. Agile Engineering Practices Agile Engineering, Pg. 124 6
MultipleTeamDynamics
PreparingforMultiple TeamRollout
• Executive, senior and middle management must all be change agents • Business and IT must be willing to dedicate the appropriate resources o Agile teams require more dedication from assigned resources o Need an Agile Champion to lead the Agile program o Need to fund for experienced Agile process coaches o Need to fund for additional training and capability development o Need to fund for Agile team rooms • Process learning will consume some amount of project teams’ time and effort • Changes to existing processes will be necessary: in particular, resource management and portfolio management • The project manager and product manager roles will change significantly Large Scale Adoption Implications 9 Some typical implications of large scale adoption:
AdoptionManagement
Incremental Rollout Strategy Initial Pilots - Pilot Projects With Day- to-Day Oversight by Master Coach Expanded Pilots - Projects Using combination of Experienced Associates and Trained Associates with Master Coach oversight across Multiple Projects Enterprise Rollout - Autonomous agile capability using experienced and trained associates. Occasional master coach involvement on an as-needed consultative basis 11
Your first projects need: • Product Owner involved, accountable & empowered to control scope & schedule • ScrumMaster empowered to control process • Dedicated, integrated team • Executive support for learning and exploration • Short term initial release timeline (< 3 months) • Potential for measurable business results and impact 12 Pilot Project Selection Criteria Thanks to Mike Cohn for the image: http://blog.mountaingoatsoftware.com/four-attributes-of-the-ideal-pilot-project
Collaborative Workspace Design 13 Capital One Workspace Design, Source: http://www.degw.com/project.aspx?id=14&p=Capital+One
14 Create a defined and reliable process: • Standardize high-level process steps, deliverables, tools and artifacts • Agree on process audit procedures • Develop standard process metrics Process Standardization The Six Sigma Paradox To attain six sigma performance, we must minimize process variability, slack and redundancy by building variability, slack and redundancy into our organizations.
TeamManagement
16 Conquer and divide by building a federation of agile teams: • Build the “whole” into the “parts” • Set a size limit ( e.g. 7 +/- 2 people) • To grow, create new integrated Agile teams when team size limit is reached • Coordinate among teams via an Agile PMO Scaling Agile Teams
Agile Engineering Practices allow teams to move fast, be flexible and deliver high quality software: • Automated Builds & Continuous Integration reduce time and effort associated with manual builds, and risk from big-bang integrations • Simple Design & Refactoring keep incremental development from leading to poor architectures • Multi-Level/Automated Testing & Test-Driven Development reduce testing time and effort and allow developers to make changes with confidence • Pair Programming increases software quality without impacting time to deliver. Agile Engineering Practices Agile Engineering, Pg. 124 17
Software Craftsmanship: • Replaces the notion of software development as an engineering activity in favor of an older concept of a software studio with a skills progression from apprentice to journeyman to master craftsman • Developers are expected to take on multiple roles and be responsible for a complete job from start to finish • Proficiency is built across the spectrum of the core skills of programming: programming, testing, debugging, and maintenance • Master craftsmen are journeymen who develop their mastery through learning and experience on many projects, and the nurturing of other developers Software Craftsmanship 18 http://manifesto.softwarecraftsmanship.org/
“Productivity” is not a mechanical measure of speed. • Knowledge drives productivity; Knowledge workers need to own the responsibility for their own productivity • Knowledge worker productivity is dependent on quality at least as much as quantity • Optimal quality is the path to high productivity 19 From AllPosters.com Team Productivity Management Tips:  Measure outcome, not output  Measure only a few things  Ensure commonly understood operational definition and measurement plan  Target specific questions and audiences - Courtesy Robin Dymond and Deborah Hartmann
ProgramManagement
• Encourage face-to-face dialogue across levels • Create overlapping management with “linking pins” • Run the Lean-Agile PMO as an Agile project team Source: The Lean-Agile PMO, Sanjiv Augustine and Roland Cuellar (Cutter Consortium 2006) 21 Organizational Structure Oscillating Between Information Discovery and Integration A centralized structure works well for discovery, because the individual’s role is to find information and report it back. In contrast, a richly connected network works best for integration and decision making, because it allows the individual to hear everyone else’s opinion about the expected return from each of the alternatives. - Alex Pentland, How Social Networks Network Best, Harvard Business Review, February 2009
Portfolio Alignment Wall 22
• Terminate sick projects • Split large projects in smaller ones • Prioritize projects by business value, at least within business unit • Limit development timeframe to months • Re-prioritize projects regularly 1 Development 3 24 Little’s Law WIP Completion Rate Portfolio Realignment 23 Business Goals & Strategy Production Sunset Cycle Time = Backlog
• Multiple, stable teams each focused on a single project at a time • Dedicated to platforms or lines of business • Platform owner prioritizes next project • Result: o Support multiple lines of business simultaneously o Focused effort results in quick delivery for individual projects o Clear accountability o Stability and predictability Source: The Lean-Agile PMO, Sanjiv Augustine and Roland Cuellar (Cutter Consortium 2006) 24 Stable Platform Teams
25 Contact Us for Further Information Sanjiv Augustine President Sanjiv.Augustine@lithespeed.com Arlen Bankston Executive Vice President Roland Cuellar VP, Enterprise Agile Consulting David Bulkin VP, Agile Coaching On the Web: http://www.lithespeed.com http://www.sanjivaugustine.com "I only wish I had read this book when I started my career in software product management, or even better yet, when I was given my first project to manage. In addition to providing an excellent handbook for managing with agile software development methodologies, Managing Agile Projects offers a guide to more effective project management in many business settings." John P. Barnes, former Vice President of Product Management at Emergis, Inc.

More Related Content

Scaling Agile - Multiple Team Dynamics

  • 1. Scaling Agile Presented by Sanjiv Augustine Sanjiv.Augustine@LitheSpeed.com April 07, 2010 Multiple Team Dynamics
  • 2. • Basic Adoption Threshold • Multiple Team Dynamics o Preparing for Multiple Team Rollout o Adoption Management o Team Management o Program Management • Q&A 2 Agenda Small is Beautiful “…for a large organization to work it must behave like a related group of small organizations.” - E. F. Schumacher, Small is Beautiful Image source: http://practicalactionconsulting.org/?id=is_small_beauti ful;
  • 4. Traditional Silos Customer BA Designer DeveloperPM Core Team (EXAMPLE) BA / Tester BA Tester Product Owner Developer Designer Developer / BA SM Release Manager Capacity Planner Prod. Architect Tech Ops Business Sponsor Risk Assessor Security Dedicated, Integrated Scrum Team 4 BAAnalysts DeveloperDeveloperDeveloper Designers Tester The Core Project Team ideally consists of 5-9 dedicated members (7 +/- 2). The Extended Team can contain many additional members, each playing an important role, but they are typically not dedicated to the effort. TesterTestersDevs
  • 5. Sprint “Ready” and “Done” Discipline What must be in place at the beginning of the Sprint for your project team to have a productive Sprint? What must be in place at the end of a Sprint to have a deployable product increment? Ready In Process Done 5
  • 6. Agile Engineering Practices allow teams to move fast, be flexible and deliver high quality software: • Automated Builds & Continuous Integration reduce time and effort associated with manual builds, and risk from big-bang integrations • Simple Design & Refactoring keep incremental development from leading to poor architectures • Multi-Level/Automated Testing & Test-Driven Development reduce testing time and effort and allow developers to make changes with confidence • Pair Programming increases software quality without impacting time to deliver. Agile Engineering Practices Agile Engineering, Pg. 124 6
  • 9. • Executive, senior and middle management must all be change agents • Business and IT must be willing to dedicate the appropriate resources o Agile teams require more dedication from assigned resources o Need an Agile Champion to lead the Agile program o Need to fund for experienced Agile process coaches o Need to fund for additional training and capability development o Need to fund for Agile team rooms • Process learning will consume some amount of project teams’ time and effort • Changes to existing processes will be necessary: in particular, resource management and portfolio management • The project manager and product manager roles will change significantly Large Scale Adoption Implications 9 Some typical implications of large scale adoption:
  • 11. Incremental Rollout Strategy Initial Pilots - Pilot Projects With Day- to-Day Oversight by Master Coach Expanded Pilots - Projects Using combination of Experienced Associates and Trained Associates with Master Coach oversight across Multiple Projects Enterprise Rollout - Autonomous agile capability using experienced and trained associates. Occasional master coach involvement on an as-needed consultative basis 11
  • 12. Your first projects need: • Product Owner involved, accountable & empowered to control scope & schedule • ScrumMaster empowered to control process • Dedicated, integrated team • Executive support for learning and exploration • Short term initial release timeline (< 3 months) • Potential for measurable business results and impact 12 Pilot Project Selection Criteria Thanks to Mike Cohn for the image: http://blog.mountaingoatsoftware.com/four-attributes-of-the-ideal-pilot-project
  • 13. Collaborative Workspace Design 13 Capital One Workspace Design, Source: http://www.degw.com/project.aspx?id=14&p=Capital+One
  • 14. 14 Create a defined and reliable process: • Standardize high-level process steps, deliverables, tools and artifacts • Agree on process audit procedures • Develop standard process metrics Process Standardization The Six Sigma Paradox To attain six sigma performance, we must minimize process variability, slack and redundancy by building variability, slack and redundancy into our organizations.
  • 16. 16 Conquer and divide by building a federation of agile teams: • Build the “whole” into the “parts” • Set a size limit ( e.g. 7 +/- 2 people) • To grow, create new integrated Agile teams when team size limit is reached • Coordinate among teams via an Agile PMO Scaling Agile Teams
  • 17. Agile Engineering Practices allow teams to move fast, be flexible and deliver high quality software: • Automated Builds & Continuous Integration reduce time and effort associated with manual builds, and risk from big-bang integrations • Simple Design & Refactoring keep incremental development from leading to poor architectures • Multi-Level/Automated Testing & Test-Driven Development reduce testing time and effort and allow developers to make changes with confidence • Pair Programming increases software quality without impacting time to deliver. Agile Engineering Practices Agile Engineering, Pg. 124 17
  • 18. Software Craftsmanship: • Replaces the notion of software development as an engineering activity in favor of an older concept of a software studio with a skills progression from apprentice to journeyman to master craftsman • Developers are expected to take on multiple roles and be responsible for a complete job from start to finish • Proficiency is built across the spectrum of the core skills of programming: programming, testing, debugging, and maintenance • Master craftsmen are journeymen who develop their mastery through learning and experience on many projects, and the nurturing of other developers Software Craftsmanship 18 http://manifesto.softwarecraftsmanship.org/
  • 19. “Productivity” is not a mechanical measure of speed. • Knowledge drives productivity; Knowledge workers need to own the responsibility for their own productivity • Knowledge worker productivity is dependent on quality at least as much as quantity • Optimal quality is the path to high productivity 19 From AllPosters.com Team Productivity Management Tips:  Measure outcome, not output  Measure only a few things  Ensure commonly understood operational definition and measurement plan  Target specific questions and audiences - Courtesy Robin Dymond and Deborah Hartmann
  • 21. • Encourage face-to-face dialogue across levels • Create overlapping management with “linking pins” • Run the Lean-Agile PMO as an Agile project team Source: The Lean-Agile PMO, Sanjiv Augustine and Roland Cuellar (Cutter Consortium 2006) 21 Organizational Structure Oscillating Between Information Discovery and Integration A centralized structure works well for discovery, because the individual’s role is to find information and report it back. In contrast, a richly connected network works best for integration and decision making, because it allows the individual to hear everyone else’s opinion about the expected return from each of the alternatives. - Alex Pentland, How Social Networks Network Best, Harvard Business Review, February 2009
  • 23. • Terminate sick projects • Split large projects in smaller ones • Prioritize projects by business value, at least within business unit • Limit development timeframe to months • Re-prioritize projects regularly 1 Development 3 24 Little’s Law WIP Completion Rate Portfolio Realignment 23 Business Goals & Strategy Production Sunset Cycle Time = Backlog
  • 24. • Multiple, stable teams each focused on a single project at a time • Dedicated to platforms or lines of business • Platform owner prioritizes next project • Result: o Support multiple lines of business simultaneously o Focused effort results in quick delivery for individual projects o Clear accountability o Stability and predictability Source: The Lean-Agile PMO, Sanjiv Augustine and Roland Cuellar (Cutter Consortium 2006) 24 Stable Platform Teams
  • 25. 25 Contact Us for Further Information Sanjiv Augustine President Sanjiv.Augustine@lithespeed.com Arlen Bankston Executive Vice President Roland Cuellar VP, Enterprise Agile Consulting David Bulkin VP, Agile Coaching On the Web: http://www.lithespeed.com http://www.sanjivaugustine.com "I only wish I had read this book when I started my career in software product management, or even better yet, when I was given my first project to manage. In addition to providing an excellent handbook for managing with agile software development methodologies, Managing Agile Projects offers a guide to more effective project management in many business settings." John P. Barnes, former Vice President of Product Management at Emergis, Inc.