Forget velocity, Foster creativity. Harm harmpauw

Transcription

1 Forget velocity, Foster creativity Harm harmpauw

2 Who am I Technical Devon Scrum.org, isqi Former Software developer Passionate about making great software

3 Promise of Scrum You ll get more You ll get it faster

4 But often We re still struggling to meet deadlines It feels like we re doing something wrong It s not because don t have smart people

5 Focus on output We want to go faster, and velocity seems related to speed It s one of the few things we measure So we want the velocity to go up

6 Optimizing output Get rid of waste Interruptions Meetings Manual work

7 Increasing output is not going to save you There s a limit to improving efficiency Scrum isn t about efficiency, but about effectiveness If you push on velocity, you ll get story point inflation

8 Who s responsible for maximizing value? Product Owner Scrum Master Development team

9 Who s responsible for maximizing value? Product Owner Scrum Master Development team

10 Making tough choices Order work so that we work on the most valuable things first Choose what not to do

11 MVPs are often misused MVPs should be used to discover what your product needs to be all about MVPs are not a good tool to meet deadlines

12 Development isn t coding Coding & testing is just the production part of development There s also thinking about fit solutions for problems And this part has way more impact

13 Development team!= production team Development team is an innovation team They know the technical consequences of a solution best We should use their creativity to come up with fit solutions Not just to build a solution

14 There are always multiple solutions There s no perfect solution Choose a solution that s fit for purpose Functional and non-functional

15 Different solutions different sizes This difference can be a couple of orders of magnitude This is where you can make a difference as a team!

16 What can you do? 1. Allow for different solutions 2. Know when you need another solution 3. Create scarce 4. Learn from your experiences

17 ➊ Allow for different solutions

18 Define What instead of how Good user stories are: Independent Negotiable Valuable Estimable Small Testable

19 Define What instead of how Good user stories are: Independent Negotiable Valuable Estimable Small Testable

20 Alternative solutions over trimmed down solutions Uber Public transport Carpooling

21 Don t let architecture suffocate creativity Create boundaries with enough freedom within Allow for new insights

22 Don t let UX design suffocate creativity Wait with UX design till the last responsible moment (that means in the sprint) Make UX designer part of the team

23 Recap Allow for different solutions Define your problem, not a solution Prefer alternative solutions over trimmed down versions of a solution Don t let architecture or UX design block creativity

24 ➋ Know when you need another solution

25 When do you estimate?

26 Estimations are often Done once Done late in the process (sometimes during Sprint Planning) Only used for planning purposes

27 Use estimations as signals If it doesn t fit in the planning, start implementing a different solution If it just fits in the planning, start implementing a different solution too

28 But my initial estimations are inaccurate! Yes, but still accurate enough to use as signals Too big lot of risk You can still roughly check your business case

29 Recap Know when you need another solution Estimate early and multiple times Don t use estimations just for planning, but also as signals If you don t or just meet your planning, think about a different solution Inaccurate estimations are still usable

30 ➌ Create scarce

31 Parkinson's Law "work expands so as to fill the time available for its completion

32 Time to Create is a requirement Time to Create is a requirement, just like any other requirement

33 Artificially limit time and people By creating scarce, you are forced to think about: Different solutions The added value of your product and team: Which thing don t we need to build ourselves

34 There s the cost of maintaining too The more you ve built, the more you have to maintain

35 Recap Create scarce Create scarce to Focus on your added value Limit the maintenance costs of your solution

36 ➍ Learn from your experiences

37 Empirical Success isn t measured by how well we stuck to our initial plan We want to learn early and often And apply those learning in the subsequent work we do

38 Don t be afraid to choose a different solution once you started It s not failure, you just have new insights Be aware of the Sunk Cost fallacy

39 Choose solutions that are cheap to change Sunk costs play a lesser part Do it when there are a lot of uncertainties

40 Recap Learn from your experiences Learn early, often and apply those learnings Don t be afraid to throw things away Make solutions cheap to change

41 Conclusion Forget velocity - Don t just try to work harder or cut down features Foster creativity Deliver more value by choosing different solutions Get from a good production team to a great innovation team Learn and apply learnings

42 Take aways There s a limit to optimizing output MVPs are not a solution for meeting deadlines Alternative solutions over trimmed down version of solutions Use estimations as signals, not just for planning Create scarce for now (cost to build) and for later (cost to maintain) Changes should be cheap

43 Questions? Harm harmpauw