"Things to unlearn in software development" talk by Alexey Krivitsky for agile.sk

1. THINGS TO UNLEARN IN SOFTWARE DEVELOPMENT AlexeyKrivitsky, SCRUMguides.com for Agile Slovakia, 14 Jan 2010

2. 2 AlexeyKrivitsky Agile coach and Scrum trainer at SCRUMguides krivitsky@scrumguides.comtwitter.com/alexeykri Skype: alexeykrvGSM: +380.50.358.9212 Coordination of Agile Ukraine communitywww.agileukraine.org Agile Eastern Europe conferencewww.agileee.org Agile Base Camp conferencewww.agilebasecamp.org 2

3. The History of Vasa

4. The History of Vasa

5. The History of Vasa

6. The History of Vasa

7. The Reasons of the Tragedy A very important client Unrealistic plans Scope creep High technology risks Architectural flaws Acceptance testing failures The lead architect changed Wishful thinking Development priorities are not balanced Deployment-time mistakes Does all that sound familiar?

8. 350 Years Later… Ship construction body of knowledge has improved a lot New domains and industries were born Project Management became a science Why nearly four centuries later we are still facing the same issues in our domain?

9. 1

10. DILEMMA OFIMPORTANCE ANDRIGHTNTESS OF A CUSTOMER Hurry Gordon Selfridge said: «The customer is always right» But what if an important customer is not right?

11. Ignore employees’ preferences and comfort Unconditional agreement with customersmight lead to quality problems Employees’ motivation fades out Lowered quality of service

12. We accept unrealistic deadlines We agree on suboptimal solutions We let technical requirements to be dictated We are afraid to pose a denial In the end,the product will have our label Unconditional agreement with customers might lead to project failures

13. UnlearnTO BE UNDENIABLE Your 'yes' has no power if you do not know how to say 'no'

14. LearnTO COLLABORATE Start by saying «No!» to unacceptable conditions And then invite to seek for better solutions That are realistic Professional Lead to Win-win

15. THE AGILE WAY Maker customers a part of the team Rely on face-to-face collaboration Run iteration planning meetings altogether Run regular demonstrations Build in trust by releasing valuable functionality early Build in quality

16. 2

17. DILEMMA OFHARD PLANNING AND CONSTANT CHANGES Fixing requirements is like trying to pin a cloud Changes come inevitably

18. Project Scope Inevitably Changesbecause 1) Researches are made «the devil is in the details»

19. Project Scope Inevitably Changesbecause We often give our promises when we know too little

20. Project Scope Inevitably Changesbecause 2) Requirements are misunderstood

21. Project Scope Inevitably Changesbecause 3) Customers get new wishes and better ideas

22. Unlearn TO FIX PROJECT SCOPE [SCOPE] x [TIME] x BUDGET x QUALITY [SCOPE] x [TIME] x [BUDGET] x [QUALITY] [SCOPE] x [TIME] x [BUDGET] x [QUALITY] It is a «lose-lose» scenario

23. LearnTO MANAGE PROJECT SCOPE 1) Turn failures into learningby dividing projects into sub-projects Detail and nail down requirements only for the current sub-project Plan next sub-project based on experience of the previous ones

24. LearnTO MANAGE PROJECT SCOPE 2) Most likely you cannot do“all of it”so focus on the most valuable stuff On regular basis deliver the most valuable for business functionality Embrace changes to let business learn and create competitive advantages

25. THE AGILE WAY Let business set and change priorities for development at any time Let the Product Backlog growand evolve Work in time-boxed iterations Have a detailed plan for the current iteration Have a potentially shippable product increment after each iteration Measure and use Team Velocity in planning

26. 3

27. THE PROBLEM OF OVER-ENGENEERING By trying to avoid changeswe tend to develop universal solutions Big Requirement Up Front (BRUF) Big Design Up Front (BDUF)

28. Unlearn TO TARGET FOR UNIVERSAL ARCHITECTURE It is impossible to foresee everything

29. LearnTO LET CHANGES HAPPEN AT MINIMAL COSTS Cheap - Simple Design Safe - Automated Test Suites With no Constrains - Refactoring Let the system architecture grow together with product knowledge

30. THE AGILE WAY Start development as early as possible Choose the simplest solutions that will work Reduce waste Zero-bug development strategy Root-cause analysis for each bug found

31. Do You Use Test-Driven Development Refactoring Continuous Integration

32. Some People Say «I ain’t need no unit-tests, I can write quality code without them» «I have no time for refactoring, that’s why I write correctly in the first place»

33. 4

34. THE PROBLEM OF PROFESSIONAL CARELESSNESS Happens each time one does not think How the codebase will look like in ½ year What will happen to the codebase once we leave the project About the people who will support the product

35. UnlearnPROFESSIONALISM = BRAVERY

36. LearnPROFESSIONALISM = SAFETY

37. LearnPROFESSIONALISM = SAFETY 1) CARE ABOUT YOURSELF - TDD - Refactoring- Continuous Integration Write code so that once in maintenance you can send yourself a card on a Thanksgiving day

38. What Developers Do? Read code Write code

39. What Developers Do? Read code 90% Write code 10%

41. THE AGILE WAY Pay attention to high quality standards of development Define Done-Done criteria of features to include: automatic build, unit testing, refactoring, customer acceptance “Let the chief control the kitchen”

42. 5

43. THE PROBLEM OF A STANDARD PROCESS When do we usually decide on a methodology?

44. THE PROBLEM OF A STANDARD PROCESS The danger of standard process is that peoplewill miss chances to take important shortcuts T. DeMarco, T. Lister

45. UnlearnTO RELY ON A STANDARD APPROACHthat would solve all possible problems There is a wide range of proposals on the «market»: CMMI,RUP,XP,SCRUM …

47. Requirements and implementation

48. Product releases and marketLearnTO BUILD AN ADAPTIVE META-PROCESS

49. LearnTO BUILD AN ADAPTIVE META-PROCESS Putting the culture of continuous improvement to the basement of the process

50. LearnTO BUILD AN ADAPTIVE META-PROCESS Building your own process and keeping adapting it based on learning

51. LearnTO BUILD A META-PROCESS Best practices Good practices

52. THE AGILE WAY Make all problems visible by not allowing to break rules, such as: working in fixed length iterations conducting public demonstrations at the end of each iteration Run retrospective meetings at regular intervals Plan for process experiments

53. To Unlearn ->To Learn To be undeniable -> To collaborate To fix project scope -> To manage project scope To target for universal architecture-> To let changes happen at minimal costs To mismatch professionalism with bravery -> Match professionalism with safety To rely on a standard approach -> To build a meta-process

54. Have a Safe Journey! S C R U M g u i d e s