Total Cost of Ownership. and Return on Investment

Transcription

1 Total Cost of Ownership 1 and Return on Investment Ken.schwaber@scrum.org

2 ROI of Software Products 2 Traditional software accounting only takes the cost of development into account. A more balanced method would take the long term costs and value of the product into account. We should also take into account the impact of short term decisions on long term ROI

3 Product ROI over the life of a product is dependent on the variables: 3 1. Presence of valuable functionality for customers to use; 2. Absence of low value functionality that must be maintained and sustained regardless; 3. Quality code base to predictably maintain and sustain; 4. Quality code base to enhance without undue effort or risk; 5. Ability to catch defects early and no later than at release; 6. Predictability of schedules; 7. Lack of surprises; and, 8. People and resources available to work on it.

4 Quality from a Developer Point of View 4 1. I can readily understand the software and where and how things happen; 2. When I change or add to part of the software, there are no unintended or poorly designed dependencies; 3. I can read the code without looking for tricks or poorly defined and labelled variables or data; 4. I donʼt need the person(s) that wrote the code to explain it to me; 5. There are a full set of (automated) tests to check that the function works as expected; 6. When I change something and add to the tests, I can check that the entire change and product continues to work; 7. How things work and hang together is tranparent; and, 8. Standard, well-known design principles have been adhered to.

5 Consequences of low value software to developers 5 Product Backlog Core Functionality Time New Functionality Core Functionality Most significant new functionality builds on it; Also called infrastructure and legacy software; Is fragile, doesnʼt have complete test harnesses, and few people still know how to or are willing to touch it; and, Requires more time to work on; velocity working on it is less than new work.

6 Where does core functionality come from? Is it bought from a malicious competitor? 6 Release 1 Product Backlog Done Velocity = 18 Undone Velocity = 36 Release 2 Time Product Backlog Done Velocity = 14 Undone Velocity = 30 Time

7 Or, do we built it ourselves?? 7 Release 3 Product Backlog Done Velocity = 8 Undone Velocity = 22 Release 8 Time 5 6 7

8 Exercise - your CEO comes to your development group. She tells you it is mandatory to deliver three new pieces of functionality within three Sprints. Otherwise, competitors will decimate the company. 8 Planned work consists of: 1. Function 1: 20 units of work, 15 new, 5 core 2. Function 2: 40 units of work, 25 new, 15 core 3. Function 3: 30 units of work, 20 new, 10 core Velocity for new functionality is 15 units of work per Sprint per team. Velocity for core functionality is 5 units of work per Sprint total. You need a release with all three functions in three months. Can do you do? Can you save the company?

9 9 Velocity in Core What are the smells a dying piece of software? 2000 New Requirements Capability What are the consequences to the organization? 1500 Requirements Year

10 Exercise : Five Minutes with Three People Near You 10 The Situation: You are a developer at xyz.co, building advanced life-critical products. Your Scrum team is one of seven teams working on a new release of one of the products. Your team is going to select requirements (product backlog) to turn into something that is done (no more work remains, potentially shippable) within a two-week iteration. Each team has all the skills to fully develop the requirements into a done increment. The Assignment: What work would you have to do to turn the requirements into a done increment? If you were developing a done, potentially shippable increment, what would your definition of done be? Would it include, for example, refactoring? What else?

11 Next Exercise : Five Minutes with Three People Near You 11 Did your definition of done include the following? If not, why not? Performance testing Stability testing Refactoring Immunological response testing Integration with the work of the other six teams Integration testing with the work of the other six teams so the increment is the totality of all seven teams Release notes Internationalization to the six cultures where the product will be sold User acceptance testing Regression testing Code reviews

12 Stabilization is when you do all the undone work 12 Scrum Project with complete, itegrated done P P D P D P D P D P D S Scrum project with incomplete or variable done S P P D P D P D P D Undone Undone Undone Undone Planning P D S Development Stabilization

13 13 Planned Release Date Defects in Release Release 1 Release 2 Time 120 people, 18 Scrum teams Release 1 : Each team produced done increments each Sprint, but they were not integrated or integration tested until code complete. Release 2: All teams produced an increment of integrated, integration tested code every Sprint.

14 The Scrum Framework is lightweight and full of holes Copyright 2010, Scrum.org, All Rights Reserved

15 Martin Fowler Calls Scrum Flaccid 14 There's a mess I've heard about with quite a few projects recently. It works out like this: They want to use an agile process, and pick Scrum They adopt the Scrum practices, and maybe even the principles After a while progress is slow because the code base is a mess What's happened is (people using Scrum) haven't paid enough attention to the internal quality of their software ( ) I've mentioned Scrum because when we see this problem, Scrum seems to be particularly common as the nominative process the team is following ( ) because Scrum is process that's centered on project management techniques and deliberately omits any technical practices. I'm sure that the many Flaccid Scrum projects being run will harm Scrum's reputation, and probably the broader agile reputation as well. 15 Martin Fowler, January 2009 Source:

16 16 BY EARLY 2009, MORE ORGANIZATIONS WERE USING AGILE PROCESSES THAN WATERFALL PROCESSES HOWEVER, LESS THAN 50% OF THOSE USING SCRUM WERE DEVELOPING IN INCREMENTAL ITERATIONS, WHICH ARE THE HEARTBEAT OF SCRUM. ONE OF THE BIGGEST CHALLENGES OF USING SCRUM HAS ALWAYS BEEN THE STEEP LEARNING CURVE FOR THE DEVELOPERS ON THE SCRUM TEAM. -- JEFF SUTHERLAND, KEN SCHWABER, MARCH 2010

17 Copyright , ADM, All Rights Reserved v1.3 17

18 17 18 Who, me?! Copyright 2010, Scrum.org, All Rights Reserved

19 What are you going to do about it? 19 But I m a developer, not a manager! Learn about Scrum Get hands-on Scrum training Measure your understanding Pass it on But I m a manager, not a developer! Learn about Scrum Get your teams handson Scrum training Measure their understanding Set a bar Copyright 2010, Scrum.org, All Rights Reserved

20 Improving the Profession of Software Development The Purpose of Scrum.org Maintain Scrum Offer Training Assess Knowledge Create and maintain bodies of knowledge on which to train and assess people for the betterment of software development. Work with experts in various technologies and fields to create a deliver courses that meet the needs of the software development profession. Continuously monitor quality. Offer rigorous assessments to allow people to evaluate their abilities so they are able to improve. Copyright 2010, Scrum.org, All Rights Reserved

21 21 Introducing the Professional Scrum Developer Program An innovate program for developers from Zuehlke and the founders of Scrum Including a training course, assessment, and certification Visit Scrum.org (

22 Four Pillars of the Professional Scrum Developer Program Learn how to: 1. How to work together as a crossfunctional, self-organizing team, 2. Using modern engineering practices, 3. On a modern technology stack, in a modern development environment, 4. To build a done increment within an iteration. Copyright 2010, Scrum.org, All Rights Reserved

23 Course Structure Mirrors the Strucure of Scrum 23 Teams iteratively build increments while learning more Scrum, teamwork, engineering techniques, and tooling each Sprint. They are allowed to fail and learn. 1.Start 2.Initiation 2.1.Form team 2.2.Course overview 2.3.Case study overview 2.4.IDE overview 2.5.Scrum overview 3.Develop product 4.Retrospective Engineering practices IDE technology stack Case study product backlog

24 24

25 25 Measure Understanding in Multiple Skills

26 Fundamental Knowledge of Scrum Development Questions 25

27 Fundamental Knowledge of Scrum Development Questions 26

28 Fundamental Knowledge of Scrum Development Questions 27

29 Fundamental Knowledge of Scrum Development Questions 28

30 30

31 31 Questions?