際際滷

際際滷Share a Scribd company logo
Scaling agility across the Enterprise.
Focus on visibility, consistency and keeping track of the bigger picture



David Weir  Head of Development
Presentation Summary

 Quick overview
 Why we needed to become Agile
 Scrum Boards  Common Pitfalls
 Scrum Boards  Quick Wins
 Practical walkthrough
 Increase visibility across the Enterprise/
  Multiple Programmes
 Q&A
Introducing Callcredit

 More than 1000 employees in
  ten locations, headquarters in
  Leeds                                  Experts in
                                         enabling smarter
                                         decisions, by
 Vertically split into 3 sectors:-      converting clients
  Credit, Marketing and Consumer.        own DATA into
                                         INFORMATION
 Serving leading companies in
  Financial
  Services, Telecoms, Retail, Utilitie
  s and Insurance
Our Agile Adoption

 Since 2000 (inception) Callcredit has grown both organically and
  through acquisition ( over 8 sub companies acquired in 12 years)

 Adopted a complete new restructure in 2010 to provide total
  operational capability (HR, IT, Legal, Facilities) as one to the wider
  group.

 In parallel to the TOM, we adopted a standard Agile delivery
  approach:- DSDM

 DSDM
       More business friendly terms
       Prioritised set of requirements (M60%, S20%, C20%, W0%)
       Delivers to a fixed time, dropping scope (S&C) if necessary
Scrum Boards / White Boards

 Provides a focal point for the project team
 Assists the velocity
    Are we working on the right things
    Whats blocked
    What is committed / time left
 Ensures important steps are not missed

 Provides visibility
 provided that we stick to a few simple rules.
No Scrum board is the same
Examples of some of our white boards
Quick Win 1: Project Info

   Name of the Project or Product
   Timebox Start Date
   Timebox End Date
   Optional
      RAG
      Current Stage
      Due Date
Quick Win 2: Consistent Sectors
        Backlog          Q        In Progress     Q       In QA          Done
                         13                       13

Derived from Timebox
                  Where a priority is currently in a number of
                                 A story    Where A story currently in QA
      Planning decided then this shows stories are completed and Completed stories
                                    development
                              Story Section
               the next story to move to awaiting QA they can be
                     development              prioritised here
                                                                  ready for timebox
                                                                        release




                              Task Section
Quick Win 3: Colour Coding

    A


                           STORY
                             TASK
                            Issue
   A.1                    BLOCKER
                              A.1
                               A
                       Test Database
                  QA Resource Unavailable
                         Corrupted
              As a businessto allow ............. To
              Write query ambassador I want
                to be able to ............ So that
                        be retrieved
  Blocker




   Issue
Quick Win 4: Consistent Progression
                Backlog                     Q            In Progress   Q     In QA       Done
                                            13                         13


      C                   F                        A
                                            B

      E                                            D
                                            G




A.5                                              A.1      A.3    I          A.2      B   A.4


B.1             B.2      B.3
                                                                                         D.1    D.3
                                                   D.2
E.1             E.2      E.3         E.4


F.1             F.2


G.1       G.2     G.3   G.4    G.5    E.6
Practical Walkthrough - Scenario

 There is a development conference in
  Southampton (UK) scheduled for 4th May 2013.
  We have won the exclusive catering contract
  for this event.
 We must transport 2 Tonnes of bananas from
  Rio (Brazil) to the Event
 We must arrive via France in order to pay the
  minimal European import tax
Practical Walkthrough  NFRs

 The transport must arrive before May 2013
 Bananas will only last 6 weeks unrefrigerated
 Southampton port is not used to international
  trade therefore we must upgrade its
  navigational aids.

 2 Projects. Build a Boat, and Build a Lighthouse
The Boat Design
The lighthouse Design 1
The lighthouse Design 2
The lighthouse Design 3
The Plan
The Boat: Halfway checkpoint
The Lighthouse: Halfway Checkpoint
The Boat: Complete (Ahead of Schedule)
The lighthouse: Complete J.I.T
Conclusion
Post Implementation Review

   Boat twice as fast as expected
   The light house was delayed
   The boat was finished and released early


          FUNDAMENTALLY  Each project
    The daylight savings hours (march) wasn't considered
    ......Lots of other reasons etc.
           was not concerned or visible to
Generally
 Each project acted exactly as it should have donetheir joint
           one another despite to satisfy its own
  requirements.
 Each project approached the delivery using manyLOOKING
           goals NO ONE WAS of the tried and tested
  agile techniques (incl. Running their whiteboards/scrum boards as
  demonstrated  this doesn't guarantee success)
 Doing right by their own project but by the programme/Enterprise
 No overarching ownership
Scrum of Scrums

 9:45am daily huddle which contains all PMs
  and other stakeholders to discuss issues/status
  of the day.
 Reports on the major
  issues, concerns, changes and state of every
  project in a programme
 Contains key individuals who can un-block
  major issues (Dev/QA/DBA/Infrastructure)
Our Scrum of Scrums Board
Project Cards


                   Project Name
                   Release Name
                   PM Initials
                   Release Date
                   RAG Status
                   Any associated Issues
                    or Blockers

More Related Content

Scaling Agility Across the Enterprise

  • 1. Scaling agility across the Enterprise. Focus on visibility, consistency and keeping track of the bigger picture David Weir Head of Development
  • 2. Presentation Summary Quick overview Why we needed to become Agile Scrum Boards Common Pitfalls Scrum Boards Quick Wins Practical walkthrough Increase visibility across the Enterprise/ Multiple Programmes Q&A
  • 3. Introducing Callcredit More than 1000 employees in ten locations, headquarters in Leeds Experts in enabling smarter decisions, by Vertically split into 3 sectors:- converting clients Credit, Marketing and Consumer. own DATA into INFORMATION Serving leading companies in Financial Services, Telecoms, Retail, Utilitie s and Insurance
  • 4. Our Agile Adoption Since 2000 (inception) Callcredit has grown both organically and through acquisition ( over 8 sub companies acquired in 12 years) Adopted a complete new restructure in 2010 to provide total operational capability (HR, IT, Legal, Facilities) as one to the wider group. In parallel to the TOM, we adopted a standard Agile delivery approach:- DSDM DSDM More business friendly terms Prioritised set of requirements (M60%, S20%, C20%, W0%) Delivers to a fixed time, dropping scope (S&C) if necessary
  • 5. Scrum Boards / White Boards Provides a focal point for the project team Assists the velocity Are we working on the right things Whats blocked What is committed / time left Ensures important steps are not missed Provides visibility provided that we stick to a few simple rules.
  • 6. No Scrum board is the same
  • 7. Examples of some of our white boards
  • 8. Quick Win 1: Project Info Name of the Project or Product Timebox Start Date Timebox End Date Optional RAG Current Stage Due Date
  • 9. Quick Win 2: Consistent Sectors Backlog Q In Progress Q In QA Done 13 13 Derived from Timebox Where a priority is currently in a number of A story Where A story currently in QA Planning decided then this shows stories are completed and Completed stories development Story Section the next story to move to awaiting QA they can be development prioritised here ready for timebox release Task Section
  • 10. Quick Win 3: Colour Coding A STORY TASK Issue A.1 BLOCKER A.1 A Test Database QA Resource Unavailable Corrupted As a businessto allow ............. To Write query ambassador I want to be able to ............ So that be retrieved Blocker Issue
  • 11. Quick Win 4: Consistent Progression Backlog Q In Progress Q In QA Done 13 13 C F A B E D G A.5 A.1 A.3 I A.2 B A.4 B.1 B.2 B.3 D.1 D.3 D.2 E.1 E.2 E.3 E.4 F.1 F.2 G.1 G.2 G.3 G.4 G.5 E.6
  • 12. Practical Walkthrough - Scenario There is a development conference in Southampton (UK) scheduled for 4th May 2013. We have won the exclusive catering contract for this event. We must transport 2 Tonnes of bananas from Rio (Brazil) to the Event We must arrive via France in order to pay the minimal European import tax
  • 13. Practical Walkthrough NFRs The transport must arrive before May 2013 Bananas will only last 6 weeks unrefrigerated Southampton port is not used to international trade therefore we must upgrade its navigational aids. 2 Projects. Build a Boat, and Build a Lighthouse
  • 19. The Boat: Halfway checkpoint
  • 21. The Boat: Complete (Ahead of Schedule)
  • 24. Post Implementation Review Boat twice as fast as expected The light house was delayed The boat was finished and released early FUNDAMENTALLY Each project The daylight savings hours (march) wasn't considered ......Lots of other reasons etc. was not concerned or visible to Generally Each project acted exactly as it should have donetheir joint one another despite to satisfy its own requirements. Each project approached the delivery using manyLOOKING goals NO ONE WAS of the tried and tested agile techniques (incl. Running their whiteboards/scrum boards as demonstrated this doesn't guarantee success) Doing right by their own project but by the programme/Enterprise No overarching ownership
  • 25. Scrum of Scrums 9:45am daily huddle which contains all PMs and other stakeholders to discuss issues/status of the day. Reports on the major issues, concerns, changes and state of every project in a programme Contains key individuals who can un-block major issues (Dev/QA/DBA/Infrastructure)
  • 26. Our Scrum of Scrums Board
  • 27. Project Cards Project Name Release Name PM Initials Release Date RAG Status Any associated Issues or Blockers

Editor's Notes

  • #2: David Weir Role, Years in the role, agile experience. Interesting fact.Graham Fisher - Role, Years in the role, agile experience, Interesting fact.
  • #5: Each acquisition brought Callcredit a new business offeringEach with a different set of productsHowever.Each brought an IT Team to support development, operations and maintenanceFragmented teams, operating in SilosMixture of technologies and standards. Mixture of methodologies and processesMixture of Infrastructure and operational capabilityWe opted for DSDM because it is a very Business Friendly framework. At least 50% of the framework is dedicated to the non-development activities, whereas SCRUM/XP tends to start from the software engineering Agile practices upwards.DSDM deals with changing requirements that are prioritised. DSDM works on iterative model, whilst SCRUM uses terms like Sprints, DSDM uses TimeboxFeasibility Foundations Exploration Engineering DeploymentDSDM has no need to detail the requirements up front. Business Sponsor == Product SponsorProject Manager == Scrum MasterTechnical Co-ordinator == ArchitectDSDM Team Lead == Scrum MasterBusiness Ambassador == Product OwnerBusiness Analyst == DeveloperSolution Developer == DeveloperSolution Tester == Quality Assurance
  • #6: DSDM does not specifically dictate that you have Huddles, or use Scrum Boards. But it does recognise a great number of modern agile engineering practices that can be used to achieve the goals set out in the DSDM framework.We all know Scrum Boards are great So there is little point trying to convince why it is a good idea to use them. But one of the key/major reasons to use a scrum board is often overlook. Visibility. The Scrum board is the Shop Window to the project. It should be a useful tool to more than just the immediate members of the team. You shouldnt need to be a fully trained agile developer or even technical to extract basic info from a well design Scrum Board.
  • #8: Each project requires different styles of white boardsSome projects will have may swim lanes, some just a fewSome will write a lot of details on the story cards, some just a prompt. Quick Question: Is this a Good Timebox or not?
  • #9: When you have 15+ plus project, all with different degrees of decencies and overlaps, you need a degree of consistency between the management, tracking and progression of scrum board usage.
  • #11: By keeping a strict Key, non-project members (such as myself/ Graham) are now tuned into the colour orange. When we pass a scrum board an orange post-it might catch our eye, and well try to unblock it. We distinguish between blocker and issues, with both a colour and orientation. Our definition of a blocker is Requires help. If something will not be done on time because of a problem , but the project team or team member is on top of the situation then this is just an issue. An FYIBusiness people are now accustomed to the green post-it note, because the stories are generally as low level as the care or understand.
  • #13: So now we know everything we need to know about running a Scrum board. And now we know, if 2 projects follow these simple rules, it will be clear and VISIBLE to everyone what is going on? Yes/No
  • #15: We need a boat that can carry 2 tonnes of bananasWe need to incorporate a refrigerated area to store themWe need somewhere for the crew to live for the journeyWe could MOSCOW the requirements, but we havent got time today.
  • #16: Must be able to withstand all weathersNeeds to be visible in day lightNeeds to bright and long range visibilityBricks/foundationsLight Needs to RotateShould be powered by the waves
  • #17: Must be able to withstand all weathersNeeds to be visible in day lightNeeds to bright and long range visibilityBricks/foundationsLight Needs to RotateShould be powered by the waves
  • #18: Must be able to withstand all weathersNeeds to be visible in day lightNeeds to bright and long range visibilityBricks/foundationsLight Needs to RotateShould be powered by the waves
  • #19: Oct: Start Building the BoatNov: Start Building the lighthouseDec: Half Way Checkpoint, Progress CheckJan: Continue to build the boat and the lighthouseFeb: Boat build complete, boat due to set sail mid-febMar: Lighthouse build complete. The Boat should be 2 weeks into its 6 week journeyApr: Boat Arrives in France22nd Apr 2013 4:00AM: Boat is released from French Customs22nd Apr 2013 12:00PM NOON: Boat expected to pass lighthouse22nd Apr 2013 13:00PM; Boat expected to dock in Southampton4th May: Bananas ripe and ready for Developers Conference. Code Monkeys happySo Lets start to build the boat, using a Scrum board:NOTE: Since all of the goods are going to be on the boat, and generally people are more excited by the boat construction than the Lighthouse, the budget for the boat is well financed, and we have put our best team onto it.
  • #20: The boat should be partially builtNo sails yetPart still missing on the hullFridge compartments should not be built yetNow lets start to build the lighthouseNOTE: The light house has a strict budget and timescale, so we going to stick with what we know. Since bricks and motor is very much a traditional design, we can consider this project legacy. On a positive: We are developing using Continuous Integration and Continuous Deployment.
  • #21: Just the foundations have been builtit has not been painted luminous / day-glowThe base of the lighthouse started, with an outline (dashed) which indicates how much of the build was expected to be built at this point. So how far behind we areThe water wheel construction has started, but no power yet
  • #22: The completed boat is different from the initial designThe boat should still be based on a sail boat design, but more modernThe biggest difference is the added outboard motor, this should be exaggeratedThere is no-longer a need for a fridge compartment, so the banana should be visible on deckNo need for sails The boat should still be the same size as the design
  • #23: The boat is not scheduled to arrive until 12Noon for its maiden voyage, so we must focus the efforts on completing the structure and making it visible in the day time.Light fitted but not working.The light is just a standard light, that does not rotateThe water wheel is still half complete
  • #24: Scene: Night time, about dawnThe boat has smashed into the lighthouseLight still not onPeople overboard in seaBananas everywhereLuminous / day glow paint not very visible at nightBoat is broken
  • #28: We use Red, Amber and Green Magnets to denote RAG Status.