Downloaded 21 times
Uploaded byJames Peckham
Kens Scrum Presentation
The document discusses several key aspects of Scrum: 1. Scrum is a framework based on empirical process control that was developed from lessons learned by companies like Toyota. It focuses on transparency, inspection, and adaptation. 2. Scrum provides a framework for self-organizing cross-functional teams to deliver working software frequently in short iterations with a "Done" definition. 3. Common reasons cited for Scrum failures include underlying problems in the organization already existing prior to adopting Scrum, as well as unwillingness to change engineering practices or deliver working code each iteration.
Kens Scrum Presentation
- 1. What is ScrumStolen from Ken Schwaber’s google video presentation
- 2. scrum Not anacronym Rugby Collection of best ideas from profession
- 3. Takeuchi and NonakaStudy Fuji Toyota 3m Xerox Had competitive responses to encroachment of marketshare
- 4. Team of verybest people Cross functional team Rounded solution Asked them to come up with competitive response
- 5. Smalltalk to newIDEs Marketplace adoption of scrum came about because of newer IDEs and automation of testing.
- 6. XP engineering practicesScrum as product management Xp as engineering practices that fit with scrum to support the scrum framework
- 7. Scrum is nota methodology Not a silver bullet You can’t turn to the page to solve a problem Scrum is a small framework that’s simple “think of chess”
- 8. Agile is ‘verygood’ With good engineers Scrum works with anyone. Crap every iteration right on time!
- 9. Know where youare! Sarbanes oxley borrowed transparency from scrum. Where are we at the end of the timebox.
- 10. Have something “Done”Coding standards Refactored Unit tested Documented Integrated Acceptance tested What all do you have to do at your company to get “Potentially Shippable”
- 11. The bank storyReplacing trust system 28 legacy core feeds New UI Keep your job… don’t use scrum here.
- 12. Scrum framework. It’snot complex, but it is difficult
- 13. And a fewrules Inspect or adapt loop (empirical) Every day “make transparent where you are” “Done”
- 14.
- 15. Single wringable neck!Person makes decisions for every single release. Comparing where they are to where they want to be Makes decisions! Accountability to the sponsor
- 16. The news problemAre you going to do something about it?
- 17. Time-honored traditions Plastercode in without refactoring Skip unit tests Skip acceptance tests Work long hours!
- 18. High moon studiosSammy sega was the original owner Use scrum Sustainable pace Japan says 12-14 hour days! 60% increase in defects Cost more than offset functionality
- 19. Core software ‘problem’Our velocity 24 Core velocity 10 Multiple dev teams for new functionality
- 20. Common things FragileNo automated tests Few ‘suckers’ left to work on it
- 21. PRDs & MRDs65% of functionality maintained and sustained is rarely used.
- 22. PRDs changing Standowner up against the wall…. We’ve forced them to not only spit out a bunch of feature with little or no value, but also ‘fearful’ of changing our minds.
- 23. Scrum master Aka“the prick“ Makes sure you don’t cut quality No authority If we’ve defined “Done” to be demo-able their job is to make sure it’s there.
- 24. Hopeless professional areasUse to doing incredible things with no respect, no authority, and no hope that it will ever get done.
- 25. Non-functional requirements ArchitecturalDesign Deliver ‘something’ demonstrable.
- 26. Scrum failed! Why?Put the framework in place Try to understand the problems that are being uncovered were already there! Unwillingness for the company to let engineers do their job (self direction) Unwillingness of engineers to improve engineering practices Unwillingness or inability for engineers to deliver ‘potentially shippable’ code every iteration Dedication to software and engineering.