SlideShare a Scribd company logo

Gears agile

•Download as PPTX, PDF•
•
A
ajit.alwe

The document aims to create a common language ("boundary object") to facilitate information exchange among communities interested in Agile transformation. It covers topics like change management options for Agile transformation, key levers for change, necessary conditions and investments for different options, and benefits including economic benefits. The document does not define project roles or communities of practice. It also does not describe how to implement Agile, which is handled at the project level based on factors like the project. The document seeks to establish a shared understanding to support discussions around Agile transformation.

Related slideshows

Guide to New Product Development (NPD)
Guide to New Product Development (NPD)Guide to New Product Development (NPD)
Guide to New Product Development (NPD)
 
DPPM2
DPPM2DPPM2
DPPM2
 
ITIL Practical Guide - Service Transition
ITIL Practical Guide - Service TransitionITIL Practical Guide - Service Transition
ITIL Practical Guide - Service Transition
 
1 of 30
Gears agile
2 | Intent of this document The intent of the document is to create Agile Transformation COMMON LANGUAGE (*boundary object) to exchange information among Community of Interest (CoI). i.e. Following topic are covered 1. Acknowledge the importance of change management in Agile Transformation 2. Different change management options in accelerating towards Agile 3. Key Change Leverages in each of these options 4. Necessary Conditions/Investment of these options 5. Benefits, including the economics benefits of these options 6. KPI for measuring maturity of each of these options This document does NOT 1. Define or Re-define Project Roles 2. Defne Community of Practices (CoP): i.e. Requirement Management, Iterative Development, Continuous Integration, Project Management, 3. Testing, Release management etc.. 4. Implementation of Agile, this will be handled at project level, based *Boundary Object - please familiarize this concept to understand the importance of communication among Community of Interests. http://exampler.com/testing-com/writings/marick-boundary.pdf
3 | Need for Common Language among Community of Interests *Boundary Object - please familiarize this concept to understand the importance of communication among Community of Interests. http://exampler.com/testing-com/writings/marick-boundary.pdf
AGILE TRANSITION- NECESSARY CONDITION 4 | Yearly/Semi-Annually Release Cycle Steps in Transition ?? Monthly or less Release Cycle Present Future
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan What is Agile The Agile Manifesto 5 evolving continuously based on shortcoming of past practices empirical approach
6 | 4 Levels - in Agile Manifesto - Excerpts of Minutes of Meeting of Agile Manifesto empirical approach
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan Agile Transformation – Rational for change The Agile Manifesto 7 Change asia today Future direction
8 | For CHANGE For CHANGE
9 | Avoiding yet another ‘Organization-Change-Initiative’ failure "The single must-be-present ingredient of successful organizational change is SAFETY.” – De Marco
Necessary Conditions for change to emerge 10
11 | Sponsors Individual Region Project team Corresponding - Entity Project team
1.Why to change ? 1. Economics - (Revenue , Save Time/Cost) 2. Moral imperative. the scope of what you are doing and why you are doing it. It is the reason why others follow you. <to be filled by each of the leader in hierarchy > 2.Where to start the change ? 1. What to change ? 2. What to change To ? 3. How to cause the change ? Improvement requires answering 2 top Questions 12
Revenue/Save Cost Business Operations Fast parallel validation/discovery of Market Opportunity information Vs Lowering cost of experiments in validating the information Monthly or less Release Cycle Unit of production release = Minimum Viable product/Feature smallest possible set of functionality that, by itself, has value in the marketplace 13 | 3 Gears for accelerating Agile Transformation DevOpsSec Yearly/ Semi- Annually Release Cycle Unit of production release = Project • Breaking requirements into user goals Vs Resource allocation • Multiple Team Vs Common definition of done from customer point of view Target Where change Why- $$ How What to change toWhat to change? Re-org IT Re-org Kanban Balance Opposing Constraints Method/Tools Feature Team Save Time in launching marketable Feature Save Cost Technical Operations Current project Org Release Speed Vs Production Stability
Gears Benefits Balance Opposing Constraints Investments/Necessary Conditions $$ 1 1. Common Language of Customer Value across the team 2. Optimize the Lead time of Features 3. Quality • Breaking requirements into user goals Vs Resource allocation • Multiple Team Vs Common definition of done from customer point of view 1. Break project into Minimum Viable Product (MVP) 1. Organize each MVP around User Stories and model them in Jira 2. Visualize the workflow in Jira to build common language 2. Create a release plan that deploys high-value features first 3. Resource allocation bias towards reducing lead time of each MVP Save Time 1 1. Better Market- Product/feature Fit 2. Business Process re- engineering Fast validation/discovery of Market Opportunity information Vs Lowering cost of experiments in validating the information 1. Concept to Cash workflow owned by Feature team 2. Composed of Business/Product manager, Lead Engineer, Usability expert 3. Responsible for fast/cheap prototyping capability to discover Pay off i.e. Discover if new feature/products/process can be introduced and sold at greater than their cost of development/maintenance 4. Market Opportunity backlog – is the input to the this team Revenue and/or Business Operation Cost Reduction 1 1. Higher throughput of Feature developed by team 2. Automated Test cases 3. Quality Release Speed Vs Production Stability 1. Invest in tools/Skills that enable Conversion of Tests, deployment, Infra to CODE and automate it 2. Project Team organization responsible for Development + QA + Operations + Security. Cost reduction 1- Technical Operation 2 New feature addition 14 | Investment / Necessary Condition CONFIDENTIAL Current proj. Org Re-org IT Re-org IT
Feature Team 15 | Re-org Concept to Cash workflow owned by single team
Why IT + Business as one Team? 16 | Product LEARNING OVER WORKING SOFTWARE Is key in case of New product/new feature being introduced in marketplace
Feature Team – ownership of Concept to Cash 17 | Market Opportunity Backlog Delivery Backlog Delivery Backlog Concept to Cash TEAM Product Delivery Team Plan-execute- verify Pay Off Discovery team – discover if new feature/products/process can be introduced and sold at greater than their cost of implementation/ maintenance Pay Off – Discovery Team Build- Measure-learn New Product: value proposition, target market, business metrics, competitive landscape, differentiator, market window, preliminary estimated cost, solution requirements) List of almost impossible. Existing Product - new projects, new feature, Business Process Reengineering Validated market opportunity assessment information Core IT Team
18 | CONFIDENTIAL Feature Team – Scaling Product development via 3 phases 1. Exploration – Owned by Pay-off Discovery Team 1. Key goal is to discover if new feature/products/process can be introduced and sold at greater than their cost of development/ maintenance 2. Key resource to optimize is to balance between running multiple parallel experiment and reduce cost of experimenting 3. Success axis- Economize validated information/discovery 2. Expand – Primarily owned by Deliver Team 2. Key resource to optimize- remove bottleneck for smooth onboarding of new user or increased transaction 3. Success axis- Economize safety, (Controlling cost and protecting throughput to balance demand) 3. Extract–Profit is optimized by reducing scalable costs • Success axis - Economize - economy of scale (where profit is optimized by reducing scalable costs) Pay Off point – Customer Discovery, Customer Validation. The unit of progress is learning, not execution S-Curve ( economics 101) Create/onboard Customer Scale
devOpsS ec 19 | Re-org IT + tools
20 | Agile’s technical journey so far devOps = Release speed + production stabilitySCRUM = frequent release = Unstable production devOpsSec = Release speed + production stability + data privacy Convert Tests, deployment, Infra to Code and Automate them Its all Code • Save it • Version it • Measure it • Evolve it devOps
Who suffers next ? the next Unicorn? “We are uncovering better ways of developing software by doing it and helping others do it. ………….” -Agile Manifesto first line 21 | Empirical mindset - evolving continuously based on shortcoming of past practices
22 | devOpsSec - Development + QA + IT Operations + Security and their tools Following Expertise within Team 1. data privacy 2. intrusion detection 3. threat vectors 4. package security 5. authentication 6. authorization 7. security standards compliance DevOps + Data Privacy = DevOpsSec PenTest +
Kanban 23 | Optimize Current project Organization ”...Kanban (capital K) is the evolutionary change method that utilizes a (kanban from lean) pull system, visualization, and other tools to catalyze the introduction of Lean ideas into technology development and IT operations (in evolutionary way)” - David J. Anderson, Kanban 2010
Why Kanban method -> Given constraint = existing project organization 24 | Team structure agnostic plus evolutionary mind set 1. Start with what you do now 2. Respect Current role and job titles 3. Agree to pursue incremental and Evolutionary change No. of practice - 3 No. of practice - 0No. of practice - 12No. of practice - 13No. of practice - 120
Kanban - Strategy for limiting Work-in- Progress 1. Group functionality into minimum viable product that can be released individually 1. Details each MVP with User Stories and model them in Jira 2. Create a release plan that deploys high-value features first. 3. Have the entire team focus on one releasable feature at a time. 4. Deploy releases as soon as possible. A MVP is the smallest possible set of functionality that, by itself, has value in the marketplace. 25 |
Kanban - Visualize the workflow 26 | To build common language about work and its progress
Strategy for Optimizing Lead Time Total Time worked = 4 wk 27 | start work on One demand request (worked -2 hrs ) Specification (worked -8 hrs ) Design (worked-22 hrs Development (worked -1 Wk) Test (worked 2 week ) Live (worked - 8 hrs ) 2 weeks Wait 5 weeks wait 2 weeks Wait 4 weeks wait 4 weeks wait Wait Time = 17 weeks Team 1 Team 2 Team 3 Team 4 Team 5 Team 6 Flow efficiency of the demand request = [4/ (17 + 4) ] * 100 = 17% Lead Time/ – 21 weeks Demand Requests
28 | Evolutionary Change – Little J Curve Coaches or any foreign element needs to be mindful of cost of change and needs to make attempt to follow Little J Curve. Not the long J Curve
29 | APPENDIX
Action Plan for Kanban approach 1. Common Language – to achieve Focus and Align Incentives. • Rationale - If you have separate language for description of goal tree and intervention, it is difficult to make transition • Actions - 3.5 hr Workshop – Project Simulation – to convey the key message of the Goal Tree 2. Start with what AXA traditional projects do now – Phase gate process • Rationale – Reduce the cost of transition. follows phase gate process, by the time work reaches the development teams, many of the Cost/Scope/Schedule/Quality decision have been taken by the earlier Phase Gates • Actions – Identify the phases which cannot be changed in first 1-3 release cycle of a given project 3. Respect the current process, roles, responsibilities and Titles • Rationale – People resist changes, if we drastically change role, without getting their buy-in on the benefit of change • Actions – Identify the artifacts used by the current roles to make decisions on optimizing the Lead time 4. Agree to pursue incremental and Evolutionary change • Actions – 1. Identify the phases which can be changed with minimum cost of intervention for first project release cycle to optimizing the lead time 2. Identify the ”Sufficient Condition” and update the Goal Tree for the given project. 3. Training need to implement the above changes for existing roles 30 |

More Related Content

Gears agile

  • 2. 2 | Intent of this document The intent of the document is to create Agile Transformation COMMON LANGUAGE (*boundary object) to exchange information among Community of Interest (CoI). i.e. Following topic are covered 1. Acknowledge the importance of change management in Agile Transformation 2. Different change management options in accelerating towards Agile 3. Key Change Leverages in each of these options 4. Necessary Conditions/Investment of these options 5. Benefits, including the economics benefits of these options 6. KPI for measuring maturity of each of these options This document does NOT 1. Define or Re-define Project Roles 2. Defne Community of Practices (CoP): i.e. Requirement Management, Iterative Development, Continuous Integration, Project Management, 3. Testing, Release management etc.. 4. Implementation of Agile, this will be handled at project level, based *Boundary Object - please familiarize this concept to understand the importance of communication among Community of Interests. http://exampler.com/testing-com/writings/marick-boundary.pdf
  • 3. 3 | Need for Common Language among Community of Interests *Boundary Object - please familiarize this concept to understand the importance of communication among Community of Interests. http://exampler.com/testing-com/writings/marick-boundary.pdf
  • 4. AGILE TRANSITION- NECESSARY CONDITION 4 | Yearly/Semi-Annually Release Cycle Steps in Transition ?? Monthly or less Release Cycle Present Future
  • 5. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan What is Agile The Agile Manifesto 5 evolving continuously based on shortcoming of past practices empirical approach
  • 6. 6 | 4 Levels - in Agile Manifesto - Excerpts of Minutes of Meeting of Agile Manifesto empirical approach
  • 7. We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan Agile Transformation – Rational for change The Agile Manifesto 7 Change asia today Future direction
  • 9. 9 | Avoiding yet another ‘Organization-Change-Initiative’ failure "The single must-be-present ingredient of successful organizational change is SAFETY.” – De Marco
  • 10. Necessary Conditions for change to emerge 10
  • 12. 1.Why to change ? 1. Economics - (Revenue , Save Time/Cost) 2. Moral imperative. the scope of what you are doing and why you are doing it. It is the reason why others follow you. <to be filled by each of the leader in hierarchy > 2.Where to start the change ? 1. What to change ? 2. What to change To ? 3. How to cause the change ? Improvement requires answering 2 top Questions 12
  • 13. Revenue/Save Cost Business Operations Fast parallel validation/discovery of Market Opportunity information Vs Lowering cost of experiments in validating the information Monthly or less Release Cycle Unit of production release = Minimum Viable product/Feature smallest possible set of functionality that, by itself, has value in the marketplace 13 | 3 Gears for accelerating Agile Transformation DevOpsSec Yearly/ Semi- Annually Release Cycle Unit of production release = Project • Breaking requirements into user goals Vs Resource allocation • Multiple Team Vs Common definition of done from customer point of view Target Where change Why- $$ How What to change toWhat to change? Re-org IT Re-org Kanban Balance Opposing Constraints Method/Tools Feature Team Save Time in launching marketable Feature Save Cost Technical Operations Current project Org Release Speed Vs Production Stability
  • 14. Gears Benefits Balance Opposing Constraints Investments/Necessary Conditions $$ 1 1. Common Language of Customer Value across the team 2. Optimize the Lead time of Features 3. Quality • Breaking requirements into user goals Vs Resource allocation • Multiple Team Vs Common definition of done from customer point of view 1. Break project into Minimum Viable Product (MVP) 1. Organize each MVP around User Stories and model them in Jira 2. Visualize the workflow in Jira to build common language 2. Create a release plan that deploys high-value features first 3. Resource allocation bias towards reducing lead time of each MVP Save Time 1 1. Better Market- Product/feature Fit 2. Business Process re- engineering Fast validation/discovery of Market Opportunity information Vs Lowering cost of experiments in validating the information 1. Concept to Cash workflow owned by Feature team 2. Composed of Business/Product manager, Lead Engineer, Usability expert 3. Responsible for fast/cheap prototyping capability to discover Pay off i.e. Discover if new feature/products/process can be introduced and sold at greater than their cost of development/maintenance 4. Market Opportunity backlog – is the input to the this team Revenue and/or Business Operation Cost Reduction 1 1. Higher throughput of Feature developed by team 2. Automated Test cases 3. Quality Release Speed Vs Production Stability 1. Invest in tools/Skills that enable Conversion of Tests, deployment, Infra to CODE and automate it 2. Project Team organization responsible for Development + QA + Operations + Security. Cost reduction 1- Technical Operation 2 New feature addition 14 | Investment / Necessary Condition CONFIDENTIAL Current proj. Org Re-org IT Re-org IT
  • 15. Feature Team 15 | Re-org Concept to Cash workflow owned by single team
  • 16. Why IT + Business as one Team? 16 | Product LEARNING OVER WORKING SOFTWARE Is key in case of New product/new feature being introduced in marketplace
  • 17. Feature Team – ownership of Concept to Cash 17 | Market Opportunity Backlog Delivery Backlog Delivery Backlog Concept to Cash TEAM Product Delivery Team Plan-execute- verify Pay Off Discovery team – discover if new feature/products/process can be introduced and sold at greater than their cost of implementation/ maintenance Pay Off – Discovery Team Build- Measure-learn New Product: value proposition, target market, business metrics, competitive landscape, differentiator, market window, preliminary estimated cost, solution requirements) List of almost impossible. Existing Product - new projects, new feature, Business Process Reengineering Validated market opportunity assessment information Core IT Team
  • 18. 18 | CONFIDENTIAL Feature Team – Scaling Product development via 3 phases 1. Exploration – Owned by Pay-off Discovery Team 1. Key goal is to discover if new feature/products/process can be introduced and sold at greater than their cost of development/ maintenance 2. Key resource to optimize is to balance between running multiple parallel experiment and reduce cost of experimenting 3. Success axis- Economize validated information/discovery 2. Expand – Primarily owned by Deliver Team 2. Key resource to optimize- remove bottleneck for smooth onboarding of new user or increased transaction 3. Success axis- Economize safety, (Controlling cost and protecting throughput to balance demand) 3. Extract–Profit is optimized by reducing scalable costs • Success axis - Economize - economy of scale (where profit is optimized by reducing scalable costs) Pay Off point – Customer Discovery, Customer Validation. The unit of progress is learning, not execution S-Curve ( economics 101) Create/onboard Customer Scale
  • 20. 20 | Agile’s technical journey so far devOps = Release speed + production stabilitySCRUM = frequent release = Unstable production devOpsSec = Release speed + production stability + data privacy Convert Tests, deployment, Infra to Code and Automate them Its all Code • Save it • Version it • Measure it • Evolve it devOps
  • 21. Who suffers next ? the next Unicorn? “We are uncovering better ways of developing software by doing it and helping others do it. ………….” -Agile Manifesto first line 21 | Empirical mindset - evolving continuously based on shortcoming of past practices
  • 22. 22 | devOpsSec - Development + QA + IT Operations + Security and their tools Following Expertise within Team 1. data privacy 2. intrusion detection 3. threat vectors 4. package security 5. authentication 6. authorization 7. security standards compliance DevOps + Data Privacy = DevOpsSec PenTest +
  • 23. Kanban 23 | Optimize Current project Organization ”...Kanban (capital K) is the evolutionary change method that utilizes a (kanban from lean) pull system, visualization, and other tools to catalyze the introduction of Lean ideas into technology development and IT operations (in evolutionary way)” - David J. Anderson, Kanban 2010
  • 24. Why Kanban method -> Given constraint = existing project organization 24 | Team structure agnostic plus evolutionary mind set 1. Start with what you do now 2. Respect Current role and job titles 3. Agree to pursue incremental and Evolutionary change No. of practice - 3 No. of practice - 0No. of practice - 12No. of practice - 13No. of practice - 120
  • 25. Kanban - Strategy for limiting Work-in- Progress 1. Group functionality into minimum viable product that can be released individually 1. Details each MVP with User Stories and model them in Jira 2. Create a release plan that deploys high-value features first. 3. Have the entire team focus on one releasable feature at a time. 4. Deploy releases as soon as possible. A MVP is the smallest possible set of functionality that, by itself, has value in the marketplace. 25 |
  • 26. Kanban - Visualize the workflow 26 | To build common language about work and its progress
  • 27. Strategy for Optimizing Lead Time Total Time worked = 4 wk 27 | start work on One demand request (worked -2 hrs ) Specification (worked -8 hrs ) Design (worked-22 hrs Development (worked -1 Wk) Test (worked 2 week ) Live (worked - 8 hrs ) 2 weeks Wait 5 weeks wait 2 weeks Wait 4 weeks wait 4 weeks wait Wait Time = 17 weeks Team 1 Team 2 Team 3 Team 4 Team 5 Team 6 Flow efficiency of the demand request = [4/ (17 + 4) ] * 100 = 17% Lead Time/ – 21 weeks Demand Requests
  • 28. 28 | Evolutionary Change – Little J Curve Coaches or any foreign element needs to be mindful of cost of change and needs to make attempt to follow Little J Curve. Not the long J Curve
  • 30. Action Plan for Kanban approach 1. Common Language – to achieve Focus and Align Incentives. • Rationale - If you have separate language for description of goal tree and intervention, it is difficult to make transition • Actions - 3.5 hr Workshop – Project Simulation – to convey the key message of the Goal Tree 2. Start with what AXA traditional projects do now – Phase gate process • Rationale – Reduce the cost of transition. follows phase gate process, by the time work reaches the development teams, many of the Cost/Scope/Schedule/Quality decision have been taken by the earlier Phase Gates • Actions – Identify the phases which cannot be changed in first 1-3 release cycle of a given project 3. Respect the current process, roles, responsibilities and Titles • Rationale – People resist changes, if we drastically change role, without getting their buy-in on the benefit of change • Actions – Identify the artifacts used by the current roles to make decisions on optimizing the Lead time 4. Agree to pursue incremental and Evolutionary change • Actions – 1. Identify the phases which can be changed with minimum cost of intervention for first project release cycle to optimizing the lead time 2. Identify the ”Sufficient Condition” and update the Goal Tree for the given project. 3. Training need to implement the above changes for existing roles 30 |