Successfully reported this slideshow.
Exploring Enterprise Agile Transformation Strategies<br />Mike Cottmeyer, Agile Coach<br />LeadingAgile, LLC<br />Dennis S...
Mike CottmeyerLeadingAgilemike@leadingagile.com	1.404.312.1471www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadi...
Dennis StevensSynaptusdennis.stevens@synaptus.com770.851.8025www.synaptus.comtwitter.com/dennisstevens<br />
Agenda<br />
Agenda<br />The difference between Agile Adoption and Agile Transformation<br />
Agenda<br />The difference between Agile Adoption and Agile Transformation<br />The real goal of Agile change initiatives<...
Agenda<br />The difference between Agile Adoption and Agile Transformation<br />The real goal of Agile change initiatives<...
Agenda<br />The difference between Agile Adoption and Agile Transformation<br />The real goal of Agile change initiatives<...
Agenda<br />The difference between Agile Adoption and Agile Transformation<br />The real goal of Agile change initiatives<...
Agenda<br />The difference between Agile Adoption and Agile Transformation<br />The real goal of Agile change initiatives<...
Agile Adoption vs. Agile Transformation<br />
Adoption vs. Transformation<br />Agile Adoption is more about what you do… practices, tools, techniques, and habits<br />A...
Adoption/Transformation Cycle<br />Introducing Agile is Iterative and Incremental<br /><ul><li>Changing some of the physic...
Teaching people new ways of working together
Helping people internalize how and why agile really works… living the value system</li></li></ul><li>Adoption/Transformati...
Make incremental changes to the structure of the organization, build Agile teams
Establish policies and working agreements</li></li></ul><li>Adoption/Transformation Cycle<br />Adopt Practices<br /><ul><l...
Identify a ScrumMaster and Product Owner
Start doing TDD and Continuous Integration
Story Mapping and Agile Requirements decomposition</li></li></ul><li>Adoption/Transformation Cycle<br />Personal Transform...
Help people to work together toward common goals
Demonstrate greater understanding and empathy amongst individuals
Teamwork</li></li></ul><li>You have to address all three aspects to achieve sustainable organizational change…<br />
Common Anti-Patterns<br />Establishing teams without breaking down the strict functional silos and rigid role definitions<...
Common Anti-Patterns<br />Establishing teams without breaking down the strict functional silos and rigid role definitions<...
Common Anti-Patterns<br />Establishing teams without breaking down the strict functional silos and rigid role definitions<...
Common Anti-Patterns<br />Establishing teams without breaking down the strict functional silos and rigid role definitions<...
The problem with Agile Transformation is that the goal is never to adopt agile…<br />
…Scrum and XP provide specific frameworks to help us deliver better software…<br />
…The goal is to improve business outcomes!<br />
Value Delivery<br />Delivery Goals<br /><ul><li>Faster Time to Market… frequent, smaller releases
High quality products… low number of escaped defects
Efficient delivery… minimize waste
Predictability… deliver what we say we are going to deliver
Happy Customers</li></ul>Product Definition<br />Planning & Coordination<br />Continuous Improvement<br />Delivery Practic...
Value Delivery<br />Product Definition<br /><ul><li>Extremely clear product vision
Well articulated product roadmap
Decompose product themes into fine grained product features
Define detailed acceptance criteria and make trade-offs
Accurately estimate effort and duration</li></ul>Product Definition<br />Planning & Coordination<br />Continuous Improveme...
Value Delivery<br />Planning & Coordination<br /><ul><li>Establish a regular planning cadence
Break down features into tasks and define acceptance tests
Establish a cadence of delivering working tested features
Limit the amount of work in process
Regularly make and meet commitments
Continually adapt the plan</li></ul>Product Definition<br />Planning & Coordination<br />Continuous Improvement<br />Deliv...
Value Delivery<br />Delivery Practices<br /><ul><li>Emergent Architecture and Design
Rapid delivery of small features into the product
Continuous testing of the product
Clean code and fixing defects as we go
Deploy the solution either internally or externally on demand</li></ul>Product Definition<br />Planning & Coordination<br ...
Value Delivery<br />Continuous Improvement<br /><ul><li>Metrics and Reporting
Teams that have a stable velocity
Retrospectives at all levels of the organization
Manage stakeholder expectations
Enable process improvement
Lead and manage change</li></ul>Product Definition<br />Planning & Coordination<br />Continuous Improvement<br />Delivery ...
Organizational Enablement<br /><ul><li>Team based delivery
Regular checkpoints to make sure everyone is on the same page
People work together to solve problems
People are empowered to make decisions
High levels of trust between coworkers</li></ul>Value Delivery<br />Product Definition<br />Planning & Coordination<br />C...
Focus less on implementing specific agile practices…<br />
…and more on developing situationally specific strategies to solve business problems.<br />
Competency Models… and our Competency Model<br />
Product Definition<br />Establish the Product Vision<br />The ability to determine and clearly communicate the product’s p...
Planning & Coordination<br />Establish a Planning Cadence <br />Is there a release train in place?  Is there a regular rel...
Delivery Practices<br />Define the Solution <br />Does the team have the capability to allow architectures and designs to ...
Continuous Improvement <br />Metrics and Reporting<br />Does the organization have a package of agile metrics that support...
Organizational Enablement<br />Team Based Delivery <br />Is the organization formed around agile teams?  Do the teams have...
Applying the Competency Model at Different Frequencies<br />
Strategic<br />Release<br />Iteration<br />Daily<br />Continuous<br />Continuous<br />
Strategic<br />Release<br />Iteration<br />Daily<br />Continuous<br />Daily<br />
Strategic<br />Release<br />Iteration<br />Daily<br />Continuous<br />Iteration<br />
Strategic<br />Release<br />Iteration<br />Daily<br />Continuous<br />Release<br />
Strategic<br />Release<br />Iteration<br />Daily<br />Continuous<br />Strategic<br />
Applying the Competency Model at Different Levels of Scale<br />
Team<br />
Multi-Team<br />
Multi-Team<br />
Multi-Team<br />
Program Management<br />
Portfolio Management<br />
Enterprise Agility<br />
How do the three dimensions Fit Together?<br />
Frequency<br />Competencies<br />Scale<br />
Create Situationally Specific Strategies for Each Competency, Frequency & Scale Combination<br />
125 Possible Combinations	<br />Competency: Continuous Integration<br />Frequency: Daily Build<br />Scale: Across Multiple...
125 Possible Combinations	<br />Competency: Continuous Integration<br />Frequency: Daily<br />Scale: Across Multiple Teams...
125 Possible Combinations	<br />Competency: Define the Product<br />Frequency: Iteration Planning<br />Scale: Single Team<...
125 Possible Combinations	<br />Competency: Define the Product<br />Frequency: Iteration Planning<br />Scale: Single Team<...
125 Possible Combinations	<br />Competency: Explore Improvement Options<br />Frequency: Iteration Planning<br />Scale: Sin...
125 Possible Combinations	<br />Competency: Explore Improvement Options<br />Frequency: Daily Planning<br />Scale: Single ...
Assessing the Organization and Getting Better Over Time<br />
Assessment Results – at Start<br />63<br />
Assessment Results – at Month One<br />64<br />
Assessment Results – at Month Two<br />65<br />
Leading Change by Incrementing and Iterating Through the Organization<br />
Incremental and Iterative Delivery<br />Incremental<br />Various parts of the system are developed at different times or r...
Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br /...
Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br /...
Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br /...
Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br /...
Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br /...
Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br /...
Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br /...
Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br /...
Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br /...
Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br /...
Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br /...
Case Study #1 – Large Federal Lending Institution<br />
Case Study: Situation <br />Financial services firm<br />350 employees-70 in IT Software Development<br />Support customer...
Case Study: Assessment<br />Planning and coordination<br />Low transparency<br />Significant WIP and individual multi-task...
Case Study: Plan<br />Organizational Design Patterns<br />5 stable delivery teams w/ a support team<br />Convert Configura...
January: Pilot a delivery team<br /><ul><li>Established Team and Co-located everyone
Got an exception from the existing governance process
Conducted Agile Team Training and TDD Training
Co-located with the team and coached them daily (planned 3 sprints)</li></li></ul><li>January: Expand to Multiple Teams<br...
Conducted training for all developers
Prepared all the remaining backlogs
Pushed production support through the support team</li></li></ul><li>January: Expand to Multiple TeamsDelivery Leadership<...
Focus on establishing new policies and working agreements
Protect team capacity
Established and aligned Communities of Excellence</li></li></ul><li>January: Expand to Multiple TeamsDev Ops<br />Support<...
Addressed internal policy constraints on automation
Moved to automation to rapidly provision environments
Coached the DevOps Team and Production Support</li></li></ul><li>March: Begin Competency Improvement Team<br /><ul><li>Jum...
Support cross functional and cross organizational change
Run transformation as an enterprise project
Updating control objectives - coaching audit and compliance
Change management is critical</li></ul>Dev Ops<br />Support<br />Delivery Leadership Team<br />Delivery Teams<br />Plan<br...
April: Align with Strategy<br />Evaluate<br />Verify<br />Explore<br />Deliver<br />Portfolio Management<br />Portfolio Le...
Balance demand against capacity</li></ul>Dev Ops<br />Support<br />Delivery Leadership<br />Delivery Teams<br />Plan<br />...
April: Align with Strategy<br />Evaluate<br />Verify<br />Explore<br />Deliver<br />Program level<br /><ul><li>CRM / PO ro...
Lessons Learned<br />Get started on the automation earlier<br />Change management must be intentional – managing resistanc...
Cast Study #2 – Network Security Appliance Company<br />
Company Profile<br />Based in the United States<br />125 employees located across 4 major cities in the US and Canada<br /...
Problem Statement<br />Functional separation between Development and QA<br />Ad-hoc waterfall based processes not able to ...
Engagement Approach<br />Conducted a competency assessment on the entire organization<br />Collaborated on a top-down plan...
Engagement Approach – Phase I<br />Team Level and Multi-Team Adoption<br />Focused on Product Definition, Planning & Coord...
Engagement Approach – Phase 2<br />Skipped the Program Management layer and went straight to Portfolio & Strategy<br />Foc...
Engagement Approach – Phase 3<br />Filled in the Portfolio Level<br />Still focusing on Product Definition, Planning & Coo...
Team<br />
Multi-Team<br />
Upcoming SlideShare
Loading in …5
×

Exploring Agile Transformation and Scaling Patterns

6,240 views

Published on

The goal of any enterprise agile adoption strategy is NOT to adopt agile. Companies adopt agile to achieve better business outcomes. Large organizations have no time for dogma and one-size-fits-all thinking when it comes to introducing agile practices. These companies need pragmatic guidance for safely and incrementally introducing structure, principles, and ultimately practices that will result in greater long term, sustainable business results. This talk will introduce a framework for safely, pragmatically, and incrementally introducing agile to help you achieve your business goals.

Published in: Business, Technology

Exploring Agile Transformation and Scaling Patterns

  1. 1. Exploring Enterprise Agile Transformation Strategies<br />Mike Cottmeyer, Agile Coach<br />LeadingAgile, LLC<br />Dennis Stevens, Agile Coach<br />Synaptus<br />
  2. 2. Mike CottmeyerLeadingAgilemike@leadingagile.com 1.404.312.1471www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadingagilelinkedin.com/in/cottmeyer<br />
  3. 3. Dennis StevensSynaptusdennis.stevens@synaptus.com770.851.8025www.synaptus.comtwitter.com/dennisstevens<br />
  4. 4. Agenda<br />
  5. 5. Agenda<br />The difference between Agile Adoption and Agile Transformation<br />
  6. 6. Agenda<br />The difference between Agile Adoption and Agile Transformation<br />The real goal of Agile change initiatives<br />
  7. 7. Agenda<br />The difference between Agile Adoption and Agile Transformation<br />The real goal of Agile change initiatives<br />Competency models, our competency model, and how to choose practices specific practices against the model<br />
  8. 8. Agenda<br />The difference between Agile Adoption and Agile Transformation<br />The real goal of Agile change initiatives<br />Competency models, our competency model, and how to choose practices specific practices against the model<br />Adapting practices for different frequency intervals in your organization<br />
  9. 9. Agenda<br />The difference between Agile Adoption and Agile Transformation<br />The real goal of Agile change initiatives<br />Competency models, our competency model, and how to choose practices specific practices against the model<br />Adapting practices for different frequency intervals in your organization<br />Adapting practices for different levels of scale within your organization<br />
  10. 10. Agenda<br />The difference between Agile Adoption and Agile Transformation<br />The real goal of Agile change initiatives<br />Competency models, our competency model, and how to choose practices specific practices against the model<br />Adapting practices for different frequency intervals in your organization<br />Adapting practices for different levels of scale within your organization<br />Case studies (4 in total)<br />
  11. 11. Agile Adoption vs. Agile Transformation<br />
  12. 12. Adoption vs. Transformation<br />Agile Adoption is more about what you do… practices, tools, techniques, and habits<br />Agile Transformation is more about who you are… reflected in both the structure of the organization and who you are as people<br />
  13. 13. Adoption/Transformation Cycle<br />Introducing Agile is Iterative and Incremental<br /><ul><li>Changing some of the physical structures in our organization
  14. 14. Teaching people new ways of working together
  15. 15. Helping people internalize how and why agile really works… living the value system</li></li></ul><li>Adoption/Transformation Cycle<br />Organizational<br />Transformation<br /><ul><li>Establish a top-down organizational design pattern and roadmap
  16. 16. Make incremental changes to the structure of the organization, build Agile teams
  17. 17. Establish policies and working agreements</li></li></ul><li>Adoption/Transformation Cycle<br />Adopt Practices<br /><ul><li>Instantiate sprint planning, daily standups, reviews & retrospectives
  18. 18. Identify a ScrumMaster and Product Owner
  19. 19. Start doing TDD and Continuous Integration
  20. 20. Story Mapping and Agile Requirements decomposition</li></li></ul><li>Adoption/Transformation Cycle<br />Personal Transformation<br /><ul><li>Develop a greater ability to deal with ambiguity and inspect and adapt
  21. 21. Help people to work together toward common goals
  22. 22. Demonstrate greater understanding and empathy amongst individuals
  23. 23. Teamwork</li></li></ul><li>You have to address all three aspects to achieve sustainable organizational change…<br />
  24. 24. Common Anti-Patterns<br />Establishing teams without breaking down the strict functional silos and rigid role definitions<br />Running daily standup meetings that devolve into status updates for the project manager<br />Coming back from CSM training only to find that there is no way to form agile teams and no interest in adopting agile practices<br />
  25. 25. Common Anti-Patterns<br />Establishing teams without breaking down the strict functional silos and rigid role definitions<br />Running daily standup meetings that devolve into status updates for the project manager<br />Coming back from CSM training only to find that there is no way to form agile teams and no interest in adopting agile practices<br />
  26. 26. Common Anti-Patterns<br />Establishing teams without breaking down the strict functional silos and rigid role definitions<br />Running daily standup meetings that devolve into status updates for the project manager<br />Coming back from CSM training only to find that there is no way to form agile teams and no interest in adopting agile practices<br />
  27. 27. Common Anti-Patterns<br />Establishing teams without breaking down the strict functional silos and rigid role definitions<br />Running daily standup meetings that devolve into status updates for the project manager<br />Coming back from CSM training only to find that there is no way to form agile teams and no interest in adopting agile practices<br />
  28. 28. The problem with Agile Transformation is that the goal is never to adopt agile…<br />
  29. 29. …Scrum and XP provide specific frameworks to help us deliver better software…<br />
  30. 30. …The goal is to improve business outcomes!<br />
  31. 31. Value Delivery<br />Delivery Goals<br /><ul><li>Faster Time to Market… frequent, smaller releases
  32. 32. High quality products… low number of escaped defects
  33. 33. Efficient delivery… minimize waste
  34. 34. Predictability… deliver what we say we are going to deliver
  35. 35. Happy Customers</li></ul>Product Definition<br />Planning & Coordination<br />Continuous Improvement<br />Delivery Practices<br />Organizational Enablement<br />25<br />
  36. 36. Value Delivery<br />Product Definition<br /><ul><li>Extremely clear product vision
  37. 37. Well articulated product roadmap
  38. 38. Decompose product themes into fine grained product features
  39. 39. Define detailed acceptance criteria and make trade-offs
  40. 40. Accurately estimate effort and duration</li></ul>Product Definition<br />Planning & Coordination<br />Continuous Improvement<br />Delivery Practices<br />Organizational Enablement<br />26<br />
  41. 41. Value Delivery<br />Planning & Coordination<br /><ul><li>Establish a regular planning cadence
  42. 42. Break down features into tasks and define acceptance tests
  43. 43. Establish a cadence of delivering working tested features
  44. 44. Limit the amount of work in process
  45. 45. Regularly make and meet commitments
  46. 46. Continually adapt the plan</li></ul>Product Definition<br />Planning & Coordination<br />Continuous Improvement<br />Delivery Practices<br />Organizational Enablement<br />27<br />
  47. 47. Value Delivery<br />Delivery Practices<br /><ul><li>Emergent Architecture and Design
  48. 48. Rapid delivery of small features into the product
  49. 49. Continuous testing of the product
  50. 50. Clean code and fixing defects as we go
  51. 51. Deploy the solution either internally or externally on demand</li></ul>Product Definition<br />Planning & Coordination<br />Continuous Improvement<br />Delivery Practices<br />Organizational Enablement<br />28<br />
  52. 52. Value Delivery<br />Continuous Improvement<br /><ul><li>Metrics and Reporting
  53. 53. Teams that have a stable velocity
  54. 54. Retrospectives at all levels of the organization
  55. 55. Manage stakeholder expectations
  56. 56. Enable process improvement
  57. 57. Lead and manage change</li></ul>Product Definition<br />Planning & Coordination<br />Continuous Improvement<br />Delivery Practices<br />Organizational Enablement<br />29<br />
  58. 58. Organizational Enablement<br /><ul><li>Team based delivery
  59. 59. Regular checkpoints to make sure everyone is on the same page
  60. 60. People work together to solve problems
  61. 61. People are empowered to make decisions
  62. 62. High levels of trust between coworkers</li></ul>Value Delivery<br />Product Definition<br />Planning & Coordination<br />Continuous Improvement<br />Delivery Practices<br />Organizational Enablement<br />30<br />
  63. 63. Focus less on implementing specific agile practices…<br />
  64. 64. …and more on developing situationally specific strategies to solve business problems.<br />
  65. 65. Competency Models… and our Competency Model<br />
  66. 66. Product Definition<br />Establish the Product Vision<br />The ability to determine and clearly communicate the product’s primary customer base, it’s competitive differentiators, and competitive alternatives. At the release level, it’s the ability to determine why we are building this product, whom it is for, and why the release is important. <br />Define the Product Roadmap<br />The product roadmap is the strategic plan for how the Product Vision will be executed. In an agile organization, this roadmap should be at the Epic level and show when various Epics need to be in market. The Product Roadmap should be supported with either Epic size or budget, and be validated against proven capacity to deliver. Epics are generally 1-3 months in size. <br />Decompose Features<br />The ability to decompose features means to break Epics into high-level feature functions that can be communicated and/or committed to customers. Features follow the same format as user stories, but are at a higher level of abstraction, much like use cases, or use case scenarios. Features are generally take 2-4 weeks to deliver<br />Estimate Size and Effort<br />Does the organization have the ability to accurately estimate the size and effort of a given Epic, Feature, or User Story? Are these estimates generated using team based, collaborative techniques? Are these estimates validated with empirical evidence gathered from actual delivery of working software?<br />Define Acceptance Criteria<br />Does the team have clear guidance on what is the definition of done? Do they know what it will take to meet the business requirements defined by the product owner? <br />34<br />
  67. 67. Planning & Coordination<br />Establish a Planning Cadence <br />Is there a release train in place? Is there a regular release-planning cadence? Do the teams meet regularly with their Product Owner to plan sprints? Does the organization do strategic planning and roadmap planning? <br />Perform Activity Breakdown<br />Do the teams break user stories into sufficiently small increments that they can be incrementally delivered and tracked through the sprint? If not, do the teams break larger user stories down into tasks and tests that can be tackled by more than one team member at a time <br />Establish Delivery Cadence<br />Does the team have a pattern of delivering working, tested software every sprint? Do multi-team projects show a pattern of coming together to deliver an integrated increment of software on a regular, periodic basis? Does the organization show a pattern of early delivery of whole Epics in a release cycle?<br />Limit Work in Process<br />Does the organization, release architecture, or team have the ability to limit the number of Epics, Features, or User Stories they are working on concurrently? Does the organization value completing work rather than getting new work started? Are teams allowed to focus on one thing until delivery, or are they constantly pulled onto other, higher priority initiatives. Do priorities change often? <br />Make and Meet Commitments<br />Does the organization, release, or team regularly do what it says it will do? Do they have the ability to make and meet commitments on short time-boxed intervals? <br />35<br />
  68. 68. Delivery Practices<br />Define the Solution <br />Does the team have the capability to allow architectures and designs to change as we learn more about the emerging product? Do the team use agile modeling techniques? Is there a desire to plan everything before we start building any working product? Does the team use a value and risk driven approach to working out the systems architecture and design. <br />Build the Solution<br />Do the developers have the tools necessary to build an increment of working software? Can software be checked in and validated on a continuous basis. Are the teams doing unit testing? Are the tests run in a test harness at check in? Are the developers confident working in the code base? Is the code safe to change? <br />Test the Solution<br />Is there a mechanism in place to incrementally test and validate the software as it is being built? Is all software tested before it is accepted? Is all software tested before it is put into production? Are the number of ‘hardening sprints’ equal to or greater than the number of sprints it took to build the product? Are the teams using continuous integration and TDD? <br />Technical Debt and Defects<br />Are defects routinely carried over from sprint to sprint and handled toward the end of the release? Do teams have difficulty estimating work due to unexpected defects and code that is difficult to understand and maintain? <br />Deploy the Solution<br />Is there an ability to incrementally deliver the solution, either to an internal customer for review, or to an external customer that will actually use the product?<br />36<br />
  69. 69. Continuous Improvement <br />Metrics and Reporting<br />Does the organization have a package of agile metrics that support team level up to executive level decision-making? Are there processes in place for gathering these metrics and reporting them to the appropriate stakeholders? <br />Establish Stable Velocity<br />Can the organization, at the enterprise, release, or team levels; reliably and predictably deliver a known quantity of working software at every iteration or release boundary? <br />Conduct Retrospectives<br />Does the organization regularly conduct reviews and retrospectives at the end of every iteration or release boundary? Is there a mechanism for acting on lessons learned and new opportunities discovered in these sessions? <br />Update the Release Backlog<br />Is there a mechanism in place for quickly updating the release backlog when new information is learned about the emerging product or when business priorities change? <br />Enable Process Improvement<br />Is there a mechanism in place for quickly updating organizational processes in the face of impediments that might impact product delivery? <br />37<br />
  70. 70. Organizational Enablement<br />Team Based Delivery <br />Is the organization formed around agile teams? Do the teams have everything they need to successfully deliver an increment of working tested software? Are members constantly pulled away from teams and assigned to other initiatives. Is there team level accountability for sprint outcomes? Is there team level accountability for release level outcomes? <br />Communication<br />How well do people talk to each other and communicate the right level of information? Do teams openly an honestly share information that could help the organization be more successful? <br />Collaboration<br />Do cross-functional teams regularly work together to define requirements, architectures, designs, test plans, etc.? Do team members often work in silos with limited communication amongst team members? <br />Empowerment<br />Are people and teams authorized to make decisions within their established constraints or within pre-defined guidelines? Are decisions routinely overturned? Are the right stakeholders present when decisions are made? <br />Trust<br />Is there open and honest communication between team members? Is it safe to share bad news? Does management ‘shoot the messenger’ when bad news in delivered? Do people feel they can openly and honestly give negative feedback? <br />38<br />
  71. 71. Applying the Competency Model at Different Frequencies<br />
  72. 72. Strategic<br />Release<br />Iteration<br />Daily<br />Continuous<br />Continuous<br />
  73. 73. Strategic<br />Release<br />Iteration<br />Daily<br />Continuous<br />Daily<br />
  74. 74. Strategic<br />Release<br />Iteration<br />Daily<br />Continuous<br />Iteration<br />
  75. 75. Strategic<br />Release<br />Iteration<br />Daily<br />Continuous<br />Release<br />
  76. 76. Strategic<br />Release<br />Iteration<br />Daily<br />Continuous<br />Strategic<br />
  77. 77. Applying the Competency Model at Different Levels of Scale<br />
  78. 78. Team<br />
  79. 79. Multi-Team<br />
  80. 80. Multi-Team<br />
  81. 81. Multi-Team<br />
  82. 82. Program Management<br />
  83. 83. Portfolio Management<br />
  84. 84. Enterprise Agility<br />
  85. 85. How do the three dimensions Fit Together?<br />
  86. 86. Frequency<br />Competencies<br />Scale<br />
  87. 87. Create Situationally Specific Strategies for Each Competency, Frequency & Scale Combination<br />
  88. 88. 125 Possible Combinations <br />Competency: Continuous Integration<br />Frequency: Daily Build<br />Scale: Across Multiple Teams<br />
  89. 89. 125 Possible Combinations <br />Competency: Continuous Integration<br />Frequency: Daily<br />Scale: Across Multiple Teams<br />Competency: Continuous Integration<br />Frequency: Release<br />Scale: At the Portfolio Level<br />
  90. 90. 125 Possible Combinations <br />Competency: Define the Product<br />Frequency: Iteration Planning<br />Scale: Single Team<br />
  91. 91. 125 Possible Combinations <br />Competency: Define the Product<br />Frequency: Iteration Planning<br />Scale: Single Team<br />Competency: Define the Product<br />Frequency: Strategic Planning<br />Scale: Entire Enterprise<br />
  92. 92. 125 Possible Combinations <br />Competency: Explore Improvement Options<br />Frequency: Iteration Planning<br />Scale: Single Team<br />
  93. 93. 125 Possible Combinations <br />Competency: Explore Improvement Options<br />Frequency: Daily Planning<br />Scale: Single Team<br />Competency: Explore Improvement Options<br />Frequency: Release Planning<br />Scale: Portfolio Management<br />
  94. 94. Assessing the Organization and Getting Better Over Time<br />
  95. 95. Assessment Results – at Start<br />63<br />
  96. 96. Assessment Results – at Month One<br />64<br />
  97. 97. Assessment Results – at Month Two<br />65<br />
  98. 98. Leading Change by Incrementing and Iterating Through the Organization<br />
  99. 99. Incremental and Iterative Delivery<br />Incremental<br />Various parts of the system are developed at different times or rates, and integrated as they are completed. You can do this in a waterfall project or an iterative project.<br />Iterative<br />Go back over parts of the system to revise and improve the system. In iterative development testing and/or user feedback is used to revise the targets of the successive deliverables. The practice of iterations arises from a desire to coordinate feedback from increments to revise a future deliverable.<br />Courtesy of Jeff Patton<br />
  100. 100. Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Phase I<br />Cultural Factors<br />Organizational Enablement<br />68<br />
  101. 101. Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Phase I<br />Product Definition<br />Continuous Improvement<br />Planning Coordination<br />Delivery Practices<br />Organizational Enablement<br />69<br />
  102. 102. Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Phase I<br />Product Definition<br />Continuous Improvement<br />Planning Coordination<br />Delivery Practices<br />Organizational Enablement<br />70<br />
  103. 103. Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Phase I<br />Product Definition<br />Continuous Improvement<br />Planning Coordination<br />Delivery Practices<br />Organizational Enablement<br />71<br />
  104. 104. Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Phase II<br />Product Definition<br />Continuous Improvement<br />Planning Coordination<br />Delivery Practices<br />Organizational Enablement<br />72<br />
  105. 105. Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Product Definition<br />Phase II<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Organizational Enablement<br />73<br />
  106. 106. Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Product Definition<br />Phase II<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Organizational Enablement<br />74<br />
  107. 107. Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Continuous Improvement<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Product Definition<br />Planning Coordination<br />Delivery Practices<br />Phase III<br />Organizational Enablement<br />75<br />
  108. 108. Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Phase III<br />Organizational Enablement<br />76<br />
  109. 109. Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Phase III<br />Organizational Enablement<br />77<br />
  110. 110. Value Delivery<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Product Definition<br />Planning Coordination<br />Continuous Improvement<br />Delivery Practices<br />Sustainability<br />Organizational Enablement<br />78<br />
  111. 111. Case Study #1 – Large Federal Lending Institution<br />
  112. 112. Case Study: Situation <br />Financial services firm<br />350 employees-70 in IT Software Development<br />Support customer facing, internal systems and integrations to third-party applications<br />Track record of late unpredictable delivery and high demand for production support – recent two year project took four years to partially complete<br />
  113. 113. Case Study: Assessment<br />Planning and coordination<br />Low transparency<br />Significant WIP and individual multi-tasking<br />Granular detail required up-front<br />Organizational Enablement<br />Low trust and collaboration<br />Delivery Practices<br />Significant rework<br />
  114. 114. Case Study: Plan<br />Organizational Design Patterns<br />5 stable delivery teams w/ a support team<br />Convert Configuration Management to DevOps<br />Establish consolidated Value Management<br />Convert PMO from day to day tasking to operate at the audit and governance level<br />Road-map<br />January: Stand up a delivery team<br />January: Stand up a DevOpsteam<br />February: Stand up the product support team<br />March: Stand up remaining teams<br />March: Migrate CRM-BA model to consolidated Value Management<br />May: Integrate with the PMO<br />
  115. 115. January: Pilot a delivery team<br /><ul><li>Established Team and Co-located everyone
  116. 116. Got an exception from the existing governance process
  117. 117. Conducted Agile Team Training and TDD Training
  118. 118. Co-located with the team and coached them daily (planned 3 sprints)</li></li></ul><li>January: Expand to Multiple Teams<br />Support<br />Delivery Teams<br /><ul><li>Stood up all the teams from the original design
  119. 119. Conducted training for all developers
  120. 120. Prepared all the remaining backlogs
  121. 121. Pushed production support through the support team</li></li></ul><li>January: Expand to Multiple TeamsDelivery Leadership<br />Support<br />Delivery Leadership Team<br />Delivery Teams<br /><ul><li>Established internal mentoring and coaching
  122. 122. Focus on establishing new policies and working agreements
  123. 123. Protect team capacity
  124. 124. Established and aligned Communities of Excellence</li></li></ul><li>January: Expand to Multiple TeamsDev Ops<br />Support<br />Dev Ops<br />Delivery Leadership Team<br />Delivery Teams<br />Rapid environment management<br /><ul><li>Stood up DevOps / CM Team
  125. 125. Addressed internal policy constraints on automation
  126. 126. Moved to automation to rapidly provision environments
  127. 127. Coached the DevOps Team and Production Support</li></li></ul><li>March: Begin Competency Improvement Team<br /><ul><li>Jumped to the Enterprise level – Engaging the enterprise and driving efforts from the strategic plan
  128. 128. Support cross functional and cross organizational change
  129. 129. Run transformation as an enterprise project
  130. 130. Updating control objectives - coaching audit and compliance
  131. 131. Change management is critical</li></ul>Dev Ops<br />Support<br />Delivery Leadership Team<br />Delivery Teams<br />Plan<br />Implement<br />Follow up<br />Backlog<br />Prepare<br />Competency Improvement Team<br />
  132. 132. April: Align with Strategy<br />Evaluate<br />Verify<br />Explore<br />Deliver<br />Portfolio Management<br />Portfolio Level<br /><ul><li>Updated steering committee approach and governance model
  133. 133. Balance demand against capacity</li></ul>Dev Ops<br />Support<br />Delivery Leadership<br />Delivery Teams<br />Plan<br />Implement<br />Follow up<br />Backlog<br />Prepare<br />Capability Improvement<br />
  134. 134. April: Align with Strategy<br />Evaluate<br />Verify<br />Explore<br />Deliver<br />Program level<br /><ul><li>CRM / PO role transitions to the PMO</li></ul>Portfolio Management<br />Produce<br />Make Ready<br />Initiate<br />UAT<br />Value Management<br />Dev Ops<br />Support<br />Delivery Leadership<br />Delivery Teams<br />Plan<br />Implement<br />Follow up<br />Backlog<br />Prepare<br />Capability Improvement<br />
  135. 135. Lessons Learned<br />Get started on the automation earlier<br />Change management must be intentional – managing resistance and organizational inertia<br />Gained momentum when we involved the overall organization in the transformation – business management drove the value proposition<br />
  136. 136. Cast Study #2 – Network Security Appliance Company<br />
  137. 137. Company Profile<br />Based in the United States<br />125 employees located across 4 major cities in the US and Canada<br />Growing through acquisition<br />
  138. 138. Problem Statement<br />Functional separation between Development and QA<br />Ad-hoc waterfall based processes not able to scale<br />Too many projects in queue <br />Teams are not predictable<br />Have not been able to realize their most strategic goal to integrate all the products into a single suite<br />
  139. 139. Engagement Approach<br />Conducted a competency assessment on the entire organization<br />Collaborated on a top-down plan led by the VP of Engineering with full support from the CTO and CEO<br />Started with the products in Atlanta and systematically moved through other geographies<br />
  140. 140. Engagement Approach – Phase I<br />Team Level and Multi-Team Adoption<br />Focused on Product Definition, Planning & Coordination, and Organizational Enablement Competencies first<br />Mostly at the Daily, Iteration, and Release levels<br />
  141. 141. Engagement Approach – Phase 2<br />Skipped the Program Management layer and went straight to Portfolio & Strategy<br />Focusing on Product Definition, Planning & Coordination, and Organizational Enablement Competencies<br />Began addressing Delivery Practices and Continuous Improvement <br />Mostly at the Daily, Iteration, and Release levels<br />Trained Marketing, Sales, and Senior Leadership<br />
  142. 142. Engagement Approach – Phase 3<br />Filled in the Portfolio Level<br />Still focusing on Product Definition, Planning & Coordination, and Organizational Enablement Competencies<br />Began addressing Delivery Practices and Continuous Improvement <br />Started addressing some of the strategic planning issues <br />
  143. 143. Team<br />
  144. 144. Multi-Team<br />
  145. 145. Multi-Team<br />
  146. 146. Multi-Team<br />
  147. 147. Portfolio Management<br />
  148. 148. Enterprise Agility<br />
  149. 149. Program Management<br />
  150. 150. Story Backlog<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />Tier 1 - Scrum<br />
  151. 151. Construction<br />Transition<br />Elaboration<br />Inception<br />Tier 3 - Kanban<br />Story Backlog<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />Tier 1 - Scrum<br />
  152. 152. Construction<br />Transition<br />Elaboration<br />Inception<br />Tier 3 - Kanban<br />Deploy<br />Build <br />Test <br />Design<br />Analysis<br />Tier 2 - Kanban<br />Story Backlog<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />Tier 1 - Scrum<br />
  153. 153. Lessons Learned<br />Having buy-in and support up to the CEO makes things a lot easier<br />The sequence of events is not always intuitive<br />Sometimes it is better to rough in something and come back to it later than try to get it perfect the first time<br />Speed can be limited by individual resistance and the rate of organizational learning<br />
  154. 154. Case Study #3 – Financial Service Company<br />
  155. 155. Case Study: Situation <br />Financial Software Services Provider<br />19,000 employees-1,000 in target division<br />Provider of technology solutions to the financial world<br />Very successful but long release cycles and low release predictability impact future strategy<br />
  156. 156. Case Study: Assessment<br />Product Definition<br />Challenges decomposing road-map into clearly defined features and stories<br />Acceptance criteria evolve after development<br />Delivery Practices<br />Quality was not a foundational practice<br />Code was developed in large chunks with long feedback cycles<br />Planning and coordination<br />Predictability is difficult due to support demand on teams<br />Challenges making and keeping commitments<br />Too much WIP – the entire release is active simultaneously<br />Organizational Enablement<br />Development teams formed around technology layers and QA and Development are not aligned in the same sprints<br />Supporting team members (architects, analysts) can be spread across multiple features and services<br />
  157. 157. Case Study: Plan<br />Organizational Design Patterns<br />Align Delivery Teams with the Product Architecture<br />Align QA, BA, and Architect with the Delivery Teams <br />Establish clear PO for each feature in Value Management and clarify feature elaboration<br />Limit WIP and make work flow through the organization<br />Road-map<br />Get cross technology development teams created and working from a single backlog<br />Establish Competency Improvement Team<br />Get BA and QA aligned with Development teams (dedicated to a team and in the same cadence)<br />Get clarity around the PO’s role and establish effective elaboration<br />Align the product road-map with the business strategy<br />
  158. 158. Structure development to match the product architecture<br /><ul><li>Align all teams with product architecture
  159. 159. Conduct training for all developers
  160. 160. Prepare the backlogs and get teams to flow</li></ul>Delivery Teams<br />
  161. 161. Competency Improvement Team<br /><ul><li>Establish a broad coalition around the transformation.
  162. 162. Identified the next most important area and enlisted change management support for the transformation </li></ul>Delivery Teams<br />Plan<br />Implement<br />Follow up<br />Backlog<br />Prepare<br />Competency Improvement Team<br />
  163. 163. Move from development to delivery teams<br /><ul><li>Dedicate QA and BA to specific teams
  164. 164. Train on the flow of work through the teams
  165. 165. Work from a single backlog</li></li></ul><li>Value Management Team<br />Program level<br /><ul><li>Value Management Team with PO per Feature
  166. 166. Align PMO approach with Feature level delivery</li></ul>Produce<br />Make Ready<br />Initiate<br />UAT<br />Value Management<br />Delivery Teams<br />Plan<br />Implement<br />Follow up<br />Backlog<br />Prepare<br />Competency Improvement Team<br />
  167. 167. Future: Align with Strategy, Support<br />Portfolio Level<br /><ul><li>Use Business Architecture to align and prioritize requirements with the services platform</li></ul>Evaluate<br />Verify<br />Explore<br />Deliver<br />Portfolio Management<br />Produce<br />Make Ready<br />Multiple Team Level<br /><ul><li>Support team (or dedicated performers) to improve predictability</li></ul>Initiate<br />UAT<br />Value Management<br />Support<br />Delivery Teams<br />Plan<br />Implement<br />Follow up<br />Backlog<br />Prepare<br />Capability Improvement<br />
  168. 168. Lessons Learned<br />Aligning development into stable teams with a clear backlog and then introducing QA and BA into the existing teams was organizationally easier – but we have to form all the teams twice<br />The guiding coalition and a focus on change management is critical to the transformation<br />The production support demands from technical debt and the historic approach makes predictability very difficult to achieve<br />Moving PMO attention to the Feature Level made transitioning the governance model easier<br />
  169. 169. Case Study #4 – Energy Management Company<br />
  170. 170. Company Profile<br />European company with offices across the United States<br />Thousands of employees worldwide, several hundred in the US<br />Significant amount of product development work done offshore in India<br />
  171. 171. Problem Statement<br />Adopted Scrum several years ago, not getting the expected business benefit<br />Releases are constantly delivered with significantly less features than planned and are often behind schedule<br />Hardware and firmware delivery out of sync with the management console software<br />Pretty significant trust issues between senior leaders and their direct reports. <br />
  172. 172. Engagement Approach<br />Conducted a competency assessment on the entire division<br />Collaborated on a top-down plan led by the Director of Quality & Process with full support from the CTO<br />Started with the teams in Atlanta and are currently moving through other geographies<br />
  173. 173. Engagement Approach – Phase I<br />Agile teams were in place, but did not stay together over time. First step we formed persistent teams<br />Requirements decomposition was not happening, so we build a Product Owner team to develop the backlog <br />Focused on Product Definition, Planning & Coordination, and Organizational Enablement Competencies first<br />Exclusively at the Release level to start<br />
  174. 174. Engagement Approach – Phase 2<br />Continued to ignore the teams and went for Portfolio & Strategy<br />Established an Agile Release Train<br />Still focusing on Product Definition, Planning & Coordination, and Organizational Enablement Competencies<br />Uncovered significant trust issues between senior level managers within engineering and product management<br />
  175. 175. Engagement Approach – Phase 3<br />Started addressing performance of the teams<br />Started addressing cultural issues around trust and transparency at all levels of the organization <br />Next steps address Delivery Practices and Continuous Improvement <br />Started to revise the roadmap by modeling the entire flow of value from Sales through Product Development into Support and Operations<br />Tighter integration of hardware and firmware<br />
  176. 176. Team<br />
  177. 177. Multi-Team<br />
  178. 178. Multi-Team<br />
  179. 179. Multi-Team<br />
  180. 180. Program Management<br />
  181. 181. Program Management<br />
  182. 182. Portfolio & Team<br />
  183. 183. Program Management<br />
  184. 184. Multi-Team<br />
  185. 185. Enterprise Agility?<br />
  186. 186. Construction<br />Transition<br />Elaboration<br />Inception<br />Tier 3 - Kanban<br />Deploy<br />Build <br />Test <br />Design<br />Analysis<br />Tier 2 - Kanban<br />
  187. 187. Story Backlog<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />Tier 1 - Scrum<br />
  188. 188. Construction<br />Transition<br />Elaboration<br />Inception<br />Tier 3 - Kanban<br />Deploy<br />Build <br />Test <br />Design<br />Analysis<br />Tier 2 - Kanban<br />Story Backlog<br />In Process<br />Task Done<br />Task Backlog<br />Story Backlog<br />Tier 1 - Scrum<br />
  189. 189. Lessons Learned<br />Engineering only change initiatives are likely to struggle<br />Effectively integrating with non-Agile work streams can make or break a transformation effort<br />Understanding the flow of value across the entire organization is critical<br />Starting with teams isn’t always the most strategic approach<br />
  190. 190. Key Takeaways <br />Introducing Agile at Scale is best done incrementally and iteratively<br />To lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organization<br />Organizational agility is not about adopting a specific set of practicesbut developing strategies to address competencies at different frequencies and different scales<br />
  191. 191. Key Takeaways <br />Introducing Agile at Scale is best done incrementally and iteratively<br />To lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organization<br />Organizational agility is not about adopting a specific set of practicesbut developing strategies to address competencies at different frequencies and different scales<br />
  192. 192. Key Takeaways <br />Introducing Agile at Scale is best done incrementally and iteratively<br />To lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organization<br />Organizational agility is not about adopting a specific set of practicesbut developing strategies to address competencies at different frequencies and different scales<br />
  193. 193. Key Takeaways <br />Introducing Agile at Scale is best done incrementally and iteratively<br />To lead sustainable organizational change, you have to address the structure of the organization, your practices and tools, and also the people in the organization<br />Organizational agility is not about adopting a specific set of practicesbut developing strategies to address competencies at different frequencies and different scales<br />
  194. 194. Mike CottmeyerLeadingAgilemike@leadingagile.com 1.404.312.1471www.leadingagile.comtwitter.com/mcottmeyerfacebook.com/leadingagilelinkedin.com/in/cottmeyer<br />Dennis StevensSynaptusdennis.stevens@synaptus.com 770.851.8025www.synaptus.comtwitter.com/dennisstevens<br />

×