Download as PDF, PPTX
More Related Content
![Qcl 14-v3-[flowchart of admission process]-[banasthali vidyapith]-[swati sharma]](https://cdn.slidesharecdn.com/ss_thumbnails/qcl-14-v3-flowchartofadmissionprocess-banasthalividyapith-swatisharma-141228021941-conversion-gate01-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Crash Course Scrum - handout
Crash Course Scrum - handout
- 1. Crash Course Scrum •Hugo Messer: Trainer Ekipa.co • Arjan Franzen: Trainer ZEN software
- 2. • The “spaghetti”Game • Manager vs Team (self) Power of self organization
- 3. ToDo In ProgressDone Who are we Lean Theory Kanban Scrum Ceremonies Artifacts Roles Overview Scrum
- 4. Who are we? •Arjan Franzen • In professional software engineering since 2000 (hobby since I was 9) • Titles & Roles: Engineer, Lead Engineer, Architect, Development Manager, Scrum master, Agile Coach • Cheering agile since 2005, lean since 2010 • Hugo Messer • MBA Erasmus in Rotterdam • 2005: Start Bridge • 2008: lived in India 1,5 years • 2005-2010: cried many times • 2014: Wrote 6 books about managing remote teams • 2015: Ekipa.co & start workshops to help others
- 5. ToDo In ProgressDone Who are we Agile Theory Lean Kanban Ceremonies Artifacts Roles Overview Scrum
- 6. What have wetried so far? •Waterfall •V-Model •RUP •Scrum •Statistics are against us here: • Normal distribution? No!
- 7. Repeat the samesolution
- 8. The Agile Manifesto– a statement of values (2001) Process and toolsIndividuals and interactions over Following a planResponding to change over Source: www.agilemanifesto.org Comprehensive documentation Working software over Contract negotiationCustomer collaboration over
- 9. ‘Elaborateness’ Agile methodologies compared(Roles, Activities & Artifacts) 120+ 13 9 6 0 RUP XP Scrum Kanban Whatever More adaptiveMore prescriptive
- 10. Agile & ScrumCompared “ Scrum is an implementation for software projects that follows the values of the agile manifesto.”
- 11.
- 12.
- 13. Product Stakeholders Product Owner Team Agile LeanStartup DevOps Scrum Lean Roles Happy Customer
- 14. Lean Thinking • Eliminatewaste • Build quality in • Create knowledge • Deliver as fast as possible • Defer commitment • Respect people • Optimize the whole
- 15. Agile & LeanCompared Agile and Lean are not exactly defined but rather are principles and practices “ Agile focuses on well organized process which allows frequent delivery which makes it easy to adjust the course of development” “Lean focuses more on limiting waste (Inc. WIP which is a waste) and making production and delivery workflow efficient”
- 16. ToDo In ProgressDone Who are we Agile Theory Lean Kanban Ceremonies Artifacts Roles Overview Scrum
- 17.
- 18.
- 19.
- 20. • Kanban (method)= approach to incremental, evolutionary process improvement for organizations = change management tool = managing flow • Scrum = an iterative and incremental agile software development framework for manageing software projects and products or application development (managing iterations) Compare Scrum to Kanban
- 21. • Limit workin Progress (WIP) • Visualize the workflow • Manage flow • Make policies explicit • Implement feedback loops • Improve Collaboratively, evolve experimentally (Scientific Method) Kanban is Simple has only 6 key principles
- 22. Limit Work Inprogress (WIP)
- 23.
- 24. • I.E: Onlystart when existing work is complete • Predictable stream of work Manage Flow
- 25.
- 26. ToDo In ProgressDone Who are we Agile Theory Lean Kanban Ceremonies Artifacts Roles Overview Scrum
- 27.
- 28. Sprints • Scrum projectsmake progress in a series of “sprints” • Typical duration is 2–4 weeks or a calendar month at most • A constant duration leads to a better rhythm • Product is designed, coded, and tested during the sprint
- 29. Sequential vs. overlappingdevelopment Source: “The New New Product Development Game” by Takeuchi and Nonaka. Harvard Business Review, January 1986. Rather than doing all of one thing at a time... ...Scrum teams do a little of everything all the time Requirements Design Code Test
- 30. No changes duringa sprint • Plan sprint durations around how long you can commit to keeping change out of the sprint Change
- 31. ToDo In ProgressDone Who are we Agile Theory Lean Kanban Ceremonies Artifacts Roles Overview Scrum
- 32. Product owner • Definethe features of the product • Decide on release date and content • Be responsible for the profitability of the product (ROI) • Prioritize features according to market value • Adjust features and priority every iteration, as needed • Accept or reject work results
- 33. The ScrumMaster • Representsmanagement to the project • Responsible for enacting Scrum values and practices • Removes impediments • Ensure that the team is fully functional and productive • Enable close cooperation across all roles and functions • Shield the team from external interferences
- 34. The team • Typically5-9 people • Cross-functional: • Programmers, testers, user experience designers, etc. • Members should be full-time • May be exceptions (e.g., database administrator)
- 35. The team • Teamsare self-organizing • Ideally, no titles but rarely a possibility • Membership should change only between sprints
- 36. Cross functional team •Multiple ‘Hats’ • Web Developer ‘Hat’ • Test ‘Hat’ • Delivery Engineer ‘Hat’ • Code Analysis ‘Hat’ • Design ‘Hat’ • Database ‘Hat’ • Operations ‘Hat’ • Security ‘Hat’
- 37. ToDo In ProgressDone Who are we Agile Theory Lean Kanban Ceremonies Artifacts Roles Overview Scrum
- 38. •Sprint Planning •The Dailyscrum •Sprint Review •Sprint Retrospective •Backlog refinement (grooming) Scrum Ceremonies
- 39. Sprint planning • Teamselects items from the product backlog they can commit to completing • Sprint backlog is created • Tasks are identified and each is estimated (1-16 hours) • Collaboratively, not done alone by the ScrumMaster • High-level design is considered As a vacation planner, I want to see photos of the hotels. Code the middle tier (8 hours) Code the user interface (4) Write test fixtures (4) Code the foo class (6) Update performance tests (4)
- 40. Sprint planning meeting Sprintprioritization • Analyze and evaluate product backlog • Select sprint goal Sprint planning • Decide how to achieve sprint goal (design) • Create sprint backlog (tasks) from product backlog items (user stories / features) • Estimate sprint backlog in hours Sprint goal Sprint backlog Business conditions Team capacity Product backlog Technology Current product
- 41. 2 Sprints anda backlog (Jira)
- 42. The daily scrum •Parameters • Daily • 15-minutes • Stand-up • Not for problem solving • Whole world is invited • Only team members, Scrum Master, product owner, can talk • Helps avoid other unnecessary meetings
- 43. Everyone answers 3questions • These are not status for the ScrumMaster • They are commitments in front of peers What did you do yesterday? 1 What will you do today? 2 Is anything in your way? 3
- 44. The sprint review •Team presents what it accomplished during the sprint • Typically takes the form of a demo of new features or underlying architecture • Informal • 2-hour prep time rule • No slides • Whole team participates • Invite the world
- 45. Sprint retrospective • Periodicallytake a look at what is and is not working • Typically 15–30 minutes • Done after every sprint • Whole team participates • Scrum Master • Product owner • Team • Possibly customers and others
- 46. Backlog refinement (grooming) •Checkpoint •Makestories better •Product owner + Team
- 47. Start / Stop/ Continue • Whole team gathers and discusses what they’d like to: Start doing Stop doing Continue doing This is just one of many ways to do a sprint retrospective.
- 48. ToDo In ProgressDone Who are we Agile Theory Lean Kanban Ceremonies Artifacts Roles Overview Scrum
- 49. Artifacts •Product backlog •Sprint Goal •SprintBacklog •Burndown chart •Definition of Done
- 50. Product backlog • Therequirements • A list of all desired work on the project • Ideally expressed such that each item has value to the users or customers of the product • Prioritized by the product owner • Reprioritized at the start of each sprintThis is the product backlog
- 51. A sample productbacklog Backlog item Estimate Allow a guest to make a reservation 3 As a guest, I want to cancel a reservation. 5 As a guest, I want to change the dates of a reservation. 3 As a hotel employee, I can run RevPAR reports (revenue-per-available-room) 8 Improve exception handling 8 ... 30 ... 50
- 52. The sprint goal •A short statement of what the work will be focused on during the sprint Database Application Financial services Life Sciences Support features necessary for population genetics studies. Support more technical indicators than company ABC with real-time, streaming data. Make the application run on SQL Server in addition to Oracle.
- 53. Managing the sprintbacklog • Individuals sign up for work of their own choosing • Work is never assigned (push vs pull) • Estimated work remaining is updated daily
- 54. Managing the sprintbacklog • Any team member can add, delete or change the sprint backlog • Work for the sprint emerges • If work is unclear, define a sprint backlog item with a larger amount of time and break it down later • Update work remaining as more becomes known
- 55. A sprint backlog Tasks Codethe user interface Code the middle tier Test the middle tier Write online help Write the foo class Mon 8 16 8 12 8 Tues 4 12 16 8 Wed Thur 4 11 8 4 Fri 8 8 Add error logging 8 10 16 8 8
- 56. A sprint burndownchart (jr)
- 57. A sprint burndownchart (sr)
- 58. Hours 40 30 20 10 0 Mon Tue WedThu Fri Tasks Code the user interface Code the middle tier Test the middle tier Write online help Mon 8 16 8 12 Tues Wed Thur Fri 4 12 16 7 11 8 10 16 8 50
- 59. Definition of Done •Stories allowed to move to done when they comply to this definition • “Done” or “Done Done” • Example: • Code Complete • Unit tests written and executed • Integration tested • Performance tested • Documented (just enough)
- 60. ToDo In ProgressDone Who are we Agile Theory Lean Kanban Ceremonies Artifacts Roles Overview Scrum
- 61. Scrum in Practice:Help a city planner
- 62. • Form teamsof 4-6 people • Each Team 1 lego box • There is 1 Product Owner (who is also a trainer) Scrum in Practice Rules
- 63. • Pre-game (50min) • Organizing teams • Defining the Process • Project chartering • Building the Backlog • Estimating • Game (3 sprints) • Sprint Planning (3min) • Sprinting (7min) • Sprint Reviewing (5min) • Post-game • Debriefing Phases
- 64. • All teamswill be building a single product – they are not competing, rather they work for the same vendor. • The product is a CITY with certain features. • The main building elements are LEGOs, though any other material can be used in addition. • The PO is the main decision maker of the product – it is my city. • I will be involved in the development process by being available to answer questions and provide feedback. Goals
- 65. What to build •1 storey-buildings (several) • 2 storey-buildings (several) • Shop • School • Hospital • Kindergarten • Bus Stop • Intersection • Park • River • Bridge
- 66. Debriefing • What didyou observe? • How did it feel being on a scrum team? • How did the short iterations go? • How accurate were the estimations (provided the Release Burndown is there) • What would we have done differently from the beginning, if we had another chance to play the game? • How did it feel after the first sprint when almost all items required re-work? • What did the scrum master do? • How will your strategy change, if you know the Product Owner is unavailable during sprints? • How did inter-team communication go? Where there any dependencies? How were they resolved? • What did students learn?
- 67.
- 68. Scalability • Typical individualteam is 7 ± 2 people • Scalability comes from teams of teams • Factors in scaling • Type of application • Team size • Team dispersion • Project duration • Scrum has been used on multiple 500+ person projects
- 69. Scaling through theScrum of scrums
- 70. Scrum of scrumsof scrums
- 72. To DevOps Customer Delivery team Constantflow of new features into production Operation + Release Analysis + Design Integration + QADevelopment Testing + DemonstrationCustomer Centralized QA Centralized IT Operations Agile team The Last Mile
- 73. “If it hurts,do it more often” Infrequent releases Effort peaks, High risk Change Time Frequent Releases Smaller releases, Less risk Change Change Time
- 74. Development / DevOpsCulture • Continuous Improvement • Ideas are experimented with (Kata) instead of squashed • Feedback instead of fire fighting • Visualized overview instead of unread documents • Team Autonomy instead of Centralized control • Eliminate all costly work handover • Context , not Control • Tribes, Guilds, Chapter • System owners/ Architects • Loosely coupled & tightly aligned
- 75. Is it Continuous •‘How long does it take to change a single line of code?’ • Small releases • Continuous Integration • Branching/Merging • Continuous Deployment • Automated tests • DevOps
- 76.
- 77. Agile Software Requirements •Use Cases, User Stories • S.M.A.R.T • Specific • Measureable • Attainable • Relevant • Timely • Lean Startup (Customer Development)
- 78. Problems with UserStories: Actors 83
- 79. 84 uc my realUser Story Administrator User General requirement Configure recorder Record Stuff External System Interface with recorder My Real User Stories: Roles and Systems
- 80. User Story • Alwaysuse the Narrative • Always describe the benefit • User Stories in central location (not email) • Dan North article
- 81. User Stories: Pitfalls •Describe the problem, not the solution • As a Home owner • I want to Shovel Snow • So that I can get out of my driveway to get to work • Problems! • Better: • As a home owner • I want my driveway to be cleared of snow • So that I can drive in and out of my driveway to get to work
- 82. 1. Focus onthe user 2. Use stories to facilitate a conversation 3. Story writing is teamwork 4. Keep your stories simple and concise 5. Progressively decompose 6. Don’t forget the acceptance criteria 7. Consider grouping user stories into themes 8. Use paper cards 9. Keep your stories visible 10. Some things aren’t stories Roman Pichler’s 10 tips for user stories
- 83. Suggested Reading Page 88 ContinuousDelivery, Lean & DevOps
- 84. Thank you! • http://blog.ekipa.co/CSM_training(scrum Alliance Training) • http://sparkeducation.nl/scaling-up-summit/ (Jeff Sutherland)