PointZERO Enabling the right first time principle

Transcription

1 PointZERO Enabling the right first time principle Antwerpen, 16 May 2013 Geert Vanhove Rik Marselis Consumerization of IT Cloud Big data Mobility bl Social 1

2 Major causes of both cost and time overruns Unrealistic project cost estimates and schedules Weak communication and ineffective decision making Lack of effective executive project sponsorship Insufficient user involvement Poorly written and/or changing requirements Late failure warning signals Unclear priorities Insufficient risk management Undisciplined, inflexible development practices/processes. What are today s challenges? Instant reaction by the consumers High impact of failures due to chains Image of companies impacted by social media Competitive market Quality What is quality? When is the quality good enough? When do we need to achieve this quality? Traditional testing is not sufficient anymore! 2

3 PointZERO PointZERO is (definition) A vision aimed at increasing business success by parallel and step-by-step improvement across the application lifecycle, to shorten time to market, avoid and reduce cost, eliminate risk, and reach fit for purpose quality 3

4 What is success? Wikipedia: Achievement of a Goal; the opposite of Failure When is your business successful? Project ready in time? IT Quality meets standards? Business value is created? Clients are happy!! Why is success important? Why do you need an information system? To increase your business success! 4

5 Application Lifecycle model Most people accept Testing as a fact of life But often they are not happy about it The IT problem Often delivered too late Cost (a lot!) more than expected Don t (completely) l solve the problem This is NOT right first time 5

6 Client said: Testing costs too much time & money So we performed a TPI NEXT assessment to assess the test maturity Conclusion: There s nothing wrong with testing The fixing and rework is the real problem! Fixing phase Why do we need a fixing phase? Can t they build it right first time? 6

7 Why don t we build it right first time? Defect distribution Capers Jones (2011) Change Analysis 26% 10% 8% Acceptance 15% Testing Requirements 19% 22% Development Design 58% of defects originate from early lifecycle activities!! What often happens Defect inserted in activity Requirements Design Development Testing Acceptance Implementation Maintenance Requirements Design Development Testing Acceptance Implementation Maintenance Defect detected and fixed in activity 7

8 Defect fixing The well-known Boehm curve still applies Three key principles Quality can t be tested in at the end Faults must be prevented; Frontload the process with quality measures People are fallible perform early reviews 8

9 No faults forward to the next activity Defect inserted in activity Requirements Design Development Testing Acceptance Implementation Maintenance Requirements Design Development Testing Acceptance Implementation Maintenance Defect detected and fixed in activity Does Agile solve this? For whom Agile has solved all problems? Agile = QD Quality Development Quick Development Quick and Dirty Quite a Disaster 9

10 What often happens Development Testing Problem grows: the later the sprint, the lower the velocity, because of the backlog of defects to be fixed No separate testing Development Testing 10

11 Implement measures right first time To enable right first time & no faults forward : Shift the quality focus to early lifecycle activities 11

12 Shift focus from time & cost to quality & risk This should be no surprise in an agile context, but often still is!! Framework for PointZERO Quality Measures Requirements Workshop Requirements Inspection Requirements Traceability Requirements Validation Business Case Workshop Business Case Review Business Analysis Business Case Management Business Risk Analysis Acceptance Management Supervision Collaboration of people & artifacts Quality Supervision Evaluations (Inspections & Reviews) Model Based Reviewing Model Driven Development System Simulations Structural Quality Analysis ALM Services End-2-end testing TPI & TMap Test Automation Model Based Test Design TPaaS Virtual Testing 12

13 Example: Quality & Risk activities in Scrum Determine product risk of each backlog item and record it on the (story) card (input for planning poker, assigning story points) Evaluate backlog items and communicate obscurities with product owner Collaborate: handover based on criteria Collaboration at handover of artifacts (quality gates) Collaboration of all parties involved for example: don t forget the maintenance people A quality gate is not a point in the process where everything comes to a stand-still, on the contrary: it must be a smooth handover based on previously agreed and monitored criteria 13

14 Quality Gates in a traditional application lifecycle Select a limited number of handover points Quality Gates for Scrum The handovers in Agile are accomplished by teamwork and common ownership. It is no longer a mere transfer of documents or deliverables. It is common responsibility. Doing Agile well will ensure that nothing gets lost in translation 14

15 Previously agreed criteria Collaborate towards smooth handover based on common responsibilities and previously agreed criteria What does this sound like? Indeed, a Definition of Done!! Including criteria on the quality needed and the risks to be covered Definition of Done includes quality and risk criteria Examples of quality and risk criteria in the DoD: Review requirements and design (or do a role-play of the process) Depending on the risk involve more people in quality check Unit testing performed How much coverage? (Statements, Decisions, Conditions, ) System testing performed Functionality covered? Non-functionals covered? Regression testing performed Results from previous sprints still stable? Test procedures of current sprint included? d? Acceptance testing performed Business process covered? The ultimate check: Client happy? 15

16 Gradual changes in testing activity through Modelization Initial: Manual testing Step 1: Industrialization Automated execution Step 2: Industrialization ti Model Based Testing (MBT) Parallel: Quality Early (model based) reviews & early tests make late-lifecycle testing unnecessary Step 3: Smart inspiration Combination of MBT & automated execution Step 4: Smart insp. Model Driven Development annihilates design, development and testing No more fixing: the ultimate goal No more testing? Not as a separate activity in the lifecycle Fully integrated in other application lifecycle l activities And of course Acceptance will remain in one way or another Testing will remain as a role, not necessarily a function Right first time! (Fixing reduced to the minimum) 16

17 A mountain can t be moved in one day Maturing is a long process of small steps forward Parallel & step-by-step improvement Kaizen: continuous improvement Using the improvement backlog Start improving at the weak spots Don t change too much at one time When ambitions for change are set high, It takes too much time before the actual savings are realized 17

18 PointZERO is a gradual stepwise move towards a goal PointZERO is about parallel and step-by-step improvement, with small but measurable effects Tip:3 improvements in parallel Quick win Good feeling with fast progress Medium term Quick win Useful improvement with high outcome Long term Medium term Quick win If you don t start now it will never get ready 18

19 How to start the PointZERO quest Pinpoint client issues (Pre-)Sales/Delivery (e.g. RCA, TPI, QOS, ) After quick scan Elaborate roadmap towards increased business success PointZERO Principal Improvement backlog Quality improvement plan Roadmap of approaches, measures, methods and tools PointZERO Team Industrialization propositions Quality & Collaboration propositions Smart inspiration propositions Effective waste reduction by doing things right from the very first moment 90% 83% of defects found before testing activity has even started 83% less incidents after go-live Looking not only at the project, but it is a comprehensive view encompassing a shift in approach that goes across the overall application lifecycle 22% minimal time to market reduction on the application lifecycle 19

20 Success factors Commitment of top management not a staff program Focus on clear results Iterative approach on improvements Improve all areas bit for bit Change culture/attitude Continuous Improvement Implementing Quality Gates as Collaboration Points Continuous Return on Investment (ROI) calculation What s the difference with traditional quality assurance? PointZERO optimizes and works towards a new way of collaboration between people and artifacts across the application lifecycle, and improves the overall lifecycle activities in order to avoid rework. This can now be achieved with the approaches, measures, methods and tools available. 20

21 What s new? Supervision for a complete and comprehensive view encompassing a shift in approach that goes across the overall application lifecycle Collaboration across all activities of the application lifecycle and also between all parties and artifacts involved No fenced off phases by frontloading the application lifecycle with quality measures instead of checking the quality at the end What s new? Key principles of Right First Time, Fit For Purpose, and No Faults Forward Effective waste reduction by doing things right from the very first moment Shorter time to market, avoid and reduce cost, eliminate risk and reach fit for purpose quality by shifting management focus from Time and Cost to Quality and Risk 21

22 Change Other approaches take you over the first hurdle, PointZERO will cut the path through the obstacle PointZERO The result Reduced effort for the lifecycle as-a-whole and Focus shifted to early lifecycle activities No more wasting time and money by focusing on Quality & Risk 22

23 Increasing business success Questions?

24 If you don t have time to do it right, When will you have time to do it over? - John Wooden PointZERO 24