Software management...for people who just want to get stuff done
Download as PPTX, PDF2 likes1,123 views
This document discusses concepts and techniques for software project management, including planning, estimation, execution, and retrospectives. It covers these concepts at the level of projects, milestones within projects, sprints, and individual stories. Key points emphasized include breaking work into small chunks, using techniques like planning poker and burndown charts, being honest about estimates, and using retrospectives to improve.
Software management...for people who just want to get stuff done
- 1. Software Management …for people who just want to get stuff done.
- 2. But I Never Want to Be a Manager!
- 3. Planning Estimation Execution Retrospective Project Milestones Sprints Stories Software Management Dimensions
- 4. Definitions Planning Estimation Execution Retrospective Project Milestone Sprint Story
- 5. Planning Estimation Execution Retrospective Waterfall Project Milestones Sprints Stories
- 6. Planning Estimation Execution Retrospective Agile Project Milestones Sprints Stories
- 7. Planning
- 8. All Plans are Wrong “No plan of operations extends with certainty beyond the first encounter with the enemy's main strength.” - Helmuth von Moltke the Elder “No software plan extends with certainty beyond the first component interaction, or the first unknown technology.” - Cliff McCollum
- 9. Planning Techniques Dependency Planning Critical Path Analysis Alternative Delivery
- 10. Estimation
- 11. All Estimates are Flawed The goal is to eliminate your biases in a systematic way. Can you make half of your estimates too low and half of them too high? In effect, can you average your errors to zero?
- 12. Estimation Techniques Rely on the expert Planning Poker The 50th Percentile Rule Monte Carlo Simulations Fudge Factors
- 13. Execution
- 14. All Execution is Hard Worst challenge is what you don’t know All development is learning Don’t lie to yourself or others
- 15. Execution Techniques Design Reviews / Code Reviews Pair-Coding Daily Standups / Reporting TDD / MDD / Continuous Integration Issue Tracking / Shared Documentation Knowledge Discovery
- 16. Projects
- 17. Project Planning Consider separate items of business value. Deliver them one at a time. Don’t interleave all your business value.
- 18. Project Estimation The further away a deadline is, the less precise it becomes. Expected Duration Date Accuracy One Week +/- one day One Month +/- one week One Quarter +/- one month Six Months +/- two months One Year +/- six months > One Year +/- Unknown You should not estimate > 1 year out.
- 19. Project Estimation Always plan to produce something useful in less than six months. Even better, do it in one quarter.
- 20. Project Execution • I don’t suggest thinking much about Dev at this level. • This is where you consider marketing, communications, etc. • Biggest value is watching Tech Milestones.
- 21. Project Retrospective • Too high-level to be of much value – unless you plan to write a book
- 22. Milestones
- 23. Milestone Planning Milestones Can exist at multiple levels. Group stories in Business-Value sets, with natural tech chunks below that.
- 24. Milestone Estimation Easiest performed as a roll-up of the Stories underneath each. Add fudge-factors at this level.
- 25. Milestone Execution Track each story regularly. Ideally daily. Burndown charts should be used here.
- 26. Milestone Retrospective When a date is missed, it is time to be brutally honest. Why was it missed? What is the impact? What are you going to change? Don’t tell lies.
- 27. Milestone Retrospective Why was it missed? New knowledge? Difficult problems? Changed business situation? Team problems?
- 28. Milestone Retrospective What is the impact? Slip the schedule? Cut scope? Add resources?
- 29. Milestone Retrospective What are you going to change? Don’t tell yourself lies. If your estimates were wrong here – they are probably wrong everywhere else. Working harder is a poor solution. Hope is not a strategy. You must accept one of the previous impacts. What do you change about future milestones?
- 30. Sprints
- 31. Sprint Planning Keep your backlogs aligned to your Milestones Don’t change a planned sprint
- 32. Sprint Estimation What is your team velocity? How do you know? Stretch a little. Leave space for the unexpected.
- 33. Sprint Execution Use Burndowns and Daily reviews. If you are above the line, find out why immediately. Address blockers before anything else.
- 34. Sprint Retrospective Lots written about this. Don’t skip them.
- 35. Stories
- 36. Story Planning No story should be larger than one person can complete in one sprint.
- 37. Story Estimation If you code it, you estimate it. Break stories down into tasks and estimate those. Follow the 50th percentile rule.
- 38. Story Execution Don’t lie to yourself: update your estimate every day.
- 39. Story Retrospective Probably not useful.
- 40. Q&A
Editor's Notes
- #3: If you develop software, you are either your own manager, you work for a manager, or you desperately need a manager. No sufficiently complex endeavor can be undertaken without management unless you never care when, how, or if it finishes.
- #4: Every software development process executes on these dimensions. Different methods emphasize some areas more than others, but none of these go away regardless of your method.
- #6: Every software development process executes on these dimensions. Different methods emphasize some areas more than others, but none of these go away regardless of your method.
- #7: Every software development process executes on these dimensions. Different methods emphasize some areas more than others, but none of these go away regardless of your method.
- #20: Don’t believe anyone who says they have a plan whose first deliverable is more than six months out. Just walk away. Or find smaller deliverables.