How did DSDM Atern Help Create Teamwork, Quality, Innovation, Enjoyment & Pride. Matthew Caine

Transcription

1 How did DSDM Atern Help Create Teamwork, Quality, Innovation, Enjoyment & Pride Matthew Caine

2 AGENDA > Intro > A Great Story > A Truly Epic Story 2

3 Intro > Who am I? > Where did these stories take place? 3

4 We Start with a Great Story Going back in time at 4am I know where René was, but where were you?

5 Really a Great Story! We delivered! The delivery worked! The client was happy! Fantastic life does not get much better!

6 Was it Really a Great Story? Delivered at the 3 rd attempt 6 months late At the expense of another client Clients not reference-able Lost revenue Less profitable Less bonus for all Finally René s wife, daughters and two dogs were not seen for two weeks.

7 Now for a truly Epic Story The next 18 months resulted in every subsequent release being delivered: ü On time ü In scope ü In budget ü With ever better quality Resulting in greater Teamwork, Quality, Innovation and Engagement (fun). We shall prove it too!

8 How did we do it?

9 How did we do it? Operational Improvement 1. Adopting an Agile methodology (DSDM Atern) 2. Insisted that the entire team contribute to effort estimation 3. Dedicated the whole company to testing at key times 4. Improved width and depth of automated testing 5. Merged Support and Quality Control (testers) teams With the exception of the fifth point, nothing above is new, but it is how it all comes together, which is key.

10 Operational Improvement #1 Adopting an Agile Methodology (DSDM Atern)

11 Some Key Agile Concepts Scope Fixed TIme Cost Quality Quality Time Cost Variable Scope MoSCoW Prio M Must (60%) S Should (20%) C Could (20%) W - Wont Time Boxes 2-6 weeks in length, with a preference for the shorter Client feedback after every time box: FAIL-FAST

12 Why DSDM Atern and not Scrum? Context is important, we had employees that were Ø demotivated Ø dis-engaged Ø very insecure We needed to change, but the change needed to: Minimise the impact on self-esteem, security and status. 12

13 Why DSDM Atern and not Scrum? Major Difference Roles Requirements Artifacts DSDM Atern Scrum Benefit Well-defined roles such as a Project Manager, Business Analyst, Team Leader. Specifies how requirements are evolved from a Terms of Reference. Caters for artifacts such as User Manuals, Upgrade Guides. Only has Product Owner, Scrum Master and the Team. Assumes userstories exist. Only has a Product. Less resistance from key people. One methodology is required. You don t need a second for the requirements. We already had a set of artifacts that matched those in DSDM Atern.

14 Why DSDM Atern and not Scrum? Major Difference Foundations Predictability Use of MoSCoW DSDM Atern Scrum Benefit Time spent in Foundations sets the context for how the work will be done. Features are allocated to time-boxes through to the end of the project. 60% of the planned features MUST be delivered. Sometimes known as Sprint 0. A Backlog is used but no plan through to the end of a release. No guarantee, only the next item(s) on the Backlog is considered. Made us think about how the work will be done using a proven Framework. Greater transparency. Knew when something dropped out of scope, early. Can commit the 60% or else.

15 The 8 Principals of DSDM Atern Focus on the Business Need Deliver on Time Collaborate Never Compromise on Quality Build Incrementally from Firm Foundations Develop Iteratively Communicate Continuously and Clearly Demonstrate Control

16 Real-Life Roll-Out 1. Convince senior management 2. Awareness training for all team members 3. Practitioner s course for key staff and team leaders 4. Create the Prioritized Requirements List (backlog) for a release 5. Let the team estimate and plan the time-boxes 6. Use a tool such as Jira - Put the PRL into it 7. Start development of the release, following the 8 principles 8. Review progress after 3 months Plus some good oldfashioned hard work!

17 Operational Improvement #2 Insistence that the entire team contribute to effort estimation

18 The Problem is Not What You Think We all know that the people doing the work must provide the estimates. Promote this! However the real issue lies elsewhere but where?

19 The Problem is Not What You Think We all know that the people doing the work must provide the estimates. Promote this! However the real issue lies elsewhere but where? Management! They are part of the team!

20 The Problem is Not What You Think 1) When a new client is in final negotiations and 30% of the requirements are unclear, don t force the team to commit an estimate or worse tell them what you think. 2) If a team estimates 40 days for a feature based on high-level requirements, don t shoot the team when the exploration results in 100 days don t force them to do it in 40. Be part if the team, challenge yes, support definitely. Then use the saved time to grow the company!

21 Operational Improvement #3 Dedicate the whole company to testing at key times

22 Need better Teamwork It must be their environment The software works, I tested it myself Testers don t know the business I don t write software with bugs in Just ship the software, it ll be ok The test case is wrong, I ll fix the test case to fit the software

23 Quality Depends on Many Things A software product house also has to address these: Regression test the full product Efficiently remove the back-log of defects that will have built up over the years Align key resources to fix client UAT issues post release Provide reasonable time for teams to plan Improve infrastructure for build effectiveness

24 Focus Quality within Timeboxes An Agile methodology will introduce Time Boxes: A Timebox lasts 2-6 weeks (we used 3 weeks) A release consists of a number of timeboxes Here we see a release consisting of 6 time boxes, or 18 weeks

25 Focus Quality within Timeboxes We action was to introduce two special Timeboxes: Quality at the start Regression at the End Quality Regr.

26 The Quality Time Box Activity Fix client UAT issues Resolve old non-critical yet annoying defects. Improve infrastructure Upgrade software Planning The Benefit The previous release s defects are resolved efficiently. Focus on those issues that require workarounds, are annoying or just plain embarrassing. Engineers will want to improve their scripts. Keep up to date and ready: Let the next release benefit from upgrades. Allow the teams to estimate and plan. This is all high interrupt work that should be avoided when focusing on new development

27 The Regression Testing Time Box The whole company tests, all coordinated by the QC team, after all: it is one product, our product. During this, we have seen real teamwork and inter-team work: ü ü ü Team members helping each other out Teams helping each other High commitment to get the release out of the door

28 The Results are Quantifiable Just regression testing is not enough... combining regression & quality time-boxes provides the leap

29 Operational Improvement #4 Improve width and depth of automated testing

30 Mind the Gap Ø When a new product is developed, test automation keeps pace. Ø However, developers are usually added to the team before testers. Ø Automation cannot keep up. Ø A gap appears and continues to grow. Ø Consequences are obvious!

31 Close the Gap Use the MoSCoW prioritization mechanism introduced by the Agile methodology to prioritize the Regression testing time box. MoSCoW Priority Must Should Could The Benefit At the very least manually test, or else! As we are testing by hand, we should document the steps! If we have time automate as well! Remember DSDM Atern Principal # 4? Never compromise on quality.

32 Actual Progress of Gap Closure

33 Final Release Quality is Measureable One FTSE-100 company: ü Approx. 75% reduction in UAT critical issues. ü Quality being sustained. ü Client is not just happy, but ecstatic about the quality. Ø The client could now cover more tests!

34 Operational Improvement #5 Merge Support and Quality Control teams

35 Lots of Pain for Support & QC Cannot influence the product they support Always last to know Rarely exposed directly to the client Never know the end-user s true pain Low acceptance Little training

36 Merge them: Wow! Influential: They know the end user s pain and can see poor design before it gets shipped Early Involvement: In design or they cannot test and support Authority: Challenge the Prima Donnas Status: Become highly motivated Career Progression: To business analysis or professional services Attractive Job Description: Attracts talent

37 Summary Bringing it all Together

38 Teamwork & Quality are... Operational Improvement Teamwork Quality Adoption of DSDM Atern The Teams Estimate Indirect Regression & Quality Time Boxes Close the Automation Test Gap Indirect Merge Support & QC Teams

39 the Key to Innovation Examples include: ü New User-Interaction Model (RIA) with Adobe Flex. ü 3-Tier architecture ü A Cube data access mechanism for easier reporting

40 Innovation sells We now also had 100% client satisfaction. In fact, for a multi-million USD deal, 90% of the selection committee chose us because of our people and the way we worked not necessarily because of the product. That is motivating!

41 which Creates a Fun Engaging Environment! Fun! Quality Innovation Teamwork

42 Which we can all be Proud of

43 Any Questions? Ah yes before I forget, René does now get to see his wife and now three daughters. Plus his two dogs now get regular morning walks!

44 Matthew Caine M.C. Partners & Associates