How BMC is Scaling Agile Development


Published on

Agile 2006 Presentation by Israel Gat

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
  • In this experience report we examine the large scale deployment of Agile in BMC's Infrastructure Management Division. We identify and demonstrate several critical success factors such as visible intentionality, empowerment, risk taking, top notch Agile consulting, applying Agile as part of the overall software engineering "stack" and changing organizational structures to better apply Agile. In particular, we highlight the relationship between empowerment and risk-taking, and suggest the two should be managed in tandem as the foundation on which successful Agile projects can evolve. Finally we emphasize the importance of rolling agile out across multiple corporate functions - marketing, sales, support, professional serivces, etc. - and to the end customers, in order to get the full benefit at the corporate level.  
  • How BMC is Scaling Agile Development

    1. 1. How BMC is Scaling Agile Development Lessons Learned in Twelve Exhilarating Agile Months at BMC Israel Gat Vice President, Distributed Systems Management BMC Software
    2. 2. Major Themes <ul><li>Introduction </li></ul><ul><ul><li>PATROL Classic, BMC Performance Manager and Christensen </li></ul></ul><ul><ul><li>Four secret sauces we started with </li></ul></ul><ul><li>Lessons Learned </li></ul><ul><ul><li>Don’t agile the Agile </li></ul></ul><ul><ul><li>It is not a license to murder </li></ul></ul><ul><ul><li>Whatever you do, always stay releasable </li></ul></ul><ul><ul><li>One never has enough product managers </li></ul></ul><ul><ul><li>End-to-end </li></ul></ul><ul><ul><li>Scaling </li></ul></ul><ul><ul><li>The role of executive sponsorship </li></ul></ul><ul><li>Are you ready for Agile? </li></ul><ul><li>Enterprise Agility (time permitting) </li></ul>
    3. 3. Snapshot, January 2005 <ul><li>Staring at the whites of Christensen’s eyes </li></ul><ul><ul><li>The Innovator’s Dilemma was not an academic exercise for us in February 2005 </li></ul></ul><ul><ul><li>… . rather, it was a reality we stared at .… </li></ul></ul><ul><ul><li>… . had to find the means to address …. </li></ul></ul><ul><ul><li>… . and chose Scrum as the vehicle for so doing .… </li></ul></ul><ul><li>Realization that time was our number one enemy </li></ul><ul><ul><li>Had to create momentum faster than one could say “momentum” </li></ul></ul><ul><li>Transform the mood </li></ul><ul><ul><li>As all too often happens during Innovator’s Dilemma situations, too many good people were too worried whether the world loves them </li></ul></ul>
    4. 4. Snapshot, December 2005 <ul><li>Agile Adoption at BMC January 2005 to December 2005 Progress </li></ul><ul><li>Infrastructure Management Adoption </li></ul><ul><li>BMC Performance Mgr Infrastructure </li></ul><ul><li>BMC Performance Mgr Solutions </li></ul><ul><li>Classic PATROL Solutions </li></ul><ul><li>PATROL Reporting </li></ul><ul><li>BMC Recovery Mgmt </li></ul><ul><li>Other Organizational Adoptions </li></ul><ul><li>Exceptions Reporting and Escalation </li></ul><ul><li>BMC Impact Integration Dev Kit </li></ul><ul><li>Professional Services </li></ul><ul><li>Partner Certification Project (IT) </li></ul><ul><li>Dashboards; Identity Management; Service Management </li></ul>
    5. 5. Four Secret Sauces We Started With <ul><li>Visibility, commitment, and intentionality </li></ul><ul><ul><li>Agile first; the rest follows </li></ul></ul><ul><ul><li>Total immersion rather than limited trial </li></ul></ul><ul><li>Management philosophy </li></ul><ul><ul><li>Team confidence is built by a management team that instilled trust in them </li></ul></ul><ul><li>Willingness to take risks </li></ul><ul><ul><li>Giving up on top-down control of detailed feature scope </li></ul></ul><ul><ul><ul><li>.… empowering the teams to fill the details as you go .... </li></ul></ul></ul><ul><ul><ul><li>.… trusting that we will hit the themes at the end .… </li></ul></ul></ul><ul><ul><ul><li>.… even though we can't predict how all of the notes will end up …. </li></ul></ul></ul><ul><ul><li>Accepting we did not have all facets of Agile figured out in advance </li></ul></ul><ul><ul><ul><li>Had the confidence we will figure them out as we go along </li></ul></ul></ul><ul><li>Top notch Agile consulting </li></ul><ul><ul><li>You really need a big brother; Dean Leffingwell was mine </li></ul></ul><ul><ul><li>I doubt we would have mastered Agile at the scale and scope we applied it but for Dean and the Rally Software Development crew </li></ul></ul>
    6. 6. Don’t Agile the Agile <ul><li>Be fully cognizant you are introducing a disruptive methodology </li></ul><ul><ul><li>Your own teams </li></ul></ul><ul><ul><li>Ripples beyond your organization/function </li></ul></ul><ul><ul><ul><li>Could easily constitute a sources of friction between the Agile team and the rest of the corporation </li></ul></ul></ul><ul><li>Give the experiment enough time to bear fruit </li></ul><ul><ul><li>Allow the teams to struggle up the learning curve, and establish a baseline of predictability and success </li></ul></ul><ul><li>Shield the teams while struggling </li></ul><ul><ul><li>Any stumbles in the first few steps, and an emergent effort with Agile can be easily squashed in a large organization. </li></ul></ul>
    7. 7. Whatever You Do, Always Stay Releasable <ul><li>It is the acid test whether you are really doing Agile or de-facto reverting to quasi-waterfall </li></ul><ul><li>You might be going through the motions of Agile until your feet hurt from the daily stand-up meetings and other Agile practices, but you will lose the key advantages of Agile if you do not stay releasable on an on-going basis </li></ul><ul><ul><li>Productivity </li></ul></ul><ul><ul><li>Quality </li></ul></ul><ul><ul><li>Predictability </li></ul></ul>
    8. 8. It is not a License to Murder <ul><li>Rules of physics (and solid software engineering practices) apply </li></ul><ul><ul><li>Integration in the overall software engineering fabric </li></ul></ul><ul><li>Beware the dilettantes </li></ul><ul><ul><li>“ But of course I know Agile… we just practice it a little differently ” </li></ul></ul><ul><ul><li>“ Don’t worry about this feature not being in the release – it is OK in Agile to de-commit functionality” </li></ul></ul>
    9. 9. One Never has Enough Product Managers
    10. 10. Transition to End-to-End Agile Organization Agile R&D Teams R&D Teams Waterfall Optimized Organization Agile Organization Executive Management BU Mgt Sales Mgt Support Mgt Mkt Mgt Operational Team Executive Team
    11. 11. End-to-end Participation Direct Field Participation Release Planning I1 I3 I2 I4 I6 I5 I7 I8 Market Planning Market/Solution Release Plan Product Roadmap Product Release Plan Product Release Plan Iteration Demos / Requirements Backlog 3-4 months I1 I3 I2 I4 I6 I5 I7 I8 2 weeks Release Mgt
    12. 12. Scaling <ul><li>The Scrum team is the fractal organizational construct </li></ul><ul><li>Requirements and QA architects span teams within a group </li></ul><ul><li>Product management spans larger groups </li></ul><ul><li>Process maturity is critical </li></ul><ul><ul><li>The daily Scrum of Scrums keeps the various teams “real time” aligned </li></ul></ul><ul><ul><li>Process checkpoints serve as the glue for longer time spans </li></ul></ul><ul><ul><ul><li>Iteration level </li></ul></ul></ul><ul><ul><ul><li>Release level </li></ul></ul></ul><ul><li>Note the points about intentionality and no half-heartedness made earlier in the course of this presentation </li></ul><ul><ul><li>Basically we immersed all of the organization in Agile, rather than experimentation with a team or two </li></ul></ul>
    13. 13. The Role of Executive Leadership <ul><li>Be ready to take some casualties of people who: </li></ul><ul><ul><li>Don’t want to give up control/criticality (usually the heroic types) </li></ul></ul><ul><ul><li>Don’t want to change </li></ul></ul><ul><ul><li>Can’t change fast enough </li></ul></ul><ul><li>Manage empowerment and risk-taking in tandem as the foundation on which successful Agile projects evolve </li></ul><ul><ul><li>Teams embarking on Agile need to cope with simultaneous changes in: </li></ul></ul><ul><ul><ul><li>Skills Systems </li></ul></ul></ul><ul><ul><ul><li>Staff Practices </li></ul></ul></ul><ul><ul><ul><li>Structure Management philosophy </li></ul></ul></ul><ul><ul><ul><li>Value system </li></ul></ul></ul><ul><ul><li>They can’t do so unless they are appropriately empowered </li></ul></ul><ul><ul><li>Empowerment and risk-taking are inextricably linked </li></ul></ul>
    14. 14. Are You Ready for Agile? <ul><li>Wholehearted Empowerment </li></ul><ul><ul><li>Think once, think twice, think thrice, whether you are really, really, really, ready to empower in the full sense of the word </li></ul></ul><ul><ul><ul><li>Half-hearted measures would not cut it </li></ul></ul></ul><ul><ul><ul><li>Empowerment is like an acid test – for better or worse it will give you your defining moments </li></ul></ul></ul><ul><li>It does not happen without the courage to give up the Waterfall illusion of control </li></ul><ul><ul><li>Don’t take your boss out to lunch… </li></ul></ul><ul><ul><li>… take him/her to the daily standup meeting </li></ul></ul>
    15. 15. In the Final Analysis <ul><li>“ When we started with agile, I was concerned it might be a less disciplined method for development. In reality, it’s more disciplined, and provides more accountability” </li></ul><ul><li>[Paul Beavers; Senior Director, R&D] </li></ul><ul><li>“ If we used waterfall on BPM, we would still be in development. We would likely be cutting features right and left to try to bring the date back in.  Changes requested along the way by the solutions teams would have been pushed back on rather than embraced. ” </li></ul><ul><li>[Walter Bodwell; R&D Director] </li></ul><ul><li>“ For me the success of the release was closely managed from the day 1 in the Release planning meeting when the senior management told those product teams with low confidence level in their plans to not forcefully fit requirements into the fixed schedule.” </li></ul><ul><li>[John Im; R&D Manager] </li></ul><ul><li>“ The team has to continuously improve the Agile process, or the temptation to become rigid and staged will creep back into the processes.” </li></ul><ul><li>[Mike Lunt; R&D Manager] </li></ul><ul><li>“ There has never been a thought towards returning to Waterfall – we only think about how to be more agile – how to do this better.  No one wants to go back!” </li></ul><ul><li>[Becky Strauss; R&D Director] </li></ul>
    16. 16. <ul><li>Thank You! </li></ul><ul><li>[email_address] </li></ul>
    17. 17. Appendix: Enterprise Agility
    18. 18. Enterprise Agility at BMC Agile Component Team Agile Teams of Teams Agile Enterprise Scale (perpetual) Measurement A B C D Requirements runway Intentional Architecture Enterprise Tooling Iterate Iterate (2 wks) Design Test Build Release (3 mo) Harden and Ship Req Plan Iterate Iterate Iterate Agile Release Train Organizational Change Organizational Change Agile Release Train Requirements runway