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


Published on - presentation at the Agile 2010 conference on scaling agility

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
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&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
  • Agile 2010 conference - a holistic approach to scaling agile at salesforce

    1. A holistic approach to scaling agile at 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?
    5. <ul><li>Unpredictable completion of anything </li></ul>
    6. Lack of Visibility
    8. Resource Bottlenecks
    9. Infrequent Customer Feedback
    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) 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!
    25. Scale with values
    26. One Codeline
    27. Product Dependencies
    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
    44. Agile Program Management
    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
    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
    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
    64. Questions?