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?
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
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
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»
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
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
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”
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 …
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