A holistic approach to scaling agile  at Salesforce.com Agile 2010 Conference Orlando, Florida Steve Greene Nicola Douramb...
Who are we?
Steve Greene VP, Program Management Nicola Dourambeis Director, Agile Delivery
Problems?
<ul><li>Unpredictable completion of anything </li></ul>
Lack of  Visibility
 
Resource Bottlenecks
Infrequent Customer Feedback
2000  2001  2002  2003  2004  2005  2006  Features Delivered per Team  Days between Major Releases
What did we do about it?
 
The Beginning (2006) 2006   25+  agile   teams in R&D
2010   100+ agile teams R&D, IT, & Technical Operations
What is ADM? ADM (Adaptive Delivery Methodology)  Salesforce.com  flavor of agile Scrum project management framework XP pr...
Next steps to scale
We scale both deep and wide
After success with R&D,  ADM was rolled out to IT
3 month rollout: Don’t overthink it, start, inspect and adapt
Next Up: Technical Operations moved to ADM
Embrace Difference and be prepared to stretch Agility
Wide scale has challenges,  scaling deep has more
Challenges
Aggressive Hiring  Let’s change the world!
Scale with values
One  Codeline
Product Dependencies
Leadership
Solutions
Scale Problem #1 Dependency Management is Hard Dependency Management  is Hard
Just enough structure but no more
ADM Release Cycle Feb  Mar  Apr  May  Jun  Jul  Aug  Sep  Oct  Nov  Dec  Jan Coordinate release planning  with generic fra...
Tools Help
But really, it’s the people that make things happen
And we make a big investment in collaboration
Maintain Technical Health Debt is the Enemy
Create a Single Definition of Done
Stop the codeline when test failures are too high
Strong Attention to metrics Status Metric Now (7/30) Release Criteria Potentially Releasable Metrics Feature Freeze Thresh...
Maintain team  focus
Hire for Values  and Culture Fit
Let’s go deeper
Case Study
Agile Program Management
Urgent change based on new strategic direction
The ugly baby
High Level Goals  Design  & Priorities
Global Prioritized “Feature” backlog
Move teams  not  people
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 ...
Launch &  Collaborate
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 W...
Collaboration is key (up, down, across)
Meet to realign  every day
Full Coordinated  Transparency
Visibility to Program feature priorities
Visibility to Workgroup feature priorities Features Priority Status <ul><ul><li>Console </li></ul></ul>1 <ul><ul><li>Clien...
Program Dependencies Delivering Team & Feature Consuming Team & Feature May June July Team 8 Team 7 Team 22 High Med Low R...
Lessons Learned
Be Bold  and  don’t go Halfway
Don’t be satisfied, always look for things to improve
Stick to your principles Trust the teams over creating mandatory process & structure
Agile does work at scale  Lightweight structure & more autonomy
Questions? http://www.slideshare.net/sgreene
Upcoming SlideShare
Loading in...5
×

Agile 2010 conference - a holistic approach to scaling agile at salesforce

4,981

Published on

Salesforce.com - presentation at the Agile 2010 conference on scaling agility

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,981
On Slideshare
0
From Embeds
0
Number of Embeds
8
Actions
Shares
0
Downloads
190
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • 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&amp;D to ADM and I’ll talk you through our Internal IT story. After two years of successful use of ADM in R&amp;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&amp;D), vendor integrations using third party software and infrastructure projects like office build outs. We modeled the rollout on R&amp;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
  • Agile 2010 conference - a holistic approach to scaling agile at salesforce

    1. 1. A holistic approach to scaling agile at Salesforce.com Agile 2010 Conference Orlando, Florida Steve Greene Nicola Dourambeis
    2. 2. Who are we?
    3. 3. Steve Greene VP, Program Management Nicola Dourambeis Director, Agile Delivery
    4. 4. Problems?
    5. 5. <ul><li>Unpredictable completion of anything </li></ul>
    6. 6. Lack of Visibility
    7. 8. Resource Bottlenecks
    8. 9. Infrequent Customer Feedback
    9. 10. 2000 2001 2002 2003 2004 2005 2006 Features Delivered per Team Days between Major Releases
    10. 11. What did we do about it?
    11. 13. The Beginning (2006) 2006 25+ agile teams in R&D
    12. 14. 2010 100+ agile teams R&D, IT, & Technical Operations
    13. 15. What is ADM? ADM (Adaptive Delivery Methodology) Salesforce.com flavor of agile Scrum project management framework XP practices Based on Lean principles
    14. 16. Next steps to scale
    15. 17. We scale both deep and wide
    16. 18. After success with R&D, ADM was rolled out to IT
    17. 19. 3 month rollout: Don’t overthink it, start, inspect and adapt
    18. 20. Next Up: Technical Operations moved to ADM
    19. 21. Embrace Difference and be prepared to stretch Agility
    20. 22. Wide scale has challenges, scaling deep has more
    21. 23. Challenges
    22. 24. Aggressive Hiring Let’s change the world!
    23. 25. Scale with values
    24. 26. One Codeline
    25. 27. Product Dependencies
    26. 28. Leadership
    27. 29. Solutions
    28. 30. Scale Problem #1 Dependency Management is Hard Dependency Management is Hard
    29. 31. Just enough structure but no more
    30. 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
    31. 33. Tools Help
    32. 34. But really, it’s the people that make things happen
    33. 35. And we make a big investment in collaboration
    34. 36. Maintain Technical Health Debt is the Enemy
    35. 37. Create a Single Definition of Done
    36. 38. Stop the codeline when test failures are too high
    37. 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
    38. 40. Maintain team focus
    39. 41. Hire for Values and Culture Fit
    40. 42. Let’s go deeper
    41. 43. Case Study
    42. 44. Agile Program Management
    43. 45. Urgent change based on new strategic direction
    44. 46. The ugly baby
    45. 47. High Level Goals Design & Priorities
    46. 48. Global Prioritized “Feature” backlog
    47. 49. Move teams not people
    48. 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
    49. 51. Launch & Collaborate
    50. 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
    51. 53. Collaboration is key (up, down, across)
    52. 54. Meet to realign every day
    53. 55. Full Coordinated Transparency
    54. 56. Visibility to Program feature priorities
    55. 57. Visibility to Workgroup feature priorities Features Priority Status <ul><ul><li>Console </li></ul></ul>1 <ul><ul><li>Client-Side Data Binding </li></ul></ul>2 <ul><ul><li>Sharing model </li></ul></ul>3 <ul><ul><li>Home page redesign </li></ul></ul>4 <ul><ul><li>Workbench </li></ul></ul>5 <ul><ul><li>Prioritizer UI </li></ul></ul>6 <ul><ul><li>Investigations support </li></ul></ul>7 <ul><ul><li>VF redesign </li></ul></ul>8 <ul><ul><li>RCA support </li></ul></ul>9 <ul><ul><li>Universal workflow </li></ul></ul>10 <ul><ul><li>api </li></ul></ul>11
    56. 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
    57. 59. Lessons Learned
    58. 60. Be Bold and don’t go Halfway
    59. 61. Don’t be satisfied, always look for things to improve
    60. 62. Stick to your principles Trust the teams over creating mandatory process & structure
    61. 63. Agile does work at scale Lightweight structure & more autonomy
    62. 64. Questions? http://www.slideshare.net/sgreene
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×