Pete Measey, Agile project governance


Published on

Assurance of agile projects conference, 27th November 2013

Published in: Business, Technology
  • Be the first to comment

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

No notes for slide

Pete Measey, Agile project governance

  1. 1. Agile Project Governance What business performance looks like with poor IT performance 1
  2. 2. Introductions Peter Measey – RADTAC CEO BCS Agile Committee Certified Scrum Trainer PMI-Agile Certified Practitioner DSDM Certified Trainer APMG Certified Lean Prince2 Practitioner Ex DSDM Board Director Public & Private sector experience 30 years mainly Information Technology Agile specialist since 1994 Worldwide Agile trainer and consultant © RADTAC 2013 2
  3. 3. What we’ve learned from 15 years…… © RADTAC 2013 3
  4. 4. What is ‘Agile’, Why do it ? What is Agile Why do Agile © RADTAC 2013 4
  5. 5. Why Agile ? Standish Group Chaos Report
  6. 6. What is Agile - Iterations / Sprints
  7. 7. When to use Agile ?
  8. 8. What is Agile – Project Context
  9. 9. Agile Assurance In terms of providing assurance to stakeholders in an agile environment how does our approach have to change? The role of assurance in agile environments is definitely NOT business-as-usual, so what is it? © RADTAC 2013 9
  10. 10. Assurance Most ‘Agile’ fails because it isn’t agile  WAgile  FrAgile  SNAgile Method fundamentalism can be an issue  ‘Pragmatic Agile’ Is Agile doing any good  The point of Agile isn’t perfect Agile, the point of Agile is excellent delivery governed effectively 10 © RADTAC 2013
  11. 11. Agile Stakeholder Assurance – Delivery ! © RADTAC 2013
  12. 12. Delivery Assurance - Measure Team ‘Agility’ © Copyright RADTAC 2010 12 © RADTAC 2013
  13. 13. Transformation Assurance - Measure the improvement Value Predictability Net Promoter Score Running Tested Features Velocity / Throughput Increment Burndown Quality Escaped Defects Productivity / Flow Cycle Time & Work in Progress Technical Debt © RADTAC 2013
  14. 14. Transformation Assurance - Measure the ‘Change Wave’ The Shallow Wave Individual teams adopt their own way of working The way of working is compatible with existing method of programme and project management Not a sustainable change outside of the team, when members depart the way of working is likely to collapse Has little Enterprise benefit, in fact is unlikely to deliver any benefit as it sits in isolation surrounded by Constraints The Breaking Wave ‘All senior team on Board, ‘gung-ho’ , flavour’ of the month It is a managed and ‘driven’ adoption. Small project teams at layer 3 embrace ideas Layer 2, ‘The Frozen Middle’ not engaged, wave crests, breaks and collapses, senior team ‘walk away’ Layer 3 get beaten up by layer 2 for being so ‘stupid’ – don’t do it again The Sustainable Wave Change comes from in all layers in a vertical slice through the organisation The change is ‘Led’ through adoption and demonstrable behaviour Company starts small and acts fast to expand Scalable growth horizontally across the whole enterprise – horizontal stripe ‘T’ Shaped People – ‘T’ Shaped Organisation Horizontal Stripes are where most people would recognise Agile implementations – IT Teams and departments Vertical Slice is where true change is required to effect sustainable Transformation Why Most Transformation is unsuccessful (60-70% fail – McKinsey - Inconvenient Truth About Change Mang’t © RADTAC 2013
  15. 15. Emergent Documentation What is documentation? • Design documentation • Code documentation • User documentation • Support documentation • Operational documentation How does it emerge? © RADTAC 2013
  16. 16. Are we on Track – Visual Boards © RADTAC 2013
  17. 17. Right Product ? Show and Tells © RADTAC 2013
  18. 18. Right Approach - Retrospectives © RADTAC 2013
  19. 19. Agile Across the Value Chain What happens when supply-chain implement agile when the client’s expectations’ or commitments’ don’t ‘fit’ the agile model? © RADTAC 2013 19
  20. 20. Waterfall Value Chain Arch Analysis Design Front End Build Back End Build Test Customer Features Wanted Something Delivered (eventually) = Process or product or signoff point © RADTAC 2013
  21. 21. Agile Value Chain – wide as possible Product Backlog Arch Skills Focus on Highest Priority Features Wanted/ Analyst Skills Highest Priority Feature/s Wanted Highest Priority Feature/s Agreed Product Owner Design Skills Test Skills Coding Skills Highest Priority Feature/s Delivered (immediately) © RADTAC 2013
  22. 22. Agile vs Conventional ‘Waterfall’ Should we be shifting our attention to smaller teams incrementally delivering quality products instead of the conventional lifecycle methodology? Will assurance in an agile world mean: face-to-face conversations, better collaborations between acceptance (testers) and developers, developers and designers, suppliers and end-users? Does integrated assurance in an agile world mean that we have to re-think the definition of ‘integration’ to one that stems back to basics where clients and delivery teams communicate and collaborate? © RADTAC 2013 22
  23. 23. Business and Developers Work Together Team size 7 plus or minus 2
  24. 24. Face-to-face Communications
  25. 25. Deliver Working Systems Frequently and collaboratively
  26. 26. Satisfy the Customer with Continuous Delivery of Value
  27. 27. Legal / Safety; Roles and responsibilities What about legalities and/or safety-critical issues when delivering with agile – how does assurance play its part? Where we have to redefine roles and responsibilities © RADTAC 2013 27
  28. 28. Agile Quality Assurance and Testing Quality Assurance Regular delivery of a working product Agile testing Acceptance criteria TDD, ATDD, BDD Automated testing Continuous integration, build and deploy User Acceptance
  29. 29. The Role of the Customer Hold the product vision Prioritise work Communicate with the business stakeholders Assist with issues Approve the work
  30. 30. The Role of the Team Decide how to do work Decide who does the work Estimate the work Do the work
  31. 31. The Role of the Stakeholders Provide governance Provide finance Provide support Provide blockers!
  32. 32. Final Thoughts….. © RADTAC 2013 32
  33. 33. This most important thing you could learn ? Recognising that while Agile may be/seem easy….. TRANSFORMATION ISN’T !! Many organisations flounder with Agile Especially when attempting to scale - they become ‘burn victims’ So then they get help - after wasting much time, effort and money … and people! … and so the perception then is that “Agile failed” © RADTAC 2013 33
  34. 34. Support from experts is required Would you re-platform a technical capability without technical experts ? How about not employing transformation experts when the ‘platforms’ are human beings ? Transformation experts involved C A P A B I L I T Y Kanban transformation – transformation experts involved Not supported – long, painful, costly transformation Not supported – failed change TIME © RADTAC 2013
  35. 35. Start with Visualising - WHY “the definition of insanity is doing the same thing over and over again and expecting different results” And then measuring the same results (repeated failure) over and over again ! 35 © RADTAC 2013
  36. 36. APM - Agile Peter Measey – RADTAC CEO Office: +44 (0) 203 6385040 Mobile: +44 (0) 7970 435290' Web: Majority of slides from BCS Agile Foundation Certification Course (BCS syllabus and course created by RADTAC) © RADTAC 2013 36