Agile 2010 conference - a holistic approach to scaling agile at salesforce
•
6 likes•12,303 views
Salesforce.com - presentation at the Agile 2010 conference on scaling agility
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (14)
Similar to Agile 2010 conference - a holistic approach to scaling agile at salesforce
Similar to Agile 2010 conference - a holistic approach to scaling agile at salesforce (20)
More from Steve Greene
More from Steve Greene (16)
Recently uploaded
Recently uploaded (20)
Agile 2010 conference - a holistic approach to scaling agile at salesforce
- 1. A holistic approach to scaling agile at Salesforce.com Agile 2010 Conference Orlando, Florida Steve Greene Nicola Dourambeis
- 2. Who are we?
- 3. Steve Greene VP, Program Management Nicola Dourambeis Director, Agile Delivery
- 4. Problems?
- 6. Lack of Visibility
- 10. 2000 2001 2002 2003 2004 2005 2006 Features Delivered per Team Days between Major Releases
- 11. What did we do about it?
- 13. The Beginning (2006) 2006 25+ agile teams in R&D
- 14. 2010 100+ agile teams R&D, IT, & Technical Operations
- 15. What is ADM? ADM (Adaptive Delivery Methodology) Salesforce.com flavor of agile Scrum project management framework XP practices Based on Lean principles
- 16. Next steps to scale
- 17. We scale both deep and wide
- 18. After success with R&D, ADM was rolled out to IT
- 19. 3 month rollout: Don’t overthink it, start, inspect and adapt
- 20. Next Up: Technical Operations moved to ADM
- 21. Embrace Difference and be prepared to stretch Agility
- 22. Wide scale has challenges, scaling deep has more
- 23. Challenges
- 24. Aggressive Hiring Let’s change the world!
- 26. One Codeline
- 28. Leadership
- 29. Solutions
- 30. Scale Problem #1 Dependency Management is Hard Dependency Management is Hard
- 31. Just enough structure but no more
- 32. ADM Release Cycle Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Coordinate release planning with generic framework Planning cycle for next release Planning cycle for next release Planning cycle for next release Release Release Release Release
- 33. Tools Help
- 34. But really, it’s the people that make things happen
- 35. And we make a big investment in collaboration
- 36. Maintain Technical Health Debt is the Enemy
- 37. Create a Single Definition of Done
- 38. Stop the codeline when test failures are too high
- 39. Strong Attention to metrics Status Metric Now (7/30) Release Criteria Potentially Releasable Metrics Feature Freeze Threshold Basic Ftest 100% 100.0% Utest 100% 100.0% Full Ftest 100% >99.8% Extended Ftest 96.86% >99.75% Basic Selenium 99.76% 100.0% Selenium 99.6% >99.5% Unresolved Integrations 0 0
- 40. Maintain team focus
- 41. Hire for Values and Culture Fit
- 42. Let’s go deeper
- 43. Case Study
- 45. Urgent change based on new strategic direction
- 46. The ugly baby
- 47. High Level Goals Design & Priorities
- 48. Global Prioritized “Feature” backlog
- 49. Move teams not people
- 50. 26 to 33 to 27 Teams Team 13 Team 11 Team 9 Team 10 Team 14 Team 8 Team 7 Team 12 Team 19 Team 18 Team 16 Team 15 Team 17 Team 25 Team 21 Team 20 Team 27 Team 22 Team 23 Team 24 Team 26 Team 2 Team 3 Team 4 Team 5 Team 1 Team 6
- 51. Launch & Collaborate
- 52. Align to Workgroups Team 13 Team 11 Team 9 Team 10 Team 14 Team 8 Team 7 Team 12 Team 19 Team 18 Team 16 Team 15 Team 17 Workgroup 4 Workgroup 2 Team 25 Team 21 Team 20 Team 27 Team 22 Team 23 Team 24 Team 26 Team 2 Team 3 Team 4 Team 5 Team 1 Team 6 Workgroup 1 Workgroup 3
- 53. Collaboration is key (up, down, across)
- 54. Meet to realign every day
- 55. Full Coordinated Transparency
- 56. Visibility to Program feature priorities
- 58. Program Dependencies Delivering Team & Feature Consuming Team & Feature May June July Team 8 Team 7 Team 22 High Med Low Risk Done – Delivered Low – On track Medium – Possible concerns/may miss deadline High – Not scheduled, cannot deliver, or deadline missed Team 12 Team 18 Team 10 Team 11 Monitor complexity & maintain visibility Something more Something I want Done Feature at risk Feature Something I need Cool Feature Something else I need Another Cool Feature
- 59. Lessons Learned
- 60. Be Bold and don’t go Halfway
- 61. Don’t be satisfied, always look for things to improve
- 62. Stick to your principles Trust the teams over creating mandatory process & structure
- 63. Agile does work at scale Lightweight structure & more autonomy
Editor's Notes
- How we’ve applied agile organizationally at scale Challenges of scale Agile can be done at scale
- At salesforce we have scaled both deep and wide. When we refer to deep, we mean that we have embedded agility very deep into the enterprise and have tackled and continue to face some of the more difficult enterprise scaling issues. Most of out talk today will be focused on specific areas where we go deep. However, before we get to that, we wanted to touch on organizational breadth of our agility. At salesforce our Technology and Products organization is 100%. That means that over 1000 people and more than 100 teams actively use ADM. There is no other methodology in use to deliver work. In fact, ADM has gained such a strong reputation inside salesforce that we are now starting to see other parts of the organization apply ADM—with Marketing being the most recent case.
- Steve just walked you through our transformation in R&D to ADM and I’ll talk you through our Internal IT story. After two years of successful use of ADM in R&D, our leadership started to ask why we were not using it in IT. The fact is, IT pre-ADM suffered from many of the same issues that ADM had specifically addressed for us in ADM --too much work, too many priorities --Lack of visibility on progress --Difficulty resourcing projects and skill set gaps --Lack delivery predictability --Late feedback from internal customers I use this image because for many business customers, IT is a bit of a black hole. Requests come in and after some period of time, work comes out the other end (often after many months where the progress can only be seen through status reports).
- So, we rolled it out to IT—an org of over 125 people who do three main type of work: application development (like R&D), vendor integrations using third party software and infrastructure projects like office build outs. We modeled the rollout on R&D and here are the basic steps: --firstly, gain executive buy-in and support. This might take a long time and requires work but is critically important. --step two: figure out your teams. When you are going from waterfall to agile, it’s common to find that your organization isn’t staffed correctly. For example, in IT we had lots of project managers but not enough delivery folks (developers, QA). 3 months Determine teams Get executive buy-in Train, train, train Launch teams Coach, adapt, correct Let go
- Teams did not work well together: Break down silos Use same language ADM Everywhere Too many priorities Lack of bottom up feedback and visibility
- Working with TechOps has caused us to stretch our understanding and application of ADM. TechOps is infrastructure and operations (software and infrastructure) Not only is the work in TechOps different than other parts of the org but also the culture is different.
- Scaling across the org was hard and it is a constant work in progress. --each org has different needs, approaches and variations which require support But even within these challenges, going deep is harder than wide. We strive to stay lightweight, respect the autonomy and authority of teams, while increasing collaboration and
- People
- People
- At salesforce Trust is our number one value. We only have a single version of our service and we cannot risk our customers’ success with low quality software. We have ensure that debt – both is quantity of bugs and test failures as well as quality and maintainability of our codebase – is avoided at all costs, by an ever increasing number of teams
- Tools: GUS built internal tools for automation and scrum with robust reporting. These reports are reviewed daily—by all teams. -our standard is 99% plus and it graduates throughout And its crucial to our success. Potentially releaseable, continuously releaseable
- People: maintain the autonomy and integrity of the team. We resist resourcing changes to stabilize and ultimately optimize teams. Make it easy to understand priorities globally and build relationships with dependent teams.
- Raw talent is not enough. Hiring process has a heavy focus on cultural alignment. This is only successful if everyone – executives, managers and team members have the same value system. We look for people who are learners, empirical, how do they adjust to change Don’t want debt
- Process