"We are doing it wrong."

  • Published on
    27-Jun-2015

  • View
    276

  • Download
    3

Embed Size (px)

DESCRIPTION

"We are doing it wrong" - Aspects of modern Software Development Project Management.

Transcript

<ul><li> 1. We are doing it wrong.10th international TYPO3 conference!Robert Weigraeber, aexea</li></ul> <p> 2. /meRobert WeigraeberPrincipal @ aexea 3. what we do:Diesel EXPOSURE LOW - Sneaker - blackI love jeans! These black EXPOSURE LOW sneakers by Diesel areavowed fans of denim and therefore come in a trendy jeans look, asreflected by the traditional denim elements, for instance the coinpocket, the typical rivets and a deep pocket. A declaration of love forthe popular denim look: Diesel EXPOSURE LOW sneakers in black.x10000x!"#$%&amp;' 4. !@robert_we#foodkoma 5. #NoEstimateshttp://www.pleacher.com/mp/mgifs/gifs16/imp.jpg 6. We are doing it wrong.This talk may contain subversive ideas. You have been warned.Do try this at home. 7. We are doing it wrong.!Aspects of project management in modern software development. 8. ?Why do we need to change something? 9. Technology adaption rate is getting stellar.Graphic: Technology adaption rate in the US (Consumer Technologies,10-90%).Adoption Rates of Consumer Technologies: commercekitchen.com 10. Technology life cycles go down.Graphic: Duration of technologies as growth pulses (Consumer Technologies,10-90%).Adoption Rates of Consumer Technologies: commercekitchen.com 11. Can you deliverfast enough?past? present? future?Maersk Agile Journey. 12. Rethink the role of software in your business. Separation of software &amp; business? Software solutions in a support role or as a solution in its own right? Adoption of mega-trends? Secure? Software as game changer? 13. Today every company is asoftware company. That includesJohn Deere and Nordstrom.@barry_crist (CEO @ Chef) 14. There will be no4th IndustrialRevolution.The evolution is already here.And its not coming with a versionnumber attached anymore.Industry 4.0 Graphic: http://www.siemens.com/annual/13/en/company-report/report-industry-solutions/strategic-context/img/130E_StrategieUSA_E_Grafiken02_%5BWeb%5D.pngJenkins Logo Adaption: http://www.praqma.com/sites/default/files/cool-jenkins2x3.png 15. Not every systemis mission critical.If you dont care about yourbrand or (possible) employees. 16. http://mkhmarketing.files.wordpress.com/2013/01/orange-keep-calm-sign.png 17. 1Metaphors.Our analogies are wrong. 18. hdwallpapersinn.com 19. http://www.maurerunited.nl/wp-content/uploads/2009/07/090731_day_1024x768.jpg 20. Create theImpossible.You are not limited to physicalboundaries.http://www.mcescher.com/gallery/impossible-constructions/waterfall/ 21. other analogies &amp; metaphors building a bridge comparing software to art sports metaphors gardening, landscaping 22. 2Extensive Process Governance 23. What we do: We want predictive and reliable software releases Long term plan/backlog of features High Inventory on Ideas &amp; Work in Progress Extensive prioritization and contracts Risk aversion by agent Linear process with multiple sign offs 24. 3Optimizing on Resource Utilization.*: resource = human people 25. Resource Planning! Backlog of work / orders Long time commitment Committed salaries/resources Resource planning as system process*: resource = human people 26. Client/Business fast implementation costs problem fitting software (the rightone)!! the way we work together has tointegrate with how our companyworksDev Shop/Agency getting paid averting risks mid/long term commitment! we have more problems findingdevelopers than fitting projectsDev Team making a difference by deliveringmeaningful software working with experts craftsmanship, clean code salary, job security, ! live is too short for bad jobsConflict of Interest? 27. Stefan Roock 28. Little's lawThroughput*: resource = human peopleWork in ProgressLead Time= 29. Little's law*: resource = human peopleWork in Progress=ThroughputLead Time 30. Cycle Time as aFunction ofUtilization (andBatch Size)leanessays.com30xCycle Time01IIIIIResource Utilization: 40% 60% 80% 100% 31. Reduced Lead time delivering fast is valuable increases throughput faster payout enables a faster delivery of value (testable on fit) reduced risk shorter feedback cycles (e.g. cash flow) can replace planningprocessesNeeded Changes minimize Work in Progress (wip limit, process steps) Focusing on flow instead of utilization smaller batch sizeWhere is the $$? 32. 4HeijunkaChoosing a non-adaptive technique for non-standardized activities. 33. Value Chain und Work in Progress.*: resource = human peopleWork in Progress=ThroughputLead Time 34. Architecture / DesignNeeds LiveSoftware Development Value Streamsoftwarecreation.orgFeatureAnalysis / RequirementsProgrammingTesting / AcceptanceDeployment / DeliveryCustomer not availableBusiness ApprovalExcessive up-frontarchitectureDesign approvalMeetingsOver-engineeringDevelopers involvementin other ProjectsFixing BugsRedoing because ofincorrect requirementand stressDeferred Integration Debt 35. Software Development Flowcut back on sitting idle waiting for somebody to work on itfast exchange of information move design, code and information fast link processes and people together to make problems surfaceright away remove linear sequences 36. One-Piece Continous Flow. Citrix Online applied this pattern at the enterprise level and reduced release cycles from 42 months to less than 10months resulting in substantial gains in market share for their products.scrumplop.org 37. All the brilliant minds working on!the same thingat the same timein the same spaceon the same computer!just like a real mob.! Woody ZuillIt exists. its called Mob Programming. 38. 5Projects.Moving #BeyondProjects.Start thinking small: Diseconomies of Scale. 39. a Project a temporary organization to achieve predefined result at a pre-specified time using predetermined results.Success Criteria On Schedule On Budget On Quality (~ Features)Assumptions The Value is knowable (at the start) There is no value in flexibility.Intrinsic Properties 40. Delivering on schedule, budget &amp; featuresis a sign of failure, not success.Allan Kelly, #NoProjects@allankellynet 41. We makedecisions, whenwe know theleast.DecisionImpactTime in ProjectKnowledge LearnedStuff 42. Projects are, where softwaregoes to die.Successful Software does not end.http://www.dorkly.com/post/1243/pacman-graves 43. Software is state, not result. Treat everything as Service Creation &amp; Service Delivery Dont limit your options by long-term determination 44. Bring work to stable teams Create stable performing teams Close to the business Bring the work to the team Manage different teams as queues with capacity, not via queue switching. 45. 16%16%3% 3% 4% 5%1 2 3 4 5 6 7 8 9 10 11 12 13 143% 3% 4% 5%Requirement12%6% 5%7%12%1% 1%21%3%1 2 3 4 5 6 7 8 9 10 11 12 13 14Figure 2. The value distribution of the 14 requirements in the RAN project.RequirementValue (percent)Value (percent)201510502015105012%6% 5%7%12%1% 1%21%3%Figure 2. The value distribution of the 14 requirements in the RAN project.Requirement6The Value Distribution of Requirements in a Project is not linear.discussion,re-quirementsactu-allyuseforSystemsComputerLinkpingjointandphasesAsJanuaryin-dustry-per-formingin-dustrialstudy,Accesswas tofor ainfor-mationsystemsmall,ournow anresearchusing the costvalue approach.We asked a group of experienced pro-jectmembers to represent customersviews and carefully instructed them onRequirementimplementation cost.We let the participants work with therequirement pairs in any order they chose,allowing for retraction during the com-parisonCost (percent)201510501% 2% 3% 4%6%11%4%6% 7%12%4%6%23%10%1 2 3 4 5 6 7 8 9 10 11 12 13 14Figure 3. Estimated cost of requirements implementation in the RAN project.Requirements 6, 10, 13, and 14 constitute 56 percent of the total implementation costs.discussion,re-quirementsactu-allyuseforSystemsComputerLinkpingjointandphasesAsJanuaryin-dustry-per-formingin-dustrialstudy,Accesswas tofor ainfor-mationsystemsmall,ournow anresearchlevelthehigh-levelusing the costvalue approach.We asked a group of experienced pro-jectmembers to represent customersviews and carefully instructed them onprioritizing requirements, making pair-wisecomparisons, choosing the scale tobe used, and deciding how many com-parisonswould be needed. We also ex-plainedimplementation cost.We let the participants work with therequirement pairs in any order they chose,allowing for retraction during the com-parisonprocess. The session was notmoderated and participants worked attheir own pace. Discussions were allowed,though in fact there were very few.Cost (percent)201510501% 2% 3% 4%6%11%4%6% 7%12%4%6%23%10%1 2 3 4 5 6 7 8 9 10 11 12 13 14Figure 3. Estimated cost of requirements implementation in the RAN project.Requirements 6, 10, 13, and 14 constitute 56 percent of the total implementation costs.a ratio scale. This means that a require-mentwhose determined value is 0.10 istwice as valuable as a requirement with adetermined value of 0.05. Moreover, thesum of all requirements value measures is1, 2, 3, and 11accountfor only 10 percent. Looking again at theextreme values, requirement number 13is about 20 times as expensive to imple-mentas requirement number 1.12, reduced by that cost CASE THE and a second that Performance mobile project of 15 of 5 15Value (percent)25201510500 10 20 25Cost (percent)1 52437911 121410138Figure 4. Costvalue diagram for the RAN project requirements. By not implement-ingthe requirements that contribute little to stakeholder satisfaction, such as 10, 11, and12, you can significantly reduce the cost and duration of development.Karlsson/Ryan: a cost-value approach for prioritizing requirements, IEEE 1997 46. Reduce Batch Size Elephant carpaccio, hamburger method identify non-linear value distributions early, provable value delivery enables options by selection create portfolio of options! Deliver features, not projects. 47. 6Investment Decisions 48. Estimating software is fed from our believein the omnipotence of project managers.#NoEstimates 49. Software development is alearning process.!Working code is a side effect.Learning is non linear.- Alberto Brandolinihttp://www.astro.princeton.edu/~jstone/images/sp.gif 50. Cost of DelayEnd dates are bad.Deadlines are good. 51. Technical debt is not like debt with thebank. It's debt with the mob.- Alberto Brandolini (@ziobrando) 52. 7Doing things, that aretechnically possible. 53. What is Done?Software that's out in production doing its job.Anything else is just self-delusion. 54. blog.endpoint.com stackoverflow.com blog.spearce.org 55. Continous Delivery should be a mutual interest of everyone.http://electric-cloud.com/blog/2014/10/the-big-bang-and-why-we-are-here/ 56. Released software starts delivering value.ValueTime / Releases Time / ReleasesValue 57. The software is ready forrelease. Every singlemoment. 58. ContinousDelivery requiresautomation.wikipedia.com 59. (Poka Yoke) 60. If Google has no branches, why do youthink you might need them?Amazon releases to production every 11.6 seconds.(Number from May 2011) 61. Summary 62. Work with aligned interests.Trust in working together. Make everything transparent. 63. Do valuable software.Meaningful software is far beyond some %s. Change the game. 64. Deliver early and continuously.Deliver value and make it provable. 65. Focus on flow and service state.Flow, throughput, velocity, flexibility. 66. Thank you.Robert Weigraeber, @robert_we </p>