Pete Measey, Agile project governance

  • 665 views
Uploaded on

Assurance of agile projects conference, 27th November 2013

Assurance of agile projects conference, 27th November 2013

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
665
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
17
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Agile Project Governance What business performance looks like with poor IT performance 1
  • 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. What we’ve learned from 15 years…… © RADTAC 2013 3
  • 4. What is ‘Agile’, Why do it ? What is Agile Why do Agile © RADTAC 2013 4
  • 5. Why Agile ? Standish Group Chaos Report
  • 6. What is Agile - Iterations / Sprints
  • 7. When to use Agile ?
  • 8. What is Agile – Project Context
  • 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. 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. Agile Stakeholder Assurance – Delivery ! © RADTAC 2013
  • 12. Delivery Assurance - Measure Team ‘Agility’ © Copyright RADTAC 2010 12 © RADTAC 2013
  • 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. 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 http://bit.ly/16HRxlZ) © RADTAC 2013
  • 15. Emergent Documentation What is documentation? • Design documentation • Code documentation • User documentation • Support documentation • Operational documentation How does it emerge? © RADTAC 2013
  • 16. Are we on Track – Visual Boards © RADTAC 2013
  • 17. Right Product ? Show and Tells © RADTAC 2013
  • 18. Right Approach - Retrospectives © RADTAC 2013
  • 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. 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. 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. 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. Business and Developers Work Together Team size 7 plus or minus 2
  • 24. Face-to-face Communications
  • 25. Deliver Working Systems Frequently and collaboratively
  • 26. Satisfy the Customer with Continuous Delivery of Value
  • 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. 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. The Role of the Customer Hold the product vision Prioritise work Communicate with the business stakeholders Assist with issues Approve the work
  • 30. The Role of the Team Decide how to do work Decide who does the work Estimate the work Do the work
  • 31. The Role of the Stakeholders Provide governance Provide finance Provide support Provide blockers!
  • 32. Final Thoughts….. © RADTAC 2013 32
  • 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. 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. 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. APM - Agile Peter Measey – RADTAC CEO peter.measey@radtac.co.uk Office: +44 (0) 203 6385040 Mobile: +44 (0) 7970 435290' Web: http://radtac.co.uk Majority of slides from BCS Agile Foundation Certification Course (BCS syllabus and course created by RADTAC) © RADTAC 2013 36