Agile India 2014 - Venkatraman L on Scaling Agile
Download as PPT, PDF1 like1,340 views
The document discusses scaling Agile practices within an organization, emphasizing the need for cross-functional teams and executive support to enhance predictability and visibility of releases. It outlines challenges faced in Agile adoption, including inter-team dependencies and communication gaps, while providing recommendations for effective collaboration and continuous improvement. The focus is on value-driven prioritization, effective planning, and the importance of measuring performance to drive Agile success.
Agile India 2014 - Venkatraman L on Scaling Agile
- 2. Agile – Pretty Simple :-)
- 3. Agenda • • • • Overview of the Organization and Teams Experiments & Experiments ! Scaling Agile Recommendations
- 4. Organization Overview Yes, teams were not cross-functional
- 5. Project, Program & Portfolio Portfolio > Programs > Feature Releases
- 6. Executive Expectations • • • • Need Predictability into releases Build credibility with business teams Provide visibility into what’s happening Manage the dependencies
- 7. With the challenges • • • • • Sorry, no pilot projects Ok, who all do we need in this release ? #search I made this change long back. Aren’t you aware ? Well, this is overall priority but that’s MY team's priority I have clarity on my team’s work – not sure about when this is being done in other teams – Do you know? #depth vs breadth • The requirement is not yet FROZEN #agile? • Oh Agile ? Too many meetings ! • I just merged this to trunk, you want me to rollback ? #rework
- 8. Meta Issues • • • • • • • • No firmed up prioritization criteria Changing technical contracts b/w teams once finalized Technical Infrastructure (build, automation) C O M M U N I C A T I O N within and beyond Goal of the organization Vs goal of the team Missing the big picture Visibility ** (Too much and too little) Lack of simple process to tie the entire puzzle together
- 9. Common Queries • What’s the VALUE of doing this Vs that ? • We are just fine. Why Agile ? • I am a developer, I am not sure of when this will be hit production – Maybe Ops will know :-) • Why is this Team A burndown better than Team B?
- 10. Foremost: Gap Identification 1. Inter-team dependencies 2. Intra-team dependencies 3. Visibility at all levels (Executive, Senior Leadership, Marketing, Sprint Teams) 4. “Plan of Record” – One single place for information 5. Agile Scrum training & gradual adoption across the teams ( focused on critical few )
- 11. Approach 1 - Virtual Teams
- 12. Approach 2 - “Stack Sprints”
- 13. Finally, Virtual + Sprints + Release Standups
- 14. Push & Pull (Scrum-Ban) Push 1. Backlog gets pushed to the teams during release breakup 2. Teams pop the requirements off the backlog as and when they plan Pull 1. Kanban used during sprint execution to notify the status of the requirements (Development Complete, Code Review, Ready for QA, Ready for Deployment etc)
- 15. So, what did scale ? • • • • • Duration : Q4 2011 through Q4 2013 Team members increased from 60 to 200 Teams increased from 6 - 14 #PM team increased from 4 - 10 Consequently, # Releases increased from 15 > 45 > 80+ The good news is that the framework seamlessly scaled to accommodate the growth in teams and the #releases
- 16. Current Focus • • • • • • • Value driven prioritization Capacity Visibility and Planning using APLM Tools Aligned teams to business units (for greater focus) Continuously improve engineering practices Adopt ScrumBan across the entire organization Predictability throug 6-sprint planning Ease of APLM Tool Usage **
- 17. 6-Sprint Look-ahead Planning Team A Sprint 1 Team B Team N Release 1 Release 2 Release 2 Release 2 Release 1 Sprint 2 : Sprint 6 Release 3 Release 3 Release 1 Release 3
- 18. Recommendations
- 19. ** Sponsor / Exec Support ** • • • Get the buy-in, consistently Solve the right problems than what you think they are Be open to feedback and criticisms
- 20. Have an open mind to “experiment” • Mix it up ! • Choose the best of what works for you • Adapt, Revise and Re-implement in faster cycles • Make it happen !
- 21. Intensely Focus on Architecture and Design • Agile does not talk about ignoring it • Design activities can start few sprints ahead • Spike ! • Influence the backlog • Plan (for) the future !
- 22. Break the Wall of Confusion – ** Embrace DevOps ** • Work as a team than in Silos for faster deployments • Unified Vision and Individual Goals • Break the “my territory” rule • Shift Left Source:http://dev2ops.org/2010/02/what-is-devops/
- 23. Collaborate (effectively) • Be active than a passive contributor • Effective Retrospectives • Focused Release & Sprint Planning • Focus on problems than people
- 24. Quality is Prime • • • • • • • Definition of Done (@ all levels) Shift Left Test Driven Development Unit Tests Acceptance Tests Automation …..
- 25. Measure • Keep it simple • Measure only what you can manage • Automate the metric capture • Manage them well
- 26. Pick what you can manage from.. Technical Operational Business Test Coverage Escaped Defects In Sprint Defects Cost of rework Code Quality Performance Defect ingestion Story point velocity Available capacity Capacity utilization Cost of the sprint($) Story points accepted / not accepted New scope added Technical Debt Stretch factor Time spent on Bugs vs feature Risk Register Updates Business Value delivered Customer Satisfaction Program Cycle Time Process cycle efficiency (%) Release Burn up Scope creep Contractual metrics ($) Portfolio Pie-chart of releases Health of the portfolio Prioritization changes ROI in the portfolio Contribution Margin Project
- 27. Keep them visible ! • • • Information Radiators Its all about transparency Out of sight is out of mind !
- 28. Agile != Scrum • Embrace XP, Lean Kanban, FDD …. Source: Version One Survey, 7th Annual State of Agile
- 29. And the surveys too confirm Source: Version One Survey, 7th Annual State of Agile
- 30. In Summary, • @ Engineers – your problems are largely technical, focus and solve for them ! • Using the guiding Agile Manifesto & Principles • Using the Agile Planning & Estimating Techniques • @ Line Managers / Scrum Masters – Remove impediments every single day (if not hourly) • Look ahead planning • @ Management – Aid Value Driven Prioritization and insulate the @ Engineers from being randomized