How Does IBM Do Agile


Published on

How Does IBM Do Agile presentation that I presented at the Software Development Conference in Wellington, New Zealand at 22 March 2011.

1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Show what’s been done – roles. Process adaptations: PMC within Rational to ensure project funnel IBM product delivery process. Print them on DVDs. Agile
  • Common agile practices: iterative, reflect, adapt, incremental, feedback Practices inspired by agile practices, scrum, xp, some custom ones, that work for us
  • Distributed development: planning an iteration takes longer
  • Chickens – give feedback, also support dev team (pigs) doing the complete job. Light adaptation – in scrum – architects on the pigs side usually. This time we have them in chickens becoz ibm architects get info from customers, present to customers, very customer focused. At the same time building things.
  • 2 reasons for these slides – 1. use terminology well know. 2. trying to apply things as they should. Less developers asking for strange things, etc. apply as much as agile as poosible. It’s a big change for IBM, but we are willing to adapt agile, not mixture. We’re doing what we can to become more agile. For a while, we mixed 2 teams, so all coming from RTCz and RTCp. Originally 2 project owners. Now have just one enterpirse extension team. Still have 2 project owners. To ensure actual release. In 3.0.1 only Guy -> from NZ. Guy Slade.
  • How Does IBM Do Agile

    1. 1. How IBM Does Agile Alan Kan – Technical Manager, IBM Rational 22/3/2011
    2. 2. How we used to work
    3. 3. How we work now
    4. 4. Jazz - transforming software delivery <ul><li>Jazz is… </li></ul><ul><ul><li>Our vision of the future of systems and software delivery </li></ul></ul><ul><ul><li>A scalable, extensible team collaboration platform </li></ul></ul><ul><ul><li>An integration architecture enabling mashups and non-Jazz products to participate </li></ul></ul><ul><ul><li>A community at where Jazz products are built </li></ul></ul><ul><ul><li>An evolution of our portfolio over time </li></ul></ul>c Rational Offerings Third party Offerings Business Partner Offerings Jazz is a platform for transforming how people work together to deliver greater value and performance from their software investments.
    5. 5. Essential attributes of Jazz Deliver real-time insight into programs, projects and resource utilization. Report Automate non-creative tasks with automated processes and workflows Automate Improve knowledge and practice maturity with an environment that develops individual and team talent. Deliver transparency of teams and projects for continuous, context-sensitive collaboration Collaborate
    6. 6. CLM supports effective team collaboration across lifecycle Quality Professional Product Managers Collaborative Lifecycle Management Project Team Developers Quality Management Requirements Development
    7. 7. The distributed Jazz Team
    8. 8. Our Reality – Agile Scaling Challenges Domain Complexity Straight -forward Intricate, emerging Compliance requirement Low risk Critical, audited Enterprise discipline Project focus Enterprise focus Technical complexity Homogenous Heterogeneous, legacy Flexible Rigid Organizational complexity Team size Under 10 developers 1000’s of developers Co-located Geographical distribution Global Organization distribution (outsourcing, partnerships) Collaborative Contractual Agility @ Scale
    9. 9. Team organisation <ul><li>We work in both component and feature teams </li></ul><ul><li>Component team </li></ul><ul><ul><li>Dependencies between adoptions tracked using Adoption Items </li></ul></ul><ul><li>Feature teams </li></ul><ul><ul><li>Execution tracked in the plan items </li></ul></ul>Feature Team Component Team Responsible for complete customer feature across products/components Responsible for only part of a customer feature Minimized dependencies Dependencies between teams leads to additional planning Iterative development More sequential development due to adoption sequence Optimizes customer value Optimizes for a particular component
    10. 10. Scrum applied <ul><li>Development process </li></ul><ul><ul><li>Based on the standard Scrum process template </li></ul></ul><ul><li>Minor process adaptations </li></ul><ul><ul><li>New role: PMC ( Project Management Council - based on Stakeholder role) </li></ul></ul><ul><ul><li>New Minutes work item </li></ul></ul><ul><ul><li>Updated permissions </li></ul></ul><ul><ul><ul><li>PMC can update Plans </li></ul></ul></ul><ul><ul><ul><li>Limited operations for externals </li></ul></ul></ul><ul><ul><li>New automatic tasks when joining a team </li></ul></ul><ul><ul><ul><li>[Joining a Team] Update your calendar with your Scheduled Absences </li></ul></ul></ul><ul><ul><ul><li>[Joining a Team] Update your Work Environment </li></ul></ul></ul>
    11. 11. Adaptation of development practices iterative development API first end game retrospectives always have a client continuous integration community involvement new & noteworthy adaptive planning continuous testing consume your own output drive with open eyes validate reduce stress learn attract to latest transparency validate update feature teams show progress enable validate live betas feedback sign off End of iteration demos/reviews Ranked Product Backlog Burndown Stories Daily Standup independent testing exploratory testing Definition of Done
    12. 12. Sprint planning detailed <ul><li>First days of each Sprint </li></ul><ul><ul><li>Get Sprint directions from Product Owner </li></ul></ul><ul><ul><li>Analyze Stories with the Architects </li></ul></ul><ul><li>All Scrum team members are involved </li></ul><ul><li>1 Sprint planning per Scrum team </li></ul><ul><li>Check Sprint time budget </li></ul><ul><ul><li>Plan/verify absences in RTC </li></ul></ul><ul><li>From Product Backlog ... </li></ul><ul><ul><li>Query Work items </li></ul></ul><ul><ul><li>Team members try to fully understand User Stories with the help of the Architects </li></ul></ul><ul><ul><li>Give estimates using the Planning Poker technique </li></ul></ul><ul><li>...To Iteration Plan </li></ul><ul><ul><li>Fill Sprint backlog with selected Stories based on team velocity and priorities </li></ul></ul>
    13. 13. Our Rhythm endgame release M1 plan develop stabilize 4-6 weeks warm-up retrospective initial release plan decompression M2 plan develop stabilize … plan develop stabilize sign-off sign-off sign-off 4-6 weeks 4-6 weeks fix - spit & polish test fix test Retrospective New&Noteworthy End of iteration demo
    14. 14. Stakeholder roles, aka ‘ Chickens’ <ul><li>Chickens’ are not part of the actual Scrum process, but they must be engaged and provide feedback . </li></ul><ul><li>Main Stakeholders </li></ul><ul><li>Project Management </li></ul><ul><li> users </li></ul><ul><li>Light adaptation from standard Scrum </li></ul><ul><ul><li>Product Owners & Architects are also ‘ Chickens ’ </li></ul></ul>
    15. 15. Development roles, aka ‘ Pigs’ <ul><li>‘ Pigs’ are the ones committed to the project and the Scrum process. </li></ul>Scrum team in action?
    16. 16. Daily Scrum
    17. 17. Keep track of work
    18. 18. Collaborate with team Instant collaboration / share context Various levels of work planification Discuss/exchange work with members
    19. 19. Elaborate user stories Product Backlog User Stories, Epics Defects, Change Requests
    20. 20. Advanced source code management Easily suspend and resume work Reproduce the exact workspace of any build Work in parallel without making branch copies
    21. 21. Managing integrations from multiple teams
    22. 22. Agile Testing Quadrant * <ul><li>There is an independent system testing team (SVT) </li></ul>Functional Testing Exploratory Testing Scenario Testing Usability Testing Alpha/Beta Performance Testing Security Testing Unit Tests * Agile Testing: A Practical Guide for Testers and Agile Teams Lisa Crispin, Janet Gregory Technology Facing Business Facing Critique Product Supporting the team Dev Team System Test
    23. 23. Test management
    24. 24. Trace tests to user stories CLM Traceability Queries Linked Test Case
    25. 25. Blocked Test Execution
    26. 26. Project status at a glance Burndown charts Various project health dashboards Team communication
    27. 27. Retrospectives <ul><li>Retrospective work item </li></ul><ul><li>Teams reflect on what worked what didn’t </li></ul><ul><li>How to tune the process </li></ul><ul><li>Define action items </li></ul>
    28. 28. Lessons learnt <ul><li>Short cycle can be difficult to achieve </li></ul><ul><li>Agile acceptance varies amongst members </li></ul><ul><li>Scaling up -> more chickens -> bureacuracy </li></ul><ul><li>Reduce paperwork by automation </li></ul><ul><li>Geographically distributed -> can’t meet </li></ul><ul><li>Scrum of scrum needed </li></ul><ul><li>Tune your process until you get it right </li></ul>
    29. 29. IBM becomes more Agile 8500+ users
    30. 30. Learn more on
    31. 31. Experience IBM Rational’s Collaborative Lifecycle Management <ul><li>Complimentary half-day hands-on workshop </li></ul><ul><li>CLM Scrum process </li></ul><ul><li>Rational Team Concert, Rational Requirement Composer, Rational Quality Manager </li></ul>4 April 2011 Cliftons Centre Level 28, The Majestic Centre 100 Willis Street Wellington 6011 Limited Seats Register now at IBM Lounge
    32. 32. Questions <ul><li>Alan Kan </li></ul><ul><li>Technical Manager, IBM Rational </li></ul><ul><li>[email_address] </li></ul>