Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Scrum Training, Day 1 (1/2)


Published on

Training materials for Agile Scrum. Starts with an overview of Agile and Lean. Followed with the Agile Scrum key concepts like Product Owner, Scrum Master, Scrum Team and Product Backlog. Theory is complemented with learnings and best practices from real life software development.

Published in: Software
  • Login to see the comments

Agile Scrum Training, Day 1 (1/2)

  1. 1. 1 Agile Scrum Training, Day 1 Jens Wilke, LangFox, 8 Dec 2014 Scrum: Team(s) working as a unit Image: Harald Selke, Creative Commons Jens Wilke, LangFox,
  2. 2. Agile •Focusing on Scrum •Info on Kanban too Goals •Recapping the key principles •Discussing best practices on organizing and doing work in real world 2 About this session Image: Thomas Teubert, Creative Commons Jens Wilke, LangFox,
  3. 3. Agenda/Backlog for day 1 –10:00 Intro –Agile and Lean –Scrum –Team and roles –Who is not in the team –Product and Sprint Backlog –Sprint Cycle –Events –Definition of done –Tools: Project documentation, Recalibrating speed –Kanban –Selecting between Scrum and Kanban –Materials for further study 3 Day 1 – Agile and scrum in theory and practice Day 1 emphasis is on theory Jens Wilke, LangFox,
  4. 4. See the walls, and the sticky notes on them –They define the agenda for today’s training –Intro, Agile, Lean, … Anything missing regarding this training session –Add the missing items to the backlog, as we‘re agile –Breaks … whatever. add them to the product backlog and we’ll prioritize them together 4 Session backlog = todos Jens Wilke, LangFox,
  5. 5. 5 Agile and Lean are not exactly defined, but are rather principles and practices Agile focuses on well organized process which allows frequent delivery which makes it easy to adjust the course of development. Manifesto: “… •Individuals and interactions over processes and tools •Working software over comprehensive documentation •Customer collaboration over contract negotiation •Responding to change over following a plan …” Lean focuses more on limiting waste (including work in progress which is considered as one of types of waste) and making production and delivery workflow efficient. (ref. Toyota) 1.Eliminate waste 2.Amplify learning 3.Decide as late as possible 4.Deliver as fast as possible 5.Empower the team 6.Build integrity in 7.See the whole Scrum and Kanban are Agile/Lean methodologies Jens Wilke, LangFox,
  6. 6. •Scrum •Kanban •Methodologies can be characterized according to how prescriptive they are •The methodology matters more than the tools used to implement it 6 About Agile SW Methodologies = Tools Jens Wilke, LangFox,
  7. 7. Scrum elements: ~9 3 roles –Product owner –Scrum master –Team 2 artifacts (+2) –Product backlog –Sprint backlog –Sprint burndown –Product burndown 4 activities (+1) –Sprint planning –Backlog grooming –Daily scrum –Sprint review –Sprint retrospective Jens Wilke, LangFox, 7 Details on methodology elements Kanban practices: ~6 1.Limit WIP 2.Visualize the workflow 3.Manage flow 4.Make Process Policies Explicit 5.Implement feedback loops 6.Improve Collaboratively
  8. 8. 8 Example: renovation After you make the spec, it should be pretty clear what and how it should be done, right? Unfortunately not - real world is way more complex and there are always surprises. In order to get good results, faster and with less cost, regular feedback and guidance helps. Task: Fix this Result: Nailed it! Jens Wilke, LangFox,
  9. 9. The next step is to give the free hand not to the person against you but an other one. check that all people are connected in one circle (otherwise you and up with two circles) below you see an example Goal: The requested end situation is a circle of people holding hands. The game: Start by giving the manager the instruction to solve this complex problem, the knot. He is only allowed giving instruction by voice. Start the timer. The manager will give instruction. If the manager has not solve the problem after 5 minutes you can stop. Start again in the same position but this time let the team solve the problem. You will see that the team solved this problem more than 10 times faster is my experience. 9 Example: Scrum Spaghetti Game Jens Wilke, LangFox,
  10. 10. •Higher productivity and lower costs •Improved employee engagement and job satisfaction •Faster time to market •Higher quality •Improved stakeholder satisfaction •What we’ve been doing no longer works 10 Why Agile Jens Wilke, LangFox, Image: Leo Reynolds, Creative Commons •Note, that the classic waterfall works better for certain types of projects
  11. 11. 11 Key differences to traditional ways Jens Wilke, LangFox,
  12. 12. 12 Key differences to traditional ways Jens Wilke, LangFox,
  13. 13. 13 Scrum Roles Implementing the product Jens Wilke, LangFox,
  14. 14. •Whether an organization is Agile or not depends on its culture. •Does the culture support the personal values of the manifesto? •If so, it's Agile, if not, then it's doing something else. •Agile Manifesto •Individuals and interactions over processes and tools •Working software over comprehensive documentation •Customer collaboration over contract negotiation •Responding to change over following a plan Jens Wilke, LangFox, 14 Because an organization is using scrum, doesn't mean it's Agile
  15. 15. Product Owner (WHAT) •Voice of the customer, customer facing Scrum Master (HOW) •Handles the process, more team facing Development Team •Scrum Teams are cross-functional, i.e. development, testing, analyst, designer, … There is no single point of contact, but communication should flow freely through the team •In practice product owner is mostly communicating with the scrum master, but product owner should be available to the whole team •Split between Product Owner and Scrum Master roles often varies Jens Wilke, LangFox, 15 Scrum Roles
  16. 16. The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. 16 Scrum Master Jens Wilke, LangFox, •Help team in it’s use of scrum –Facilitates scrum events, i.e. running the daily show •Remove impediments –So that the team can effectively execute •Facilitates communication •Has no authority over the team members •Has authority over the process •Provides guidance, not answers
  17. 17. Attributes of a good scrum master •Responsible •Humble •Collaborative •Committed •Influential •Knowledgeable 17 Scrum Master Jens Wilke, LangFox,
  18. 18. Scrum Master … Can be a developer –Pretty usual approach with smaller teams Shouldn’t be the lead developer –Has a tendency to disrupt the self-organization Shouldn’t be the product owner –These roles have generally too different agendas and possibly conflicting interests Should be internal Jens Wilke, LangFox, 18 Scrum master and other roles
  19. 19. Provides a vision Responsible for the product backlog –Backlog defines what gets done –Does not need to write all the stories Provides boundaries –Schedule, Performance, … –Goals should be reachable Each team needs exactly one Jens Wilke, LangFox, 19 Product Owner Image: Kristina Alexanderson, Creative Commons
  20. 20. Attributes of a good Product Owner •Available •Business-Savvy •Communicative •Decisive •Empowered 20 Product Owner Jens Wilke, LangFox,
  21. 21. Sometimes more persons are needed to manage product Sometimes the sponsor or some other stakeholder wields big power In any case, there should be only ONE product owners from the teams point of view –There can be lot of heavy discussion in the product owner team, but this shouldn’t concern the team 21 A product owner team or a proxy product owner Jens Wilke, LangFox,
  22. 22. A team’s time demands on their Product Owner and Scrum Master move in different directions. Jens Wilke, LangFox, 22 Team need of Scrum Master and Product Owner Graph from: Succeeding with Agile, Mike Cohn
  23. 23. A collection of individuals working together to deliver the requested and committed product increments. Working together •Succeeding together •Failing together Responsible together •Follow a common goal •Adhere to the same norms and rules •Show respect to each other •Be collaborative 23 Scrum team Jens Wilke, LangFox, Image: DG EMPL, Creative Commons
  24. 24. There’s no specific limitations on the roles. Team members can be developers, testers, business analysts, designers, architects etc. 24 Scrum team roles Jens Wilke, LangFox,
  25. 25. •Fewer than three Development Team members decreases interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. •Big team size causes communication overhead (ref. Mythical Man Month) 25 Scrum team size optimum: 3 - 9 Jens Wilke, LangFox, Graph from: Succeeding with Agile, Mike Cohn
  26. 26. Those who can not commit –Allocating a certain amount of time for doing the sprint backlog tasks Possible examples –Architect looking at multiple projects –Designer serving multiple customers 26 Who is not in the scrum team Jens Wilke, LangFox,
  27. 27. Scrum Master ≠ Project Manager Product Owner ≠ Product Manager Traditionally project manager was planning, what the team is doing Product manager was talking with the customers and doing the requirements Above tasks are now split between the roles in a different way. Few examples •Scope management -> Product Owner •Process -> Scrum Master •Organizing work -> Team members select the tasks •Backlog grooming -> Product owner, Scrum Master, Team •Communication flows between Product owner, Scrum Master, Team 27 Side note: How do these relate to traditional project manager and manager Jens Wilke, LangFox,
  28. 28. 28 Scrum artifacts Artifact = something created by humans usually for a practical purpose Jens Wilke, LangFox, Image: Wessex Archeology, Creative Commons
  29. 29. •Product backlog •Sprint backlog •Sprint burndown •Product burndown 29 Scrum Artifacts Jens Wilke, LangFox,
  30. 30. List of desired product functionality Maintained by product owner –Can be also somebody else, but product owner is responsible Prioritized by product owner Usually the items in product backlog are user stories, e.g. –As a <type of user>, I want <some goal> so that <some reason> In end effect roughly: A prioritzied feature list 30 Product Backlog Jens Wilke, LangFox,
  31. 31. Next items should be clear and on top of the product backog Next items should be small enough for sprint planning Later items can be more hazy and big (Epics) 31 Product Backlog characteristics Jens Wilke, LangFox, Graph from: Succeeding with Agile, Mike Cohn
  32. 32. Should be actively managed –Backlog grooming 32 Managing the product backlog Jens Wilke, LangFox,
  33. 33. The items on top will get implemented next The long tail is for documenting the ideas –Most of it never gets implemented 33 Product backlog can have tons of stuff Jens Wilke, LangFox,
  34. 34. Human readable •You can use Epics for higher abstraction Accessible for anybody with interest •Publish it on the wall •Input will help to improve The Product Owner may do the above work, or have the Team do it. However, the Product Owner remains accountable. Roadmap can be considered a digest of a Product Backlog Jens Wilke, LangFox, 34 Good product backlog
  35. 35. Few options If there’s flexibility on time •You can define release by content If there’s no flexibility on time •Must have content must be in the release •You can use important ”nice to have” features as buffer •Drop these, if things get tight 35 Release plan and product backlog Alpha release Jens Wilke, LangFox,
  36. 36. 36 Now we have defined scrum roles and the big plan Jens Wilke, LangFox,
  37. 37. •The scrum development runs repeating cycles called sprints •Scrum master (with the team and product owner) define the sprint length –Usually between 1-4 weeks –Most commonly 2 weeks •The sprint backlog is generally the top most items from the product backlog, that can be done during the sprint duration •At the end of the sprint backlog should be ideally implemented, and there should be a new potentially shippable software increment 37 Sprints and Sprint Backlog Jens Wilke, LangFox,
  38. 38. Refine 38 From product backlog into Sprint Backlog - roughly Sprint Jens Wilke, LangFox,
  39. 39. 39 Each sprint should deliver functional software Working software encourages feedback Working software helps a team gauge its progress Working software allows the product to ship early if desired Jens Wilke, LangFox,
  40. 40. According to the Scrum Guide, one (1) day is the largest a task duration. •Anyway, much smaller than typically in the product backlog Smaller items •Better predictability on outcome •Better visibility on progress •When breaking down, the task has been already pre- processed Jens Wilke, LangFox, 40 Sprint backlog should be granular Image: Andrew Moreton, Creative Commons
  41. 41. General advice is to estimate the sizes of the sprint backlog items, so that you can estimate what gets done during the sprint •Some prefer not to, but use something else, e.g. number of tasks. General advice is to use fake time units for estimation, so that you can calibrate your velocity/estimates in the future sprints •Some prefere plain hours For estimation, you can use different measures •Natural numbers •Fibonacci numbers •T-Shirts sizes You might want to use different sizing schemes for product backlog and sprint backlog Jens Wilke, LangFox, 41 Estimating the backlog sizes
  42. 42. Make your work visible for yourselves and everybody with interest Each scrum backlog item has a status, and you see items moving to completion All modern tools like VersionOne, Rally and Jira (with Greenhopper) have these Jens Wilke, LangFox, 42 Scrum board
  43. 43. See how your sprint is progressing Tools like VersionOne and Rally provide these automatically Use this to re-calibrate your efforts in the future sprints 43 Sprint backlog burndown chart Jens Wilke, LangFox,
  44. 44. See how your Product is progressing Tools like Scrumworks and JIRA/Greenhopper provide these automatically With product backlog there is many more unknows than with the short well planned sprints –Thus preparing for emergent stories is advised 44 Product backlog burndown chart Jens Wilke, LangFox,
  45. 45. •Sprint planning •Daily scrum •(Backlog grooming) •Sprint review •Sprint retrospective 45 Scrum events Jens Wilke, LangFox,
  46. 46. The Sprint Planning Meeting is time-boxed. According to guide, 8 hours for a one- month Sprint. 2 week Sprints have four- hour Sprint Planning Meetings. 46 Sprint Planning Meeting Jens Wilke, LangFox, Part One: What will be done this Sprint? –Product owner, Scrum Master, Team –Create sprint backlog –Define sprint goal Part Two: How will the chosen work get done? –Team understand how they get the things done –Product Owner may be present, but is not needed –Recalibration of part 1 may follow with product owner
  47. 47. The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. 47 The Sprint after the planning by the book Often modified Jens Wilke, LangFox, During the Sprint: • No changes are made that would affect the Sprint Goal; • Development Team composition and quality goals remain constant • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.
  48. 48. The Daily Scrum meeting is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. 48 Daily Scrum Jens Wilke, LangFox, • What has been accomplished since the last meeting? • What will be done before the next meeting? • What obstacles are in the way? Not a status meeting Idea of standing is not to get too comfortable The Scrum Master ensures that the Development Team has the meeting, but the Development Team is responsible for conducting the Daily Scrum. Image: Improve It, Creative Commons
  49. 49. Product backlog grooming is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate –Product backlog should be well groomed prior to the Sprint Planning During Product Backlog grooming, items are reviewed and revised. –However, they can be updated at any time by the Product Owner or at the Product Owner’s discretion. Grooming is a part-time activity during a Sprint between the Product Owner and the Development Team. Often the Development Team has the domain knowledge to perform grooming itself. Grooming usually consumes no more than 10% of the capacity of the Development Team. The Development Team is responsible for all estimates. The Product Owner may influence the Team by helping understand and select trade-offs, but the people who will perform the work make the final estimate. 49 Backlog grooming Jens Wilke, LangFox,
  50. 50. Demo –The Development Team demonstrates the work that it has “Done” and answers questions about the Increment The Product Owner identifies what has been “Done” and what has not been “Done” –Often facilitated by the scrum master The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved As book example, two week Sprints have two-hour Sprint Reviews. Jens Wilke, LangFox, 50 Sprint Review
  51. 51. Items should have a clearly defined definition of done at the beginning of sprint –Task will become more clear –It’s easier to say, if task got done Undone items are moved to the product backlog or directly to the next sprint backlog Recalibrating the velocity, i.e. how the story points correlate to the actual hours –Idea is to get better with estimation The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning Meetings. Jens Wilke, LangFox, 51 Sprint review
  52. 52. The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, • Inspect how the last Sprint went with regards to people, relationships, process, and tools • Identify and order the major items that went well and potential improvements • Create a plan for implementing improvements to the way the Scrum Team does its work 52 Sprint Retrospective Jens Wilke, LangFox,
  53. 53. To be shared –Scrum guide –Scrum vs. Kanban Selected books (good for CSP = Certified Scrum Professional) 1.Succeeding with Agile: Software Development Using Scrum - Must read for CSP 2.Agile Estimating and Planning - Must read for CSP 3.Agile Software Development with Scrum - Must read for CSP 4.Agile Product Management with Scrum 5.Agile Retrospectives 6.Refactoring: Improving the Design of Existing Code 7.Test Driven Development By Example 8.Agile Retrospectives 53 Materials Jens Wilke, LangFox,
  54. 54. Q&A Jens Wilke, LangFox, 54