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

Sgin2013 scrum accomplished-industrialagilecasestudy-avinashrao

•
•
India Scrum Enthusiasts Community
India Scrum Enthusiasts Community

The document discusses challenges with implementing Agile practices at scale within large enterprises. Some key points: - Rework is higher in Agile projects which impacts perceived progress when measured by delivered size. However, Agile allows for earlier delivery of value. - Large enterprises have additional pressures like non-Agile dependencies, approvals from various stakeholders, and contractual obligations that can reduce Agile team autonomy. - Defining and splitting up requirements into user stories or features that multiple teams can work on simultaneously is challenging at scale. Approaches like hybrid WaterScrumFall may be needed. - Showcasing progress, value delivered, and managing expectations is important when non-traditional measures don't align

1 of 33
© Mindtree limited 2012 Industrial Agile Case Study: Structure, Management and Challenges Scrum Gathering® India Regional 2013 - Pune Avinash Rao Mindtree
Agile is becoming mainstream in the enterprise 2 ”We’ve run a proof of concept and we are impressed with the benefits of Agile! We want to roll it out across our IT shop.” “We have an efficient IT organisation; we are looking for ways to increase effectiveness. Agile is a step in that direction.” “We run large, complex, multi-year IT programs that will benefit from delivery of business value at regular, predictable intervals”
Parsing rationale for enterprise Agile adoption • “IT shop” • “Effectiveness as well as efficiency” • “Regular, predictable intervals” 3 Large enterprise CTOs have long managed IT for efficiency; Agile seems to offer an opportunity to increase effectiveness However the pressures that Agile faces in large enterprise programs are different from the incentives and measurements of smaller development projects
So what is this ‘Industrial’ Agile? • Multi-year New Product Development • Product Size > 10,000 FPs (Mk II) • Team > 200 people in more than a dozen scrum teams offshore all delivering a single product 4 This session shares the key experiences and learning from an Industrial Agile program. The focus is on scaling Agile for large programs in the enterprise.
Session Takeaways • Enterprise Agile looks different from traditional Agile in several ways • The pressures of size in Enterprise Agile, and the centralized planning and trade-offs needed for coordination across the enterprise • Do some cherished Agile ideals break down with size? • Also, given the pressures in many organizations around cost and schedule, is Agile the right choice for Enterprise IT? 5
Agenda • Enterprise IT goal posts • Managing completion • Contracting • Rework • Feeding the beast • Should definition be Agile? • Big UCs, Hybrids and Agile Definition • Working in the Enterprise eco-system 6
Enterprise IT goal posts 7 “So basically, you are wasting my money in the name of Agile?” Senior Management
In the name of Agile … • Managing Completion • Wasting Money – how much re-work is acceptable? • Distinguishing between Business and SMEs • Contracting • Continuous improvement • Impact of rework to product completion • 20% productivity penalty due to overheads and integration when re- working • More than 50% of the rework was imposed from outside the Agile project • Are Agile teams self-managing at this scale? 8
Traditional v/s Agile view of funding 9 Phase 1 complete CRs on Phase 1 Acceptance Project completion Benefit realization Project size: 100 FPs Measured by size (often the basis for funding), Agile projects show a slower rate of progress because of rework – this rework would have been funded by CRs on traditional projects
If only the requirements were perfect the first time .. 10 • The value of Agile isn’t that it is cheaper – it is that value is delivered early • However, re-work is incurred in Agile to course-correct (feedback from demos, acceptance); this is seen as a negative from a delivered size perspective • This problem is acute with Function Points – a case can quickly be made that if only the requirements were perfect the first time around, we wouldn’t be having so much rework …
Business v/s SMEs • But its Agile! I’m supposed to be able to make changes! • A legitimate concern is that SMEs deputed as customers to large Agile projects often focus on polishing functionality where good enough is often good enough for the business 11
Non-Agile dependencies and interfaces • Given the multitude of dependencies in enterprise IT, delivering value requires that the Agile project work with several non-Agile interfaces and approvers • Who manages the integration? Who owns an overall product view to take the project to completion? • These can quickly impose a planning overhead to the Agile project 12
Now bring in contracting considerations • Much IT is outsourced, and procurement likes pay for performance • Payments linked to size delivered are complicated by Agile – what is acceptable rework? Is there a vendor obligation to reduce re-work? 13
Continuous Improvement Targets • Procurement in IT is used to continuous improvement and vendor learning! • Improvements expected as familiarity increases with the process and project domain and technology variants • Lets look at a case where a 6% improvement was expected in Productivity Quotient (hours/unit work) 14 80 90 100 1 2 3 4 5 6 PQ Decreasing PQ Targets Note on data presented: • Normalized for output variations in teams, cumulative output • Variations presented as a % change • Absolute numbers are masked • Rework is client- commissioned re-work, not including defect fixes or other development overhead
Making sense of rework • We saw a wide variability in output from individual iterations, plotted against target PQ 15 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Investigating the variations • Factors investigated to explain the variation included: • Complexity of work across iterations • Staff movement • Vacations and holiday patterns • Defects raised on output • However, there appeared to be no difference in complexity of work handled, or in the teams that developed the functionality • The scrum masters, however, complained that they had more trouble with iterations that touched code already written 16
Plotting Productivity against Rework 17 • Plotting PQ against Rework started providing clues to the cause of the variation 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 PQ Rework
What was this re-work? • Some items we would see in all Agile projects: • Change in design • Others that come in play in large enterprise projects: • Defect fixes and changes in dependencies • Other partner changes or defects • Audits and checks on work performed in the past and submitted for approval • More than half of the impact was from outside the ‘Agile Project’ 18
The Rework – Productivity link The nature of Rework induced was a collection of small changes into functionality developed already The overheads in an iteration – planning day, testing (unit, regression, automation), code compliance and deployment is common irrespective of the amount of functionality developed Further, at a team level, rework resulted in fragmented idle time that could not be used; rework teams also waited more for other teams to complete We found a rework penalty of 20% for teams dealing with externally induced rework 19
Why the stress on contractual and measurement aspects? • Traditional methods of reporting progress may weigh against Agile • We believe that an Agile approach compounds the problem of cross application integration, if progress is measured in size • An additional wrinkle is added by defects found mid-iteration on other non- Agile code leading to spiraling effort without moving the product forward • Agile projects need to clearly showcase their progress and value delivered 20
Feeding the Beast 21 “Of all the questions that kept me awake at night, the biggest one that gnawed at me was – how will I keep the teams fed in the next iteration?” Manager, Requirements
Finding the right approach to definition • We began with a team of business analysts documenting requirements using traditional Use Cases • Given that there were already existing requirements available in areas of the product (developed pre-Agile), it seemed logical to continue with Use Cases • The Use Cases were approved and added to the product backlog for development • The Use Cases were large (often multiple iterations by multiple teams) 22 Many enterprises switching over to Agile already have some of requirements (which are unlikely to be User Stories) and would like them re-used
• Given the size of each Use Case, review and approval took weeks and sometimes months due to approvals from Corporate, Architecture or non- Agile dependencies 23 In smaller projects, it is easier to get stakeholders together and accelerate decision making. Large enterprises are unlikely to move all IT functions to Agile at once!
A hybrid traditional / Agile approach • What if the requirement teams released every two weeks? 24
Finally! Agile Requirements • We finally moved to a fully Agile mode of working where the business analysts released functionality every two weeks that was of a size that could be consumed by a single scrum team. • This is what we should have done in the first place, right? 25
WaterScrumFall? Agile definition turned into a nightmare for analysts • Complex functionality could not be part-delivered easily and, with dependencies, keeping track of outstanding items to be defined and tracking their dependencies soon became a full time task that reduced the productivity of the requirement teams. • It was extremely difficult to visualize a piece of working product and then specify it incrementally. On every iteration care had to be taken to ensure that the piece fitted the bigger picture and that every missing detail was captured in future definition iterations. 26
End state • It became imperative to modify the requirement documentation process to overcome these bottlenecks and the new approach was rolled back. • Finally, the functionality was divided into various domains and use cases were authored covering functionalities in a domain across various iterations. • Since requirements were gathered for each domain simultaneously, inter- dependency of functionalities was taken into account during requirement documentation. • This had the benefits of being efficient and effective for requirements, but the overhead of splitting work among multiple scrum teams remained. 27
Working in the Enterprise eco-system 28 The chaos of the Enterprise Bazaar
Success in Enterprise Agile Meta- Planning Working with non Agile dependencies: Scheduling approvals, requirements, deliveries & defect fixes Showcase: Budgeting and cost control, demonstrating progress and value “An Agile Project” 29 Architecture Security & Compliance Non-Agile IT Data centre Partners
An Agile project is just one part of the ecosystem A few things to keep in mind … • Company Architecture standards to be followed, approvals needed • Security and compliance audits, signoff • External partner dependencies and delays • How non-Agile dependencies provide releases and patches • Data centres are not agile! • Constantly showcase value delivered! 30
And in conclusion … 31
What were the results from our program? • Delivered a real product that could be demo-ed, deployed and used (with functional gaps) • Agile seen as critical to success – with waterfall, the program would likely have been deemed a failure • Additional funding provided to extend program 32
India | USA | UK | Germany | Sweden | Belgium | France | Switzerland | UAE | Singapore | Australia | Japan | China 33 Questions? Thank you!

More Related Content

Sgin2013 scrum accomplished-industrialagilecasestudy-avinashrao

  • 1. © Mindtree limited 2012 Industrial Agile Case Study: Structure, Management and Challenges Scrum Gathering® India Regional 2013 - Pune Avinash Rao Mindtree
  • 2. Agile is becoming mainstream in the enterprise 2 ”We’ve run a proof of concept and we are impressed with the benefits of Agile! We want to roll it out across our IT shop.” “We have an efficient IT organisation; we are looking for ways to increase effectiveness. Agile is a step in that direction.” “We run large, complex, multi-year IT programs that will benefit from delivery of business value at regular, predictable intervals”
  • 3. Parsing rationale for enterprise Agile adoption • “IT shop” • “Effectiveness as well as efficiency” • “Regular, predictable intervals” 3 Large enterprise CTOs have long managed IT for efficiency; Agile seems to offer an opportunity to increase effectiveness However the pressures that Agile faces in large enterprise programs are different from the incentives and measurements of smaller development projects
  • 4. So what is this ‘Industrial’ Agile? • Multi-year New Product Development • Product Size > 10,000 FPs (Mk II) • Team > 200 people in more than a dozen scrum teams offshore all delivering a single product 4 This session shares the key experiences and learning from an Industrial Agile program. The focus is on scaling Agile for large programs in the enterprise.
  • 5. Session Takeaways • Enterprise Agile looks different from traditional Agile in several ways • The pressures of size in Enterprise Agile, and the centralized planning and trade-offs needed for coordination across the enterprise • Do some cherished Agile ideals break down with size? • Also, given the pressures in many organizations around cost and schedule, is Agile the right choice for Enterprise IT? 5
  • 6. Agenda • Enterprise IT goal posts • Managing completion • Contracting • Rework • Feeding the beast • Should definition be Agile? • Big UCs, Hybrids and Agile Definition • Working in the Enterprise eco-system 6
  • 7. Enterprise IT goal posts 7 “So basically, you are wasting my money in the name of Agile?” Senior Management
  • 8. In the name of Agile … • Managing Completion • Wasting Money – how much re-work is acceptable? • Distinguishing between Business and SMEs • Contracting • Continuous improvement • Impact of rework to product completion • 20% productivity penalty due to overheads and integration when re- working • More than 50% of the rework was imposed from outside the Agile project • Are Agile teams self-managing at this scale? 8
  • 9. Traditional v/s Agile view of funding 9 Phase 1 complete CRs on Phase 1 Acceptance Project completion Benefit realization Project size: 100 FPs Measured by size (often the basis for funding), Agile projects show a slower rate of progress because of rework – this rework would have been funded by CRs on traditional projects
  • 10. If only the requirements were perfect the first time .. 10 • The value of Agile isn’t that it is cheaper – it is that value is delivered early • However, re-work is incurred in Agile to course-correct (feedback from demos, acceptance); this is seen as a negative from a delivered size perspective • This problem is acute with Function Points – a case can quickly be made that if only the requirements were perfect the first time around, we wouldn’t be having so much rework …
  • 11. Business v/s SMEs • But its Agile! I’m supposed to be able to make changes! • A legitimate concern is that SMEs deputed as customers to large Agile projects often focus on polishing functionality where good enough is often good enough for the business 11
  • 12. Non-Agile dependencies and interfaces • Given the multitude of dependencies in enterprise IT, delivering value requires that the Agile project work with several non-Agile interfaces and approvers • Who manages the integration? Who owns an overall product view to take the project to completion? • These can quickly impose a planning overhead to the Agile project 12
  • 13. Now bring in contracting considerations • Much IT is outsourced, and procurement likes pay for performance • Payments linked to size delivered are complicated by Agile – what is acceptable rework? Is there a vendor obligation to reduce re-work? 13
  • 14. Continuous Improvement Targets • Procurement in IT is used to continuous improvement and vendor learning! • Improvements expected as familiarity increases with the process and project domain and technology variants • Lets look at a case where a 6% improvement was expected in Productivity Quotient (hours/unit work) 14 80 90 100 1 2 3 4 5 6 PQ Decreasing PQ Targets Note on data presented: • Normalized for output variations in teams, cumulative output • Variations presented as a % change • Absolute numbers are masked • Rework is client- commissioned re-work, not including defect fixes or other development overhead
  • 15. Making sense of rework • We saw a wide variability in output from individual iterations, plotted against target PQ 15 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
  • 16. Investigating the variations • Factors investigated to explain the variation included: • Complexity of work across iterations • Staff movement • Vacations and holiday patterns • Defects raised on output • However, there appeared to be no difference in complexity of work handled, or in the teams that developed the functionality • The scrum masters, however, complained that they had more trouble with iterations that touched code already written 16
  • 17. Plotting Productivity against Rework 17 • Plotting PQ against Rework started providing clues to the cause of the variation 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 PQ Rework
  • 18. What was this re-work? • Some items we would see in all Agile projects: • Change in design • Others that come in play in large enterprise projects: • Defect fixes and changes in dependencies • Other partner changes or defects • Audits and checks on work performed in the past and submitted for approval • More than half of the impact was from outside the ‘Agile Project’ 18
  • 19. The Rework – Productivity link The nature of Rework induced was a collection of small changes into functionality developed already The overheads in an iteration – planning day, testing (unit, regression, automation), code compliance and deployment is common irrespective of the amount of functionality developed Further, at a team level, rework resulted in fragmented idle time that could not be used; rework teams also waited more for other teams to complete We found a rework penalty of 20% for teams dealing with externally induced rework 19
  • 20. Why the stress on contractual and measurement aspects? • Traditional methods of reporting progress may weigh against Agile • We believe that an Agile approach compounds the problem of cross application integration, if progress is measured in size • An additional wrinkle is added by defects found mid-iteration on other non- Agile code leading to spiraling effort without moving the product forward • Agile projects need to clearly showcase their progress and value delivered 20
  • 21. Feeding the Beast 21 “Of all the questions that kept me awake at night, the biggest one that gnawed at me was – how will I keep the teams fed in the next iteration?” Manager, Requirements
  • 22. Finding the right approach to definition • We began with a team of business analysts documenting requirements using traditional Use Cases • Given that there were already existing requirements available in areas of the product (developed pre-Agile), it seemed logical to continue with Use Cases • The Use Cases were approved and added to the product backlog for development • The Use Cases were large (often multiple iterations by multiple teams) 22 Many enterprises switching over to Agile already have some of requirements (which are unlikely to be User Stories) and would like them re-used
  • 23. • Given the size of each Use Case, review and approval took weeks and sometimes months due to approvals from Corporate, Architecture or non- Agile dependencies 23 In smaller projects, it is easier to get stakeholders together and accelerate decision making. Large enterprises are unlikely to move all IT functions to Agile at once!
  • 24. A hybrid traditional / Agile approach • What if the requirement teams released every two weeks? 24
  • 25. Finally! Agile Requirements • We finally moved to a fully Agile mode of working where the business analysts released functionality every two weeks that was of a size that could be consumed by a single scrum team. • This is what we should have done in the first place, right? 25
  • 26. WaterScrumFall? Agile definition turned into a nightmare for analysts • Complex functionality could not be part-delivered easily and, with dependencies, keeping track of outstanding items to be defined and tracking their dependencies soon became a full time task that reduced the productivity of the requirement teams. • It was extremely difficult to visualize a piece of working product and then specify it incrementally. On every iteration care had to be taken to ensure that the piece fitted the bigger picture and that every missing detail was captured in future definition iterations. 26
  • 27. End state • It became imperative to modify the requirement documentation process to overcome these bottlenecks and the new approach was rolled back. • Finally, the functionality was divided into various domains and use cases were authored covering functionalities in a domain across various iterations. • Since requirements were gathered for each domain simultaneously, inter- dependency of functionalities was taken into account during requirement documentation. • This had the benefits of being efficient and effective for requirements, but the overhead of splitting work among multiple scrum teams remained. 27
  • 28. Working in the Enterprise eco-system 28 The chaos of the Enterprise Bazaar
  • 29. Success in Enterprise Agile Meta- Planning Working with non Agile dependencies: Scheduling approvals, requirements, deliveries & defect fixes Showcase: Budgeting and cost control, demonstrating progress and value “An Agile Project” 29 Architecture Security & Compliance Non-Agile IT Data centre Partners
  • 30. An Agile project is just one part of the ecosystem A few things to keep in mind … • Company Architecture standards to be followed, approvals needed • Security and compliance audits, signoff • External partner dependencies and delays • How non-Agile dependencies provide releases and patches • Data centres are not agile! • Constantly showcase value delivered! 30
  • 32. What were the results from our program? • Delivered a real product that could be demo-ed, deployed and used (with functional gaps) • Agile seen as critical to success – with waterfall, the program would likely have been deemed a failure • Additional funding provided to extend program 32
  • 33. India | USA | UK | Germany | Sweden | Belgium | France | Switzerland | UAE | Singapore | Australia | Japan | China 33 Questions? Thank you!