SlideShare a Scribd company logo
1 of 52
ork
                              ile fr amew
             ga    n Ag                ation
Bu ildin                r :org   anis
             sreyenurs
         ip p s o te
   akt hfo t
 h
tWor s            rt Sola
                          rte
            r   Ku
                and
 Rick Weave
                    2
             May 201
                 th
       ay 29
  Tuesd
Building a smarter planet


    Agenda

  Welcome and introductions
  Activity
  Learning from IBM’s transformation to agility@scale
          Anti-patterns and scaling factors to look for
          Addressing the 5 Ps of IT
                                                                              Driving Business
  Activity                                                                      Differentiation
  Insights to help you build your framework
  Action Plan
          Your guide to building an Agile framework that fits your organisation

  Feedback


                                                                                     © 2009 IBM Corporation
   2
Building a smarter planet


    Learning objectives and expected takeaways

   Understanding of the critical anti-patterns and scaling factors that
    inhibit scaling Agile within organisations large and small


   Strategies and tactics to overcome challenges faced

                                                               Driving Business
   Action plan to build a flexible Agile framework that fits yourDifferentiation

    organisation




                                                                      © 2009 IBM Corporation
   3
Building a smarter planet




                            © 2009 IBM Corporation
   4
Building a smarter planet


    Our Journey to Agile…




                            © 2009 IBM Corporation
   5
Building a smarter planet


    Was a bit daunting at first…




                                   © 2009 IBM Corporation
   6
Building a smarter planet


    But through Teamwork…




                            © 2009 IBM Corporation
   7
Building a smarter planet


    No Fear of Heights




                            © 2009 IBM Corporation
   8
Building a smarter planet




    And a Clear Focus on Destination




                                       © 2009 IBM Corporation
   9
Building a smarter planet


    We found our way to Success!




                                   © 2009 IBM Corporation
   10
Building a smarter planet


    …and We Proved that Elephants CAN dance!




                                               © 2009 IBM Corporation
   11
Building a smarter planet


    Measuring Improvements…


                                                2006          2011
                               Metric
                                             Measurement   Measurement

                       On Time Delivery          47%           95%

                            Defect Backlog     9+ Months    3.5 months

                  Enhancements Triaged            3%          100%

              Enhancements into Release           1%           21%

                     Customer Sat Index          88%           96%
                Beta Defects Fixed Before
                                                  3%           94%
                           GA
                      % of Agile Projects         5%           78%


                                                                         © 2009 IBM Corporation
   12
Building a smarter planet


 Some of the Challenges IBM faced…


            Complexity Challenges                    Team Challenges
   More granular service functionality       Geographically dispersed teams
    in composite business applications
   Large number of projects and              Effective cross-organizational
    assets (coming from all different          visibility and synchronization,
    sources)                                   sharing becomes an imperative


               Process Challenges                    Tools Challenges
   Blind adherence to process insensitive    Lack of standards impacts ability
                                               to collaborate, automate and report
     to potential business trade-offs          across teams and assumptions
   Need for agility at scale                 Frequent asset updates and
                                               changing interdependencies




                                                                                 © 2009 IBM Corporation
   13
Building a smarter planet


Key Principles We Learned (Inspired by LEAN)




     Eliminate Waste                    Build Quality In             Defer Commitment            Deliver Fast
     • Value Stream Maps                • Foundation Disciplines     Keep options open           Queuing theory
     • Complete Solution                • Continuous Validation




                            Focus on Learning           Respect People            Optimize the Whole
                            Product & process           • Teams                   • Systems thinking
                                                        • Partners                • Set-based design



                                                                                                            © 2009 IBM Corporation
   14
Building a smarter planet


Agile Scaling Factors

                                   Team size                 Compliance requirement
                       Under 10                 1000’s of                                   Critical,
                                                              Low risk
                      developers               developers                                   audited



                        Geographical                                         Domain Complexity
                         distribution                                       Straight                Intricate,
              Co-located              Global                                -forward                emerging

                                                       agility@
              Enterprise discipline
                                                        scale        Organisation distribution
                 Project              Enterprise                    (outsourcing, partnerships)
                  focus                 focus                            Collaborative             Contractual



                    Organisational complexity                   Technical complexity
                        Flexible               Rigid                                   Heterogeneous,
                                                            Homogenous                     legacy




                                                                                                           © 2009 IBM Corporation
   15
Building a smarter planet


    Common anti-patterns

     No support for skills development
           Have you invested in coaching, training and education


     Agile in name only
           Agile adoption is a paradigm shift


     Only focusing on construction
           Have you applied agile practices to the full delivery cycle?


     Thinking that you’re special
           Do you think you can’t become more agile? Interesting




                                                                           © 2009 IBM Corporation
   16
Building a smarter planet


    Scaling Agile - Our point of view

     Each organisation is different and faces a unique set of
      challenges

     A one size fits all approach to adopting Agile practices may not
      be appropriate
     Do what is practical for your team

     The ability to understand and prioritise business objectives and
      track your success in achieving them is key to success

     Your Agile transformation is an ongoing journey that needs
      constant review and refinement


                                                                     © 2009 IBM Corporation
   17
Building a smarter planet




                            © 2009 IBM Corporation
   18
Building a smarter planet


    Reviewing your organisation
 Scaling Factors                               Anti-Patterns
  Our team size is growing/is already large    We have no support for skills
                                                 development
  Our team is distributed geographically
                                                We are Agile in name only
  Enterprise focus is needed, we used to
   get by on focusing on projects               We are only focusing on
                                                 construction
  Our organisational structure is complex
                                                We think we have achieved all
  We have complex compliance                    there is to achieve with Agile
   requirements                                  practices

  Our technical environment is complex

  Our partnering relationships are complex

  Our problem domains are complex



                                                                        © 2009 IBM Corporation
   19
Building a smarter planet




                            © 2009 IBM Corporation
   20
Building a smarter planet


Organisational Adoption: Address the “5Ps” of IT


1.       People
2.       Principles/Philosophies
3.       Practices/Patterns
4.       Products
5.       Process




                                                   © 2009 IBM Corporation
   21
Building a smarter planet




                            © 2009 IBM Corporation
   22
Building a smarter planet


Agile changes your relationship with the business
 Your business and development processes must reflect one another
   – Plans must be high-level with the details coming just in time (JIT)
   – Schedules and estimates must be given in ranges
   – Traditional business approaches will eliminate most benefits of agile

 The new relationship with the customer:
   – They must be actively involved with development all the way through the
     lifecycle
   – The greater visibility and control that they now have implies the need for greater
     accountability on their part
   – They often don’t understand the implications of what they ask for, you need to
     educate them




                                                                             © 2009 IBM Corporation
   23
Building a smarter planet


Agile changes your relationship with the business


 Common problem: Customers don’t want to be actively involved with
  development, not realising that they increase project risk
      – The customer must be involved with development projects on a daily basis
      – The customer must provide information and make decisions in a timely manner



 Suggested strategy:
      – Help your customers to understand what is expected of them and why
      – Customer decision makers need to be coached too
      – Be selective about the projects you apply agile strategies to. If the customer
        isn’t willing to step up then the project isn’t a good choice for agile




                                                                                  © 2009 IBM Corporation
    24
Building a smarter planet


    Pulling it all together with planning & governance
  Treat agile adoption like an agile project
        –   Have a release plan
        –   Have iterations where you deliver something regularly
        –   Demo your results, both successes and failures
        –   Reflect on what you’ve learned and steer the project accordingly




                                                                               © 2009 IBM Corporation
   25
Building a smarter planet


Our Strategy for Agile Transformation

Waves of Change


            Today                                                                                       Future
                                Wave 1                  Wave 2                      Wave 3              Vision
                            Change                        Change                Change
                            Initiative /                  Initiative            Initiative
                            Project

             Introduces 1 or
             more development              Agree Scope     Train, Pilot, Harvest,      Roll out wider      Final Roll Business
             capabilities                  Business Case Package, Test                 scale               out        As Usual
                                           High Level Plan
                                           Define Results
                                                                             Development Projects
             [Best Practices for Transformation]
           Adopt process & tools incrementally in projects
           Support project teams with just-in-time training & mentoring to accelerate learning/adoption
           Demonstrate quick-wins from projects.
           Develop internal SMEs/Mentors who deliver mentoring to project team via CoE/Tools Group




                                                                                                                 © 2009 IBM Corporation
   26
Building a smarter planet


    Five Best Practices for Driving Change



                      Outside-in                  Development
                       Design                      Processes



          Componentization                     Communities
               and                                and
              Reuse                          Community Source

                             Measurements and Reporting


     27
                                                            © 2009 IBM Corporation
Building a smarter planet




    Our Approach for Agile Governance = Managing
    Uncertainty and Managing Variance

   Scope is not a requirements document, it is a continuous negotiation
        Plans/Resource estimates
        Scope
        Product features/quality




   A plan is not a prescription, it is an evolving,
    moving target                                                              Uncertainty in
                                                                                Stakeholder
                                                                             Satisfaction Space




           Initial State                                                     Initial Plan
                                   Actual path and precision of Scope/Plan



                                                                                  © 2009 IBM Corporation
   28
Kick off




29
                                                     Initial release planning


                                                  Indentify assets for reuse /
                                                 sourcing (incl. documentation)




                                                                                   Warm-up




                          2-6 weeks
                                                                                                                                                      Building a smarter planet




                                                    High level architecture
                                                   Requirement confirmation
                                                                                                    release
                                                     sprint planning


                                                   Develop and stabilize
                                                                                   Sprint1




                          2-4 weeks
                                                                                                              Demo




                                                          plan
                                                       sprint planning
                                                                                                            Sign-off
                                                                                                          Retrospective
                                                                                                                          Project Timeline Template




                                                   Develop and stabilize
                                                                                  Sprint 2




                          2-4 weeks
                                                                                                              Demo




                                                       sprint planning
                                                                                                            Sign-off




                                      On going
                                                                                                          Retrospective



                                                                                …




                                                   Develop and stabilize
                          2-4 weeks




                                                         stabilize
                                                                                                              Demo




                                                    Finalise release testing
                                                                                                            Sign-off
                                                                                                          Retrospective




                                                       Hand  -over assets
                                                     (incl. documentation)
                                                   Technical implementation
                          2-4 weeks




                                                    Roll
                                                       -out organisational
                                                                                   Implementation




                                                       implementation
                                                                                                          Sign-off




 © 2009 IBM Corporation
Building a smarter planet


But What Should We Measure?
An Example Set of Candidate Agile Metrics..lots of
possibilities!
                                                      Executive Dashboard

         Project Health                Customer Quality               Development Quality            Strategic Health
       Defect Backlog                 Transactional Survey         Defect Backlog
                                                                                                     Sales Plays
       Defect Density                 PMR / Call Rates             Test Escapes
                                                                                                     Partner Enablement
       Defect Repair Latency          Critical Situations          Functional Test Trends
                                                                     Critical Situations
                                                                                                     Support Enablement
       Build Health                   Cost of Support
                                                                     System Test Trends             Technical Enablement
       Project Velocity               Installability
                                                                     S-Curve Progress               Sales Enablement
       Staffing Actuals               Enhancement SLA              Automation Percentage          Localization
       Process Timeliness             Useability                                                   MCIF Index
       Milestone Status               Consumability                Customer Testcases             Competition
       Severity Analysis              Perceived Performance                                        Integrated into Story
       Security Vulnerabilities       Scalability                  Consumability Scorecard        Green Threads
       Static Code Analysis           Integrations with other                                      LCM
       Requirements Met                products                     Defect Latency
                                                                                                     Pipeline / Multiplier
       IPD Timeliness                 User Experience / Doc        Quality Plan Commitments
                                                                     Test Coverage
                                                                                                     Revenue
                                        Time to Resolution
   Evolutionary Architecture
            Vulnerability Assessment                    Practices
                                                             Test Driven Development
                                                       Whole Team
      Concurrent Testing           Requirements Management      Team Change Management



                                                                                                                © 2009 IBM Corporation
   30
Building a smarter planet




    Measures Help Answer Key Questions
                Business-Related          IT-Related             Agile-Related
                Measures                  Measures               Measures
                                             Appropriate level
                   Projects deliver          of management         Agile practice
                   faster than today         and analysis          adoption
                                             activities

 Are we meeting
          Projects deliver             Are we seeing
                                            Efficient change             Are we agile?
                                                                   Agile role
          with lower overall
 business cost than today              the benefit
                                            request process        adoption


 objectives? created
          Systems
                                       where we
                                            Efficient
                                                                   Agile work
                                            requirements
                   or updated in the
                   projects have the
                                       expected?
                                            definition and
                                                                   product
                                                                   adoption
                   agreed quality            signoff

                   The development           Fewer breakages
                   organisation is a         when solution         Agile task
                   learning                  elements are          adoption
                   organisation              integrated



                  Employee                  Less “solution        Agile process
                  satisfaction              hardening” needed     adoption




                                                                                    © 2009 IBM Corporation
   31
Building a smarter planet


    Key Project Performance Metrics: Agile View
                                                                             (all reported by common reporting period)

                                     Delivery Rate vs. Plan                                                                         Scope Change Rate
                                     Burndown/Velocity                                                                                  (Add, Modify, Remove)
        t 140
        h
                                                                                       120%
                                                                                                 t 160
        g                                                                                        h
        i 120                                                                          100%      g
                                                                                                 i 140
        e                                                                                        e
        W 100                                                                                    W 120
        y                                                                              80%       y
        b                                                                                        b 100
        s 80                                                                                     s
        e                                                                                        e
                                                                                                 r
        r                                                                              60%       u 80
        u
        t 60                                                                                     t
                                                                                                 a
        a
        e                                                                              40%
                                                                                                 e 60
                                                                                                 F
        F 40                                                                                     e
                                                                                                 t
        e
        t                                                                                        a 40
                                                                                                 g
        a                                                                              20%
        g 20                                                                                     e
                                                                                                 r 20
        e
        r                                                                                        g
                                                                                                 g
        g
        g   0                                                                          0%        A   0
        A
                   1    2    3       4    6   5 7   8    9 10 11 12 13                                      1       2       3       4      5    6    7     8    9   10   11   12   13
                                        Reporting Period                                                                                  Reporting Period
         Velocity: Plan – – – Optimistic – – – Best Guess – – % Pessimistic – – –
             Planned Features        Delivered Features       – of Plan To-Date                          Baseline Features              Added / Modified Features   Removed Features
         Actual Burndown (Features Remaining)                 Delivered in Period


                         Delivery / Labor Cost Performance                                                                      Integration Test Quality
        350%                                                                                        140%
                                                                                                                                        (High Severity Defects)
        300%                                                                                        120%
        250%                                                                                        100%
        200%                                                                                         80%
        150%                                                                                         60%
        100%                                                                                         40%
         50%                                                                                         20%
          0%                                                                                          0%
                    1    2       3       4      5     6    7    8   9   10   11   12   13                       1       2       3     5 4  6     7    8    9    10 11 12            13
                                                                                                                                      Reporting Period
                                              Reporting Period
                                                                                                                % Defects Open                        Defect / Test Run Ratio
                % of Plan To-Date            % of Plan Spend Rate   Cost EAC % Projection
                                                                                                                % Test Cases Run In Period            Feature / Test Run Ratio


   This is a sample view. Metrics can take different forms. The intent is ensure that the
          charts address core management concerns and associated questions.


                                                                                                                                                                                         © 2009 IBM Corporation
   32
Building a smarter planet


    Agile Performance Metrics: Core Answers
                                                                             (all reported by common reporting period)

                                     Delivery Rate vs. Plan                                                                         Scope Change Rate
                                     Burndown/Velocity                                                                                  (Add, Modify, Remove)
        t 140
        h
                                                                                       120%        Are scope changes
                                                                                                 t 160
        g 120                                                                                    h
        i
        e                                         Are we on schedule?                  100%      g
                                                                                                 i 140
                                                                                                 e overwhelming our
        W 100                                     If not, how far behind?                        W 120
        y
        b                                                                              80%       y ability to deliver?
                                                                                                 b 100
                                                                                                 s
        s 80
        e
        r
                                                  When will we complete?               60%
                                                                                                 e
                                                                                                 r
        u 60                                                                                     u 80
                                                                                                 t
        t                                                                                        a
        a
        e                                                                              40%
                                                                                                 e
                                                                                                 F 60
        F 40                                                                                     e
                                                                                                 t 40
        e
        t                                                                                        a
        a 20                                                                           20%       g
        g                                                                                        e 20
                                                                                                 r
        e
        r                                                                                        g
                                                                                                 g
        g
        g   0                                                                          0%        A   0
        A
                   1    2    3       4    6   57    8   9 10 11 12 13                                       1       2       3       4      5    6    7     8    9   10   11   12   13
                                       Reporting Period                                                                                   Reporting Period
         Velocity: Plan – – – Optimistic – – – Best Guess – – % of Plan To-Date –
             Planned Features       Delivered Features        – Pessimistic – –                          Baseline Features              Added / Modified Features   Removed Features
         Actual Burndown (Features Remaining)                 Delivered in Period


                         Delivery / Labor Cost Performance                                                                      Integration Test Quality
        350%                                                                                        140%
                                                                                                                                        (High Severity Defects)
        300%                                       Are our estimates good?                          120%                                           Do we have enough test coverage and
        250%                                       Do we have enough staff ?                        100%                                           execution?
        200%                                       What will it take to complete?                    80%                                           Is the quality of our deliveries good
        150%                                                                                         60%
                                                                                                                                                   enough?
        100%                                                                                         40%
         50%                                                                                         20%
          0%                                                                                          0%
                    1    2       3       4      5     6    7    8   9   10   11   12   13                       1       2       3     5 4  6     7    8    9    10 11 12            13
                                                                                                                                      Reporting Period
                                              Reporting Period
                                                                                                                % Defects Open                        Defect / Test Run Ratio
                % of Plan To-Date            % of Plan Spend Rate   Cost EAC % Projection
                                                                                                                % Test Cases Run In Period            Feature / Test Run Ratio



   Here are the key management questions answered by each chart. An inability to answer
                any of these questions serves as a source of fundamental risk.


                                                                                                                                                                                         © 2009 IBM Corporation
   33
Building a smarter planet




                            © 2009 IBM Corporation
   34
Building an Agile framework that fits your organisation
Building a smarter planet




                            © 2009 IBM Corporation
   36
Building a smarter planet




                            © 2009 IBM Corporation
   37
Building a smarter planet


    Addressing the scaling factors




                                     © 2009 IBM Corporation
   38
Building a smarter planet


    Addressing the scaling factors




                                     © 2009 IBM Corporation
   39
Building a smarter planet


    Addressing the scaling factors




                                     © 2009 IBM Corporation
   40
Building a smarter planet


    Addressing the scaling factors




                                     © 2009 IBM Corporation
   41
Building a smarter planet


    Addressing the scaling factors




                                     © 2009 IBM Corporation
   42
Building a smarter planet


    Addressing the scaling factors




                                     © 2009 IBM Corporation
   43
Building a smarter planet


    Addressing the scaling factors




                                     © 2009 IBM Corporation
   44
Building a smarter planet


    Addressing the scaling factors




                                     © 2009 IBM Corporation
   45
Building a smarter planet


    Addressing the anti patterns




                                   © 2009 IBM Corporation
   46
Building a smarter planet


    Addressing the anti patterns




                                   © 2009 IBM Corporation
   47
Building a smarter planet


    Addressing the anti patterns




                                   © 2009 IBM Corporation
   48
Building a smarter planet


    Addressing the anti patterns




                                   © 2009 IBM Corporation
   49
Building a smarter planet


    The roles have changed, so must you


 Traditional roles:           Agile roles:
   –Analyst                      –Stakeholder/Customer
   –Architect                    –Team Lead/Scrum Master
   –Database Administrator
   –Designer                     –Product Owner
   –Developer                    –Agile Team Member
   –Product Manager              –Architecture Owner
   –Project Manager
   –Quality Assurance (QA)
   –Tester



                                                   © 2009 IBM Corporation
   50
Building a smarter planet


    Agile Coaches
 Good agile coaches
    – Have deep experience in agile
    – Have good interpersonal skills
    – Are respected by their teams based on merit, not on positional status
    – Are actively involved with the team(s) that they are mentoring, but don’t dominate them
    – Create an environment where people collaborate and learn together
 Role and responsibilities of an agile coach
    – Provide advice to the team
    – Provide opportunities for people to learn, even through mistakes
    – Pair with the people they are coaching to provide detailed mentoring
    – Help teams to solve problems
    – Negotiate conflicts within the team
    – Promote self organization and self discipline within the team
    – Help the team to understand and meet their improvement goals
 “Growing” your coaches
    – 1 experienced coach can coach two teams (10 people each) on one project at a time.
      While doing so, they can also develop one agile coach with each team.
    – Senior coaches can develop coaches in about 3 months, but typically it takes 6 months
      to develop new coaches


                                                                                    © 2009 IBM Corporation
   51
Building a smarter planet


    Agile Champions

 Good agile champions
   – Understand the fundamentals of agile
   – Understand how to apply agile at scale
   – Understand enterprise-level implications of agile
   – Are respected by agile teams based on their merit, not positional status
   – Create an environment where agile teams are given the resources to succeed

 Role and responsibilities of agile champions
   – Support the agile coaches
   – Work closely with the business to help them understand and shift to agile
   – Work closely with IT senior management to help them understand and adopt agile
   – Communicate to the organization the current status of the agile adoption, successes, …
   – Help promote communication between the agile coaches and teams
   – Promote and defend agile approach in their LoB
   – Use collected results to show value




                                                                                  © 2009 IBM Corporation
   52

More Related Content

What's hot (20)

Introduction To Agile
Introduction To AgileIntroduction To Agile
Introduction To Agile
 
Scrum best practices
Scrum best practicesScrum best practices
Scrum best practices
 
Agile Methodology ppt
Agile Methodology pptAgile Methodology ppt
Agile Methodology ppt
 
Agile Scrum Overview
Agile  Scrum  OverviewAgile  Scrum  Overview
Agile Scrum Overview
 
Agile
AgileAgile
Agile
 
Scrum In 15 Minutes
Scrum In 15 MinutesScrum In 15 Minutes
Scrum In 15 Minutes
 
Agile
Agile Agile
Agile
 
Agile software development
Agile software developmentAgile software development
Agile software development
 
Overview of Agile Methodology
Overview of Agile MethodologyOverview of Agile Methodology
Overview of Agile Methodology
 
Agile scrum fundamentals
Agile scrum fundamentalsAgile scrum fundamentals
Agile scrum fundamentals
 
Agile Project Management
Agile Project ManagementAgile Project Management
Agile Project Management
 
Scrum and Agile SDLC 101
Scrum and Agile SDLC 101Scrum and Agile SDLC 101
Scrum and Agile SDLC 101
 
Agile project management using scrum
Agile project management using scrumAgile project management using scrum
Agile project management using scrum
 
Scrum Process
Scrum ProcessScrum Process
Scrum Process
 
Agile Methodology - Agile Project Management Training
Agile Methodology - Agile Project Management TrainingAgile Methodology - Agile Project Management Training
Agile Methodology - Agile Project Management Training
 
Scrum in an hour
Scrum in an hourScrum in an hour
Scrum in an hour
 
Agile & Scrum Training
Agile & Scrum TrainingAgile & Scrum Training
Agile & Scrum Training
 
Agile Project Management - An introduction to Agile and the new PMI-ACP
Agile Project Management - An introduction to Agile and the new PMI-ACPAgile Project Management - An introduction to Agile and the new PMI-ACP
Agile Project Management - An introduction to Agile and the new PMI-ACP
 
Introduction To Scrum
Introduction To ScrumIntroduction To Scrum
Introduction To Scrum
 
Scaling Agile With SAFe (Scaled Agile Framework)
Scaling Agile With SAFe (Scaled Agile Framework)Scaling Agile With SAFe (Scaled Agile Framework)
Scaling Agile With SAFe (Scaled Agile Framework)
 

Viewers also liked

IBM Studios: The Journey Home (Telstra Design Conference 2015)
IBM Studios: The Journey Home (Telstra Design Conference 2015)IBM Studios: The Journey Home (Telstra Design Conference 2015)
IBM Studios: The Journey Home (Telstra Design Conference 2015)Kurt Solarte
 
Lean Business Intelligence: Achieve Better, Faster, Cheaper Business Intellig...
Lean Business Intelligence: Achieve Better, Faster, Cheaper Business Intellig...Lean Business Intelligence: Achieve Better, Faster, Cheaper Business Intellig...
Lean Business Intelligence: Achieve Better, Faster, Cheaper Business Intellig...Kurt Solarte
 
Breaking down agile requirements in Agile Methodology
Breaking down agile requirements in Agile MethodologyBreaking down agile requirements in Agile Methodology
Breaking down agile requirements in Agile MethodologyMario Lucero
 
Achieving the Full Potential of Your Distributed Agile Team (AgileAus 2013)
Achieving the Full Potential of Your Distributed Agile Team (AgileAus 2013)Achieving the Full Potential of Your Distributed Agile Team (AgileAus 2013)
Achieving the Full Potential of Your Distributed Agile Team (AgileAus 2013)Kurt Solarte
 
How to Organize a User Story Writing Workshop
How to Organize a User Story Writing WorkshopHow to Organize a User Story Writing Workshop
How to Organize a User Story Writing WorkshopJeff Lopez-Stuit
 
Agile Requirements Writing
Agile Requirements WritingAgile Requirements Writing
Agile Requirements WritingBernhard Kappe
 
Disruption isn't Digital (Digital strategy Summit Sydney 2015 Keynote)
Disruption isn't Digital (Digital strategy Summit Sydney 2015 Keynote)Disruption isn't Digital (Digital strategy Summit Sydney 2015 Keynote)
Disruption isn't Digital (Digital strategy Summit Sydney 2015 Keynote)Kurt Solarte
 
Agile Requirements Decomposition
Agile Requirements DecompositionAgile Requirements Decomposition
Agile Requirements DecompositionRick Austin
 
Disruptive Incumbents (Daze of Disruption 2015)
Disruptive Incumbents (Daze of Disruption 2015)Disruptive Incumbents (Daze of Disruption 2015)
Disruptive Incumbents (Daze of Disruption 2015)Kurt Solarte
 
User Story Mapping Workshop (Design Skills 2016)
User Story Mapping Workshop (Design Skills 2016)User Story Mapping Workshop (Design Skills 2016)
User Story Mapping Workshop (Design Skills 2016)Bartosz Mozyrko
 
Managing Requirements in Agile Development - Best Practices for Tool-Based Re...
Managing Requirements in Agile Development - Best Practices for Tool-Based Re...Managing Requirements in Agile Development - Best Practices for Tool-Based Re...
Managing Requirements in Agile Development - Best Practices for Tool-Based Re...pd7.group
 
Writing Agile Requirements
Writing  Agile  RequirementsWriting  Agile  Requirements
Writing Agile RequirementsRobert Dempsey
 

Viewers also liked (13)

IBM Studios: The Journey Home (Telstra Design Conference 2015)
IBM Studios: The Journey Home (Telstra Design Conference 2015)IBM Studios: The Journey Home (Telstra Design Conference 2015)
IBM Studios: The Journey Home (Telstra Design Conference 2015)
 
Lean Business Intelligence: Achieve Better, Faster, Cheaper Business Intellig...
Lean Business Intelligence: Achieve Better, Faster, Cheaper Business Intellig...Lean Business Intelligence: Achieve Better, Faster, Cheaper Business Intellig...
Lean Business Intelligence: Achieve Better, Faster, Cheaper Business Intellig...
 
Breaking down agile requirements in Agile Methodology
Breaking down agile requirements in Agile MethodologyBreaking down agile requirements in Agile Methodology
Breaking down agile requirements in Agile Methodology
 
Achieving the Full Potential of Your Distributed Agile Team (AgileAus 2013)
Achieving the Full Potential of Your Distributed Agile Team (AgileAus 2013)Achieving the Full Potential of Your Distributed Agile Team (AgileAus 2013)
Achieving the Full Potential of Your Distributed Agile Team (AgileAus 2013)
 
How to Organize a User Story Writing Workshop
How to Organize a User Story Writing WorkshopHow to Organize a User Story Writing Workshop
How to Organize a User Story Writing Workshop
 
Agile Requirements Writing
Agile Requirements WritingAgile Requirements Writing
Agile Requirements Writing
 
Disruption isn't Digital (Digital strategy Summit Sydney 2015 Keynote)
Disruption isn't Digital (Digital strategy Summit Sydney 2015 Keynote)Disruption isn't Digital (Digital strategy Summit Sydney 2015 Keynote)
Disruption isn't Digital (Digital strategy Summit Sydney 2015 Keynote)
 
Agile Requirements Decomposition
Agile Requirements DecompositionAgile Requirements Decomposition
Agile Requirements Decomposition
 
Epics and User Stories
Epics and User StoriesEpics and User Stories
Epics and User Stories
 
Disruptive Incumbents (Daze of Disruption 2015)
Disruptive Incumbents (Daze of Disruption 2015)Disruptive Incumbents (Daze of Disruption 2015)
Disruptive Incumbents (Daze of Disruption 2015)
 
User Story Mapping Workshop (Design Skills 2016)
User Story Mapping Workshop (Design Skills 2016)User Story Mapping Workshop (Design Skills 2016)
User Story Mapping Workshop (Design Skills 2016)
 
Managing Requirements in Agile Development - Best Practices for Tool-Based Re...
Managing Requirements in Agile Development - Best Practices for Tool-Based Re...Managing Requirements in Agile Development - Best Practices for Tool-Based Re...
Managing Requirements in Agile Development - Best Practices for Tool-Based Re...
 
Writing Agile Requirements
Writing  Agile  RequirementsWriting  Agile  Requirements
Writing Agile Requirements
 

Similar to Building an Agile framework that fits your organisation

Real insights real_results-steve_robinson
Real insights real_results-steve_robinsonReal insights real_results-steve_robinson
Real insights real_results-steve_robinsonIBM
 
Real Insights Real Results - Steve Robinson
Real Insights Real Results - Steve RobinsonReal Insights Real Results - Steve Robinson
Real Insights Real Results - Steve RobinsonRoopa Nadkarni
 
Real insights real_results-steve_robinson
Real insights real_results-steve_robinsonReal insights real_results-steve_robinson
Real insights real_results-steve_robinsonIBM
 
The Agile PMO: Ensuring visibility and governance
The Agile PMO: Ensuring visibility and governanceThe Agile PMO: Ensuring visibility and governance
The Agile PMO: Ensuring visibility and governanceMatt Holitza
 
The Agile Scaling Model (ASM): Be as Agile as You Need to Be
The Agile Scaling Model (ASM): Be as Agile as You Need to BeThe Agile Scaling Model (ASM): Be as Agile as You Need to Be
The Agile Scaling Model (ASM): Be as Agile as You Need to BeAgile Software Community of India
 
Estimation Agile Projects
Estimation Agile ProjectsEstimation Agile Projects
Estimation Agile ProjectsRam Srivastava
 
Smarter Computing Integrated Systems
Smarter Computing Integrated SystemsSmarter Computing Integrated Systems
Smarter Computing Integrated SystemsIBMGovernmentCA
 
Scaling agile scrum practices 2.0
Scaling agile   scrum practices 2.0Scaling agile   scrum practices 2.0
Scaling agile scrum practices 2.0Reedy Feggins Jr
 
A very long engagement
A very long engagementA very long engagement
A very long engagementSkills Matter
 
Agile Marketing for SEO - SMX West 2013 - Dave Lloyd, Adobe
Agile Marketing for SEO - SMX West 2013 - Dave Lloyd, AdobeAgile Marketing for SEO - SMX West 2013 - Dave Lloyd, Adobe
Agile Marketing for SEO - SMX West 2013 - Dave Lloyd, AdobeDave Lloyd
 
Building the Agile Enterprise
Building the Agile EnterpriseBuilding the Agile Enterprise
Building the Agile EnterpriseSrini Koushik
 
From Waterfall to Agile - from predictive to adaptive methods
From Waterfall to Agile - from predictive to adaptive methodsFrom Waterfall to Agile - from predictive to adaptive methods
From Waterfall to Agile - from predictive to adaptive methodsBjörn Jónsson
 
Open Source Maturity Curve and Ecosystem
Open Source Maturity Curve and EcosystemOpen Source Maturity Curve and Ecosystem
Open Source Maturity Curve and Ecosystemguest239f177
 
Making Life Simple: Plug and Play Enterprise Computing
Making Life Simple: Plug and Play Enterprise ComputingMaking Life Simple: Plug and Play Enterprise Computing
Making Life Simple: Plug and Play Enterprise ComputingGen-i
 
IBM PureSystems - a ground breaking new family of Expert Integrated Systems.
IBM PureSystems - a ground breaking new family of Expert Integrated Systems.IBM PureSystems - a ground breaking new family of Expert Integrated Systems.
IBM PureSystems - a ground breaking new family of Expert Integrated Systems.Gen-i
 
Presentation 20111102
Presentation 20111102Presentation 20111102
Presentation 20111102dgarlough
 
PCTY 2012, Developing for Mobile Enterprise Application Platform v. Peter Eibak
PCTY 2012, Developing for Mobile Enterprise Application Platform v. Peter EibakPCTY 2012, Developing for Mobile Enterprise Application Platform v. Peter Eibak
PCTY 2012, Developing for Mobile Enterprise Application Platform v. Peter EibakIBM Danmark
 
Rational collaborative-lifecycle-management-2012
Rational collaborative-lifecycle-management-2012Rational collaborative-lifecycle-management-2012
Rational collaborative-lifecycle-management-2012Strongback Consulting
 

Similar to Building an Agile framework that fits your organisation (20)

Real insights real_results-steve_robinson
Real insights real_results-steve_robinsonReal insights real_results-steve_robinson
Real insights real_results-steve_robinson
 
Real Insights Real Results - Steve Robinson
Real Insights Real Results - Steve RobinsonReal Insights Real Results - Steve Robinson
Real Insights Real Results - Steve Robinson
 
Real insights real_results-steve_robinson
Real insights real_results-steve_robinsonReal insights real_results-steve_robinson
Real insights real_results-steve_robinson
 
The Agile PMO: Ensuring visibility and governance
The Agile PMO: Ensuring visibility and governanceThe Agile PMO: Ensuring visibility and governance
The Agile PMO: Ensuring visibility and governance
 
The Agile Scaling Model (ASM): Be as Agile as You Need to Be
The Agile Scaling Model (ASM): Be as Agile as You Need to BeThe Agile Scaling Model (ASM): Be as Agile as You Need to Be
The Agile Scaling Model (ASM): Be as Agile as You Need to Be
 
Estimation Agile Projects
Estimation Agile ProjectsEstimation Agile Projects
Estimation Agile Projects
 
Smarter Computing Integrated Systems
Smarter Computing Integrated SystemsSmarter Computing Integrated Systems
Smarter Computing Integrated Systems
 
Business value of Agile : A People10 Showcase
Business value of Agile : A People10 ShowcaseBusiness value of Agile : A People10 Showcase
Business value of Agile : A People10 Showcase
 
Scaling agile scrum practices 2.0
Scaling agile   scrum practices 2.0Scaling agile   scrum practices 2.0
Scaling agile scrum practices 2.0
 
A very long engagement
A very long engagementA very long engagement
A very long engagement
 
Agile Marketing for SEO - SMX West 2013 - Dave Lloyd, Adobe
Agile Marketing for SEO - SMX West 2013 - Dave Lloyd, AdobeAgile Marketing for SEO - SMX West 2013 - Dave Lloyd, Adobe
Agile Marketing for SEO - SMX West 2013 - Dave Lloyd, Adobe
 
Building the Agile Enterprise
Building the Agile EnterpriseBuilding the Agile Enterprise
Building the Agile Enterprise
 
From Waterfall to Agile - from predictive to adaptive methods
From Waterfall to Agile - from predictive to adaptive methodsFrom Waterfall to Agile - from predictive to adaptive methods
From Waterfall to Agile - from predictive to adaptive methods
 
Open Source Maturity Curve and Ecosystem
Open Source Maturity Curve and EcosystemOpen Source Maturity Curve and Ecosystem
Open Source Maturity Curve and Ecosystem
 
Introduction to Lean, Agile, Scrum, & XP
Introduction to Lean, Agile, Scrum, & XPIntroduction to Lean, Agile, Scrum, & XP
Introduction to Lean, Agile, Scrum, & XP
 
Making Life Simple: Plug and Play Enterprise Computing
Making Life Simple: Plug and Play Enterprise ComputingMaking Life Simple: Plug and Play Enterprise Computing
Making Life Simple: Plug and Play Enterprise Computing
 
IBM PureSystems - a ground breaking new family of Expert Integrated Systems.
IBM PureSystems - a ground breaking new family of Expert Integrated Systems.IBM PureSystems - a ground breaking new family of Expert Integrated Systems.
IBM PureSystems - a ground breaking new family of Expert Integrated Systems.
 
Presentation 20111102
Presentation 20111102Presentation 20111102
Presentation 20111102
 
PCTY 2012, Developing for Mobile Enterprise Application Platform v. Peter Eibak
PCTY 2012, Developing for Mobile Enterprise Application Platform v. Peter EibakPCTY 2012, Developing for Mobile Enterprise Application Platform v. Peter Eibak
PCTY 2012, Developing for Mobile Enterprise Application Platform v. Peter Eibak
 
Rational collaborative-lifecycle-management-2012
Rational collaborative-lifecycle-management-2012Rational collaborative-lifecycle-management-2012
Rational collaborative-lifecycle-management-2012
 

More from Kurt Solarte

Designing for the Experience of Augmented Intelligence (Internet Economy Summ...
Designing for the Experience of Augmented Intelligence (Internet Economy Summ...Designing for the Experience of Augmented Intelligence (Internet Economy Summ...
Designing for the Experience of Augmented Intelligence (Internet Economy Summ...Kurt Solarte
 
Agile Sales! Is that a Thing?
Agile Sales! Is that a Thing?Agile Sales! Is that a Thing?
Agile Sales! Is that a Thing?Kurt Solarte
 
Is Agile Documentation An Oxymoron?
Is Agile Documentation An Oxymoron?Is Agile Documentation An Oxymoron?
Is Agile Documentation An Oxymoron?Kurt Solarte
 
IBM Next Gen ALM 2012
IBM Next Gen ALM 2012IBM Next Gen ALM 2012
IBM Next Gen ALM 2012Kurt Solarte
 
Agile - Transforming Small Team Thinking Into Big Business Results
Agile - Transforming Small Team Thinking Into Big Business ResultsAgile - Transforming Small Team Thinking Into Big Business Results
Agile - Transforming Small Team Thinking Into Big Business ResultsKurt Solarte
 
Agile Requirements by Agile Analysts
Agile Requirements by Agile AnalystsAgile Requirements by Agile Analysts
Agile Requirements by Agile AnalystsKurt Solarte
 
Organizing Design-Driven Development Using Rational Requirements Composer
Organizing Design-Driven Development Using Rational Requirements ComposerOrganizing Design-Driven Development Using Rational Requirements Composer
Organizing Design-Driven Development Using Rational Requirements ComposerKurt Solarte
 
Does Agile Analysis Require a Business Analyst?
Does Agile Analysis Require a Business Analyst?Does Agile Analysis Require a Business Analyst?
Does Agile Analysis Require a Business Analyst?Kurt Solarte
 
Optimising and prioritising your SDLC using business intelligence
Optimising and prioritising your SDLC using business intelligenceOptimising and prioritising your SDLC using business intelligence
Optimising and prioritising your SDLC using business intelligenceKurt Solarte
 
Does Agile Analysis Require a Business Analyst?
Does Agile Analysis Require a Business Analyst?Does Agile Analysis Require a Business Analyst?
Does Agile Analysis Require a Business Analyst?Kurt Solarte
 

More from Kurt Solarte (10)

Designing for the Experience of Augmented Intelligence (Internet Economy Summ...
Designing for the Experience of Augmented Intelligence (Internet Economy Summ...Designing for the Experience of Augmented Intelligence (Internet Economy Summ...
Designing for the Experience of Augmented Intelligence (Internet Economy Summ...
 
Agile Sales! Is that a Thing?
Agile Sales! Is that a Thing?Agile Sales! Is that a Thing?
Agile Sales! Is that a Thing?
 
Is Agile Documentation An Oxymoron?
Is Agile Documentation An Oxymoron?Is Agile Documentation An Oxymoron?
Is Agile Documentation An Oxymoron?
 
IBM Next Gen ALM 2012
IBM Next Gen ALM 2012IBM Next Gen ALM 2012
IBM Next Gen ALM 2012
 
Agile - Transforming Small Team Thinking Into Big Business Results
Agile - Transforming Small Team Thinking Into Big Business ResultsAgile - Transforming Small Team Thinking Into Big Business Results
Agile - Transforming Small Team Thinking Into Big Business Results
 
Agile Requirements by Agile Analysts
Agile Requirements by Agile AnalystsAgile Requirements by Agile Analysts
Agile Requirements by Agile Analysts
 
Organizing Design-Driven Development Using Rational Requirements Composer
Organizing Design-Driven Development Using Rational Requirements ComposerOrganizing Design-Driven Development Using Rational Requirements Composer
Organizing Design-Driven Development Using Rational Requirements Composer
 
Does Agile Analysis Require a Business Analyst?
Does Agile Analysis Require a Business Analyst?Does Agile Analysis Require a Business Analyst?
Does Agile Analysis Require a Business Analyst?
 
Optimising and prioritising your SDLC using business intelligence
Optimising and prioritising your SDLC using business intelligenceOptimising and prioritising your SDLC using business intelligence
Optimising and prioritising your SDLC using business intelligence
 
Does Agile Analysis Require a Business Analyst?
Does Agile Analysis Require a Business Analyst?Does Agile Analysis Require a Business Analyst?
Does Agile Analysis Require a Business Analyst?
 

Building an Agile framework that fits your organisation

  • 1. ork ile fr amew ga n Ag ation Bu ildin r :org anis sreyenurs ip p s o te akt hfo t h tWor s rt Sola rte r Ku and Rick Weave 2 May 201 th ay 29 Tuesd
  • 2. Building a smarter planet Agenda  Welcome and introductions  Activity  Learning from IBM’s transformation to agility@scale  Anti-patterns and scaling factors to look for  Addressing the 5 Ps of IT Driving Business  Activity Differentiation  Insights to help you build your framework  Action Plan  Your guide to building an Agile framework that fits your organisation  Feedback © 2009 IBM Corporation 2
  • 3. Building a smarter planet Learning objectives and expected takeaways  Understanding of the critical anti-patterns and scaling factors that inhibit scaling Agile within organisations large and small  Strategies and tactics to overcome challenges faced Driving Business  Action plan to build a flexible Agile framework that fits yourDifferentiation organisation © 2009 IBM Corporation 3
  • 4. Building a smarter planet © 2009 IBM Corporation 4
  • 5. Building a smarter planet Our Journey to Agile… © 2009 IBM Corporation 5
  • 6. Building a smarter planet Was a bit daunting at first… © 2009 IBM Corporation 6
  • 7. Building a smarter planet But through Teamwork… © 2009 IBM Corporation 7
  • 8. Building a smarter planet No Fear of Heights © 2009 IBM Corporation 8
  • 9. Building a smarter planet And a Clear Focus on Destination © 2009 IBM Corporation 9
  • 10. Building a smarter planet We found our way to Success! © 2009 IBM Corporation 10
  • 11. Building a smarter planet …and We Proved that Elephants CAN dance! © 2009 IBM Corporation 11
  • 12. Building a smarter planet Measuring Improvements… 2006 2011 Metric Measurement Measurement On Time Delivery 47% 95% Defect Backlog 9+ Months 3.5 months Enhancements Triaged 3% 100% Enhancements into Release 1% 21% Customer Sat Index 88% 96% Beta Defects Fixed Before 3% 94% GA % of Agile Projects 5% 78% © 2009 IBM Corporation 12
  • 13. Building a smarter planet Some of the Challenges IBM faced… Complexity Challenges Team Challenges  More granular service functionality  Geographically dispersed teams in composite business applications  Large number of projects and  Effective cross-organizational assets (coming from all different visibility and synchronization, sources) sharing becomes an imperative Process Challenges Tools Challenges  Blind adherence to process insensitive  Lack of standards impacts ability to collaborate, automate and report to potential business trade-offs across teams and assumptions  Need for agility at scale  Frequent asset updates and changing interdependencies © 2009 IBM Corporation 13
  • 14. Building a smarter planet Key Principles We Learned (Inspired by LEAN) Eliminate Waste Build Quality In Defer Commitment Deliver Fast • Value Stream Maps • Foundation Disciplines Keep options open Queuing theory • Complete Solution • Continuous Validation Focus on Learning Respect People Optimize the Whole Product & process • Teams • Systems thinking • Partners • Set-based design © 2009 IBM Corporation 14
  • 15. Building a smarter planet Agile Scaling Factors Team size Compliance requirement Under 10 1000’s of Critical, Low risk developers developers audited Geographical Domain Complexity distribution Straight Intricate, Co-located Global -forward emerging agility@ Enterprise discipline scale Organisation distribution Project Enterprise (outsourcing, partnerships) focus focus Collaborative Contractual Organisational complexity Technical complexity Flexible Rigid Heterogeneous, Homogenous legacy © 2009 IBM Corporation 15
  • 16. Building a smarter planet Common anti-patterns No support for skills development Have you invested in coaching, training and education Agile in name only Agile adoption is a paradigm shift Only focusing on construction Have you applied agile practices to the full delivery cycle? Thinking that you’re special Do you think you can’t become more agile? Interesting © 2009 IBM Corporation 16
  • 17. Building a smarter planet Scaling Agile - Our point of view  Each organisation is different and faces a unique set of challenges  A one size fits all approach to adopting Agile practices may not be appropriate  Do what is practical for your team  The ability to understand and prioritise business objectives and track your success in achieving them is key to success  Your Agile transformation is an ongoing journey that needs constant review and refinement © 2009 IBM Corporation 17
  • 18. Building a smarter planet © 2009 IBM Corporation 18
  • 19. Building a smarter planet Reviewing your organisation Scaling Factors Anti-Patterns  Our team size is growing/is already large  We have no support for skills development  Our team is distributed geographically  We are Agile in name only  Enterprise focus is needed, we used to get by on focusing on projects  We are only focusing on construction  Our organisational structure is complex  We think we have achieved all  We have complex compliance there is to achieve with Agile requirements practices  Our technical environment is complex  Our partnering relationships are complex  Our problem domains are complex © 2009 IBM Corporation 19
  • 20. Building a smarter planet © 2009 IBM Corporation 20
  • 21. Building a smarter planet Organisational Adoption: Address the “5Ps” of IT 1. People 2. Principles/Philosophies 3. Practices/Patterns 4. Products 5. Process © 2009 IBM Corporation 21
  • 22. Building a smarter planet © 2009 IBM Corporation 22
  • 23. Building a smarter planet Agile changes your relationship with the business  Your business and development processes must reflect one another – Plans must be high-level with the details coming just in time (JIT) – Schedules and estimates must be given in ranges – Traditional business approaches will eliminate most benefits of agile  The new relationship with the customer: – They must be actively involved with development all the way through the lifecycle – The greater visibility and control that they now have implies the need for greater accountability on their part – They often don’t understand the implications of what they ask for, you need to educate them © 2009 IBM Corporation 23
  • 24. Building a smarter planet Agile changes your relationship with the business  Common problem: Customers don’t want to be actively involved with development, not realising that they increase project risk – The customer must be involved with development projects on a daily basis – The customer must provide information and make decisions in a timely manner  Suggested strategy: – Help your customers to understand what is expected of them and why – Customer decision makers need to be coached too – Be selective about the projects you apply agile strategies to. If the customer isn’t willing to step up then the project isn’t a good choice for agile © 2009 IBM Corporation 24
  • 25. Building a smarter planet Pulling it all together with planning & governance  Treat agile adoption like an agile project – Have a release plan – Have iterations where you deliver something regularly – Demo your results, both successes and failures – Reflect on what you’ve learned and steer the project accordingly © 2009 IBM Corporation 25
  • 26. Building a smarter planet Our Strategy for Agile Transformation Waves of Change Today Future Wave 1 Wave 2 Wave 3 Vision Change Change Change Initiative / Initiative Initiative Project Introduces 1 or more development Agree Scope Train, Pilot, Harvest, Roll out wider Final Roll Business capabilities Business Case Package, Test scale out As Usual High Level Plan Define Results Development Projects [Best Practices for Transformation]  Adopt process & tools incrementally in projects  Support project teams with just-in-time training & mentoring to accelerate learning/adoption  Demonstrate quick-wins from projects.  Develop internal SMEs/Mentors who deliver mentoring to project team via CoE/Tools Group © 2009 IBM Corporation 26
  • 27. Building a smarter planet Five Best Practices for Driving Change Outside-in Development Design Processes Componentization Communities and and Reuse Community Source Measurements and Reporting 27 © 2009 IBM Corporation
  • 28. Building a smarter planet Our Approach for Agile Governance = Managing Uncertainty and Managing Variance  Scope is not a requirements document, it is a continuous negotiation Plans/Resource estimates Scope Product features/quality  A plan is not a prescription, it is an evolving, moving target Uncertainty in Stakeholder Satisfaction Space Initial State Initial Plan Actual path and precision of Scope/Plan © 2009 IBM Corporation 28
  • 29. Kick off 29 Initial release planning Indentify assets for reuse / sourcing (incl. documentation) Warm-up 2-6 weeks Building a smarter planet High level architecture Requirement confirmation release sprint planning Develop and stabilize Sprint1 2-4 weeks Demo plan sprint planning Sign-off Retrospective Project Timeline Template Develop and stabilize Sprint 2 2-4 weeks Demo sprint planning Sign-off On going Retrospective … Develop and stabilize 2-4 weeks stabilize Demo Finalise release testing Sign-off Retrospective Hand -over assets (incl. documentation) Technical implementation 2-4 weeks Roll -out organisational Implementation implementation Sign-off © 2009 IBM Corporation
  • 30. Building a smarter planet But What Should We Measure? An Example Set of Candidate Agile Metrics..lots of possibilities! Executive Dashboard Project Health Customer Quality Development Quality Strategic Health  Defect Backlog  Transactional Survey  Defect Backlog  Sales Plays  Defect Density  PMR / Call Rates  Test Escapes  Partner Enablement  Defect Repair Latency  Critical Situations  Functional Test Trends  Critical Situations  Support Enablement  Build Health  Cost of Support  System Test Trends  Technical Enablement  Project Velocity  Installability  S-Curve Progress  Sales Enablement  Staffing Actuals  Enhancement SLA  Automation Percentage  Localization  Process Timeliness  Useability  MCIF Index  Milestone Status  Consumability  Customer Testcases  Competition  Severity Analysis  Perceived Performance  Integrated into Story  Security Vulnerabilities  Scalability  Consumability Scorecard  Green Threads  Static Code Analysis  Integrations with other  LCM  Requirements Met products  Defect Latency  Pipeline / Multiplier  IPD Timeliness  User Experience / Doc  Quality Plan Commitments  Test Coverage  Revenue Time to Resolution Evolutionary Architecture Vulnerability Assessment Practices Test Driven Development Whole Team Concurrent Testing Requirements Management Team Change Management © 2009 IBM Corporation 30
  • 31. Building a smarter planet Measures Help Answer Key Questions Business-Related IT-Related Agile-Related Measures Measures Measures Appropriate level Projects deliver of management Agile practice faster than today and analysis adoption activities Are we meeting Projects deliver Are we seeing Efficient change Are we agile? Agile role with lower overall business cost than today the benefit request process adoption objectives? created Systems where we Efficient Agile work requirements or updated in the projects have the expected? definition and product adoption agreed quality signoff The development Fewer breakages organisation is a when solution Agile task learning elements are adoption organisation integrated Employee Less “solution Agile process satisfaction hardening” needed adoption © 2009 IBM Corporation 31
  • 32. Building a smarter planet Key Project Performance Metrics: Agile View (all reported by common reporting period) Delivery Rate vs. Plan Scope Change Rate Burndown/Velocity (Add, Modify, Remove) t 140 h 120% t 160 g h i 120 100% g i 140 e e W 100 W 120 y 80% y b b 100 s 80 s e e r r 60% u 80 u t 60 t a a e 40% e 60 F F 40 e t e t a 40 g a 20% g 20 e r 20 e r g g g g 0 0% A 0 A 1 2 3 4 6 5 7 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13 Reporting Period Reporting Period Velocity: Plan – – – Optimistic – – – Best Guess – – % Pessimistic – – – Planned Features Delivered Features – of Plan To-Date Baseline Features Added / Modified Features Removed Features Actual Burndown (Features Remaining) Delivered in Period Delivery / Labor Cost Performance Integration Test Quality 350% 140% (High Severity Defects) 300% 120% 250% 100% 200% 80% 150% 60% 100% 40% 50% 20% 0% 0% 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 5 4 6 7 8 9 10 11 12 13 Reporting Period Reporting Period % Defects Open Defect / Test Run Ratio % of Plan To-Date % of Plan Spend Rate Cost EAC % Projection % Test Cases Run In Period Feature / Test Run Ratio This is a sample view. Metrics can take different forms. The intent is ensure that the charts address core management concerns and associated questions. © 2009 IBM Corporation 32
  • 33. Building a smarter planet Agile Performance Metrics: Core Answers (all reported by common reporting period) Delivery Rate vs. Plan Scope Change Rate Burndown/Velocity (Add, Modify, Remove) t 140 h 120% Are scope changes t 160 g 120 h i e Are we on schedule? 100% g i 140 e overwhelming our W 100 If not, how far behind? W 120 y b 80% y ability to deliver? b 100 s s 80 e r When will we complete? 60% e r u 60 u 80 t t a a e 40% e F 60 F 40 e t 40 e t a a 20 20% g g e 20 r e r g g g g 0 0% A 0 A 1 2 3 4 6 57 8 9 10 11 12 13 1 2 3 4 5 6 7 8 9 10 11 12 13 Reporting Period Reporting Period Velocity: Plan – – – Optimistic – – – Best Guess – – % of Plan To-Date – Planned Features Delivered Features – Pessimistic – – Baseline Features Added / Modified Features Removed Features Actual Burndown (Features Remaining) Delivered in Period Delivery / Labor Cost Performance Integration Test Quality 350% 140% (High Severity Defects) 300% Are our estimates good? 120% Do we have enough test coverage and 250% Do we have enough staff ? 100% execution? 200% What will it take to complete? 80% Is the quality of our deliveries good 150% 60% enough? 100% 40% 50% 20% 0% 0% 1 2 3 4 5 6 7 8 9 10 11 12 13 1 2 3 5 4 6 7 8 9 10 11 12 13 Reporting Period Reporting Period % Defects Open Defect / Test Run Ratio % of Plan To-Date % of Plan Spend Rate Cost EAC % Projection % Test Cases Run In Period Feature / Test Run Ratio Here are the key management questions answered by each chart. An inability to answer any of these questions serves as a source of fundamental risk. © 2009 IBM Corporation 33
  • 34. Building a smarter planet © 2009 IBM Corporation 34
  • 36. Building a smarter planet © 2009 IBM Corporation 36
  • 37. Building a smarter planet © 2009 IBM Corporation 37
  • 38. Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 38
  • 39. Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 39
  • 40. Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 40
  • 41. Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 41
  • 42. Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 42
  • 43. Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 43
  • 44. Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 44
  • 45. Building a smarter planet Addressing the scaling factors © 2009 IBM Corporation 45
  • 46. Building a smarter planet Addressing the anti patterns © 2009 IBM Corporation 46
  • 47. Building a smarter planet Addressing the anti patterns © 2009 IBM Corporation 47
  • 48. Building a smarter planet Addressing the anti patterns © 2009 IBM Corporation 48
  • 49. Building a smarter planet Addressing the anti patterns © 2009 IBM Corporation 49
  • 50. Building a smarter planet The roles have changed, so must you  Traditional roles:  Agile roles: –Analyst –Stakeholder/Customer –Architect –Team Lead/Scrum Master –Database Administrator –Designer –Product Owner –Developer –Agile Team Member –Product Manager –Architecture Owner –Project Manager –Quality Assurance (QA) –Tester © 2009 IBM Corporation 50
  • 51. Building a smarter planet Agile Coaches  Good agile coaches – Have deep experience in agile – Have good interpersonal skills – Are respected by their teams based on merit, not on positional status – Are actively involved with the team(s) that they are mentoring, but don’t dominate them – Create an environment where people collaborate and learn together  Role and responsibilities of an agile coach – Provide advice to the team – Provide opportunities for people to learn, even through mistakes – Pair with the people they are coaching to provide detailed mentoring – Help teams to solve problems – Negotiate conflicts within the team – Promote self organization and self discipline within the team – Help the team to understand and meet their improvement goals  “Growing” your coaches – 1 experienced coach can coach two teams (10 people each) on one project at a time. While doing so, they can also develop one agile coach with each team. – Senior coaches can develop coaches in about 3 months, but typically it takes 6 months to develop new coaches © 2009 IBM Corporation 51
  • 52. Building a smarter planet Agile Champions  Good agile champions – Understand the fundamentals of agile – Understand how to apply agile at scale – Understand enterprise-level implications of agile – Are respected by agile teams based on their merit, not positional status – Create an environment where agile teams are given the resources to succeed  Role and responsibilities of agile champions – Support the agile coaches – Work closely with the business to help them understand and shift to agile – Work closely with IT senior management to help them understand and adopt agile – Communicate to the organization the current status of the agile adoption, successes, … – Help promote communication between the agile coaches and teams – Promote and defend agile approach in their LoB – Use collected results to show value © 2009 IBM Corporation 52

Editor's Notes

  1. Introduce Rick and Kurt – backgrounds and experience – include internal IBM but emphasise CUSTOMER experience Quick overview of IBM’s credentials – yes we may be one of the largest organisations in the world but we too started small – small projetcs
  2. Where did we come from? What was it like in early days Informal adoption since early 2000s, likely earlier Official adoption program started in 2006 Multi-faceted strategy Adoption of agile techniques Adoption of lean philosophies Increased reuse and asset management Leveraged existing IBM improvement group, Quality Software Engineering (QSE) Adoption of new collaboration and development products (including Jazz and Lotus products) Improvement of the governance process to reflect agile strategies Approach included Training and education at all levels in SWG, including practitioners, middle management, and senior management Mentoring/coaching at all levels, particularly on project teams This is a long-term, multiple-year strategy which is still underway Process improvement is continuous
  3. Significant changes in project roles Traditional roles have mostly disappeared Agilists are generalizing specialists with a wider range of skills Significant culture change Focus on delivering visible value to stakeholders regularly Focus on high-value activities Agile teams are self organizing Disciplined agile teams are governed appropriately Quality focused Collaborative and evolutionary Agile adoption is a paradigm shift Multi-year, ongoing effort People and cultural issues are critical Insufficient support for the effort You must invest in training, mentoring, and coaching You must consider investing in new tooling
  4. In the early days, agile development was applied to projects that were small in scope and relatively straightforward. Today, organizations want to apply agile development to a broader set of projects. Agile needs to adapt to increasing complexity. Agility@Scale is about explicitly addressing the complexities that disciplined agile delivery teams face in the real world. The agile scaling factors are: Geographical distribution. What happens when the team is distributed within a building or across continents? Team size. Mainstream agile processes work well for small teams (10-15), but but what if the team is fifty people? One hundred people? One thousand people? Compliance requirement. What if regulatory issues – such as Sarbanes Oxley, ISO 9000, or FDA CFR 21 – are applicable? Domain complexity. What if the problem domain is intricate ( such as bio-chemical process monitoring or air traffic control), or is changing quickly (such as financial derivatives trading or electronic security assurance). More complex domains require greater exploration and experimentation, including but not limited to prototyping, modeling, and simulation. Organization distribution. Sometimes a project team includes members from different divisions, different partner companies, or from external services firms. Technical complexity. Working with legacy systems, multiple platforms, or blending disparate technologies can add layers of technical complexity to a solution. Sometimes the nature of the problem is very complex in its own right. Organizational complexity. The existing organizational structure and culture may reflect traditional values, increasing the complexity of adopting and scaling agile strategies. Different subgroups within the organization may have different visions as to how they should work. Individually, the strategies can be quite effective, but as a whole they simply don’t work together effectively. Enterprise discipline. Organizations want to leverage common infrastructure platforms to lower cost, reduce time to market, and to improve consistency. They need effective enterprise architecture, enterprise business modeling, strategic reuse, and portfolio management disciplines. These disciplines must work in concert with, and better yet enhance, the disciplined agile delivery processes. Each scaling factor has a range of complexities associated with it. Each team faces a different combination of factors, and therefore needs a process, team structure, and tooling environment tailored to meet their unique situation.
  5. No support for skills development Your organization needs to invest in coaching, training, and education Agile in name only You need to do more than read a book or attend a workshop to become agile Only focusing on construction Agile applies to the full delivery lifecycle Thinking that you’re special If you think that you can’t become more agile, you are very likely mistaken
  6. To achieve systemic improvement within an IT organization, you need to address five primary issues: People. Solution delivery is a “team sport”, individuals and the way that they work together are the primary determinants of success on most projects. Principles. You need a consistent and coherent philosophical foundation which reflects your values as an organization to guide your decisions. Practices. Practices are contextual, describing how people work together to achieve a goal. Products. The tools and technologies which people use to perform their work. Process. The “glue” which pulls everything together. See https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler/entry/5pofit?lang=en_us
  7. Agile roles are different than traditional roles, even though they may sound similar to what you are used to. Many organizations struggle to adopt agile effectively because they’re not willing to make the changes necessary to support these new roles. This is an example of the “Organizational Complexity” scaling factor. Agile principle # 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.