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 (+ Kanban), Day 2 (2/2)


Published on

Training materials for Agile Scrum. This presentation goes into more detail how to manage you product backlog, bug inflow and resolution and technical debt. Benefits of test driven development and continuous integration and live deployment are also discussed. Kanban is introduced in more detail, and the benefits of Scrum, Kanban and Scrum-Ban are compared.

Published in: Software
  • Login to see the comments

Agile Scrum Training (+ Kanban), Day 2 (2/2)

  1. 1. Jens Wilke, LangFox, 1 Agile Scrum Training, Day 2 Jens Wilke, LangFox, 9 Dec 2014 Scrum: Team(s) working as a unit Image: Harald Selke, Creative Commons
  2. 2. •Recapping some of the day 1 items (Scrum overview) •Other real world issues •Practicalities creating a product backlog •Kanban •Materials •Hands-on workshop -> Session desired •Q&A Agile Training - Day 2 agenda Jens Wilke, LangFox,
  3. 3. Selected issues from session 1 revisited Jens Wilke, LangFox,
  4. 4. PO prioritizes the bugs too –Can delegate this, e.g. part of sprint is ok for bug fixing. –In practice, this is part of backlog grooming Bugs are part of product backlog –This is considered as a clear way, as there is only 1 prioritized list –On the other hand, in case of many bugs, the stories (non-bug) can get unclear (unless you can filter them out) Alternative: Bugs and product backlog are separate prioritized lists –2 lists: Product Backlog and Defect Management systems –Especially, if there is a separate Defect Management system –Bugs are pulled to the (single) Sprint Backlog from both lists according to PO guidance Sprint backlog and bugs Jens Wilke, LangFox,
  5. 5. If the team has also maintenance responsibilities, there are often some critical issues, that require fast resolution –Aborting Sprint and re-planning is impractical –Consider reserving a share of capacity for bug fixing –You can make task for this, e.g. 10% of sprint reserved for critical bug fixes –Create tasks for the bugs that are fixed. You can mark them differently for clarity –Product Owner must be aligned with the procedure –Review fixed bugs in sprint review –If bug is really small, just fix it Adding bugs during to an ongoing sprint backlog Jens Wilke, LangFox,
  6. 6. Technical debt refers to the consequences of poor system design •For example, business can cause the release of imperfect code On short term, technical debt can be tempting On the long term, mounting technical debt causes large costs •More defects, slower velocity, higher cost of maintenance, developer repulsion, … Backlogs should have tasks for managing the technical debt (refactoring code) •Backlogs can have everything that needs to be done for the software to be complete •Often separated from stories as “Tasks” Sprint backlog and Technical Debt Refactoring code Jens Wilke, LangFox,
  7. 7. There is evidence that doing TDD takes about 15% longer than not doing TDD. But there is also evidence that TDD leads to fewer defects. Two studies at Microsoft found that the number of bugs found went down by 2 4% and 3 8% with the use of TDD. TDD may take longer initially, but the time will come back to the team in the form of reduced bug fixing and maintenance time. An anecdote on technical debt and test driven development Jens Wilke, LangFox,
  8. 8. Continuous integration and automated tests help managing technical debt Splits big integration issues to normal daily business •Builds can be done multiple a day If build process is long, initial smoke tests can be used Facilitates team work •More here: Continuous integration also reduces technical debt Jens Wilke, LangFox, a b
  9. 9. Sometimes cumulating technical debt is ok Jens Wilke, LangFox,
  10. 10. What happens if the team finishes the sprint early •You can take new tasks from top of the sprint backlog, but you should be able finish these by the end of the sprint •Fix bugs •Reduce technical debt Finishing sprint early Jens Wilke, LangFox, Image: shortCHINESEguy, Creative Commons
  11. 11. For stories and tasks to be completed, they should be preferably tested and verified. This can be problematic, especially if many items are finished at the end of the sprint Means to avoid congestion at the end of sprint –Continuous acceptance (and possible continuous live deployment) –Small stories/tasks, so that you can submit to QA early –Build/deployment automation running automated tests –Developers should also test as far as possible –Limit work in progress (WIP), as stories will then hit QA earlier as a continuous stream As a side note, testers should be at sprint planning, as acceptance criteria is defined and testing can contribute Testing features done during the sprint Jens Wilke, LangFox,
  12. 12. Revisiting a release Jens Wilke, LangFox, At the end of the sprint, there should be a working increment of software –This could be a release candidate, that goes to end user testing –Release candidate can have bugs, that are found in end user testing (Staging), as the sprint has finished Make bug task –Allocate bug to a sprint –Can go to a current sprint, if you have this kind of practice –Fix only the bug, test and make a new release –Submit again to end user testing (Staging)
  13. 13. Team can work in Agile mode, but often organizations still follow waterfall. •Stage gates can require certain items •Provide minimum documentation feasible to pass the gate •For example, contractual reasons can mandate a release date •Consider splitting content to •Mandatory functionality (MVP – Minimum Viable Product) •There should be enough confidence to reach this on time •Planned content •In case of issues, drop the planned content •Your realistic plan should aim for completing the planned content Mixing scrum and waterfall Jens Wilke, LangFox, Image: Chris Golightly, Creative Commons
  14. 14. Communication is more challenging –More support materials are needed for verifying common goals –Over communicating is better than under communicating –Has significant overhead compared to co-location –Can succeed, but is more tricky aligning the teams Non co-located teams Jens Wilke, LangFox,
  15. 15. Making Product Backlog in practice Jens Wilke, LangFox, Image: ilker ender, Creative Commons
  16. 16. Backlogs can be comprised of very different types of items •Features •Bugs (often a separate defect management system) •Technical work •Knowledge acquisition In theory, you should document all stories and tasks, that are needed to be completed Product backlog content Jens Wilke, LangFox, Image: Andy McLemore, Creative Commons
  17. 17. As a [role], I want to [do something] so that [reason/benefit] –This is the brief description –Template originally developed at Connextra. Discussing the story during backlog grooming –Fleshing out the details with the team –Potentially making additional materials, e.g. Acceptance criteria –So that we know when the story is complete –Testing should be also around and discussing this Good user stories Jens Wilke, LangFox,
  18. 18. Feature: Shovel Snow –As a Home Owner –I want to Shovel Snow –So that I can get out of my driveway to get to work Problem with the above it describes the solution in too much detail. Less is better. Team can look for the best possible solution Feature: Accessible Driveway –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 Describe the problem, not the solution Jens Wilke, LangFox,
  19. 19. 1.Focus on the 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 Backup: Roman Pichler’s 10 tips for user stories Jens Wilke, LangFox,
  20. 20. Independent We want to be able to develop in any sequence. Negotiable Avoid too much detail; keep them flexible so the team can adjust how much of the story to implement. Valuable Users or customers get some value from the story. Estimatable The team must be able to use them for planning. Small Large stories are harder to estimate and plan. By the time of iteration planning, the story should be able to be designed, coded, and tested within the iteration. Testable Document acceptance criteria, or the definition of done for the story, which lead to test cases. Backup: Bill Wake's INVEST for user stories Jens Wilke, LangFox,
  21. 21. Product Backlog, a simple example Jens Wilke, LangFox,
  22. 22. •Minimum Viable Product (MVP) - ASAP •Order that makes sense for optimal execution –You can’t build roof first •Customer value, e.g. ROI –End user value / Cost of execution (generally using rough estimates, and needs to be done on high enough level) •Releasing stories together that make a meaningful theme •Risky items –Difficult and complex items should be addressed early Prioritization of Product Backlog is multi- objective optimization Jens Wilke, LangFox,
  23. 23. •Product focus is on users/customers •Product Owner should be actively discussing with users or their representatives, e.g. sales •Typically different people have differing opinions, and you can’t please all –One way is to gather feedback from users and document this, and use it as guidance –There are many scoring schemes •Releases need to be meaningful, so Product Owner can’t rely only on user feedback, but use her own judgment •Users/customers should be able to access the product backlog –… or a release plan, if that is available and easier to understand Jens Wilke, LangFox, Prioritization of stories with customers
  24. 24. Usually some users are more insightful than the others users Identifying and using these lead users, you can reduce somewhat the communication on the stories and priorities, and better understand the future evolution Lead users Jens Wilke, LangFox,
  25. 25. A Minimum Viable Product has just those features that allow the product to be deployed, and no more. –In practice this is the product, that you can consider shipping You can make releases to select users, e.g. lead users, already prior to the MVP –Release early and release often MVP Jens Wilke, LangFox,
  26. 26. Defines the longer term evolution and release plan in a simplified form for stakeholders –Can have impact on planning the architecture Release plan or roadmap Jens Wilke, LangFox,
  27. 27. Kanban The name 'Kanban' originates from Japanese, and translates roughly as "signal card" Jens Wilke, LangFox,
  28. 28. •Scrum •Kanban •Methodologies can be characterized according to how prescriptive they are •The methodology matters more than the tools used to implement it About Agile SW Methodologies = Tools Jens Wilke, LangFox,
  29. 29. Kanban (method) = An approach to incremental, evolutionary process improvement for organizations = Change management tool = Managing flow Scrum = an iterative and incremental agile software development framework for managing software projects and product or application development = Managing iterations Underlying difference between Kanban and Scrum Jens Wilke, LangFox,
  30. 30. Kanban is a tool, that is not specifically a software development tool, but can be used for it. Kanban is a change management tool Jens Wilke, LangFox,
  31. 31. As Kanban is less descriptive, teams using Kanban actually need more discipline With little rules, it’s easy to avoid them, e.g. setting high WIP limit –With high WIP limit, it’s in theory Kanban, but Kanban principle is rendered pointless Kanban requires discipline Jens Wilke, LangFox, Image: Gabriela Pinto, Creative Commons Image: Ray Morris, Creative Commons
  32. 32. 1.Limit Work In Progress 2.Visualize the workflow 3.Manage flow 4.Make policies explicit 5.Implement feedback loops 6.Improve collaboratively, evolve experimentally (using models and the scientific method) These can be typically complemented with further elements –This also applies to Scrum –You can extend Kanban towards Scrum Kanban is simple and has only 6 key principles Jens Wilke, LangFox,
  33. 33. How many items can be in each phase at a time, e.g. in ”To Do” or ”In Progress” Idea is to limit items per phase, so that they will efficiently flow through –Analogy to traffic:. Flow with high speed sparsely rather than progress in a slow traffic jam When a WIP limit for a certain task has been reached, the team stops and works together to clear the bottleneck. The goal of working in this manner is meant to ensure that the entire team takes ownership of the project and produces high quality code. Limit Work In Progress (WIP) Jens Wilke, LangFox,
  34. 34. Hitting WIP (Work in progress) limit causes pain, as it blocks others tasks In effect, this should encourage the immediate resolution of the issue Resolution will then restore the effective flow of tasks In effect: Smooth flow with some quickly resolved issues is better than having more issues per stage slowing each other down (with less pain and efficiency) Hitting WIP limit causes pain, thus encouraging quick resolution Jens Wilke, LangFox,
  35. 35. Only small number of items should be in a single stage for more even flow. •Good for testing •Clear and reduces the number of unfinished items Work in progress limit for Scrum Jens Wilke, LangFox,
  36. 36. Visualizing your work flow using a Kanban board shows which stage of development each feature is in. This is very helpful in seeing what the total backlog is and what work has been completed. The stages can be freely defined Looking a the Kanban board, immediately see where a team is Visualize the workflow Jens Wilke, LangFox,
  37. 37. A specific Kanban board physically limiting the flow Many SW tools support limiting work items too Visualize the workflow Jens Wilke, LangFox,
  38. 38. For example, only start new work when an existing work is complete –Keep the traffic density in check, as with work in progress (WIP) limits –Not many unfinished tasks cluttering the flow and impeding work of others Getting a constant and predictable stream of work through, whilst improving efficiency and quality. Rather than viewing work as a series of projects, view our work as a constant stream of work of varying kinds. Manage flow Jens Wilke, LangFox, Image: Ray Morris, Creative Commons
  39. 39. Until the mechanism of a process is made explicit it is often hard or impossible to hold a discussion about improving it. –Organization identifies opportunities to improve the system, –Evolutionary, collaborative change Allows to capture and preserve organizational learning by building it into the system that is used to manage the work Make policies explicit Jens Wilke, LangFox,
  40. 40. •Improve beyond local teams through operations reviews •Collaboration to review flow of work •Organizations that have not implemented the second level of feedback - the operations review - have generally not seen process improvements beyond a localized team level Implement feedback loops Jens Wilke, LangFox,
  41. 41. The Kanban method encourages small continuous, incremental and evolutionary changes that stick. When teams have a shared understanding, they are more likely to be able to build a shared comprehension of a problem and suggest improvement actions which can be agreed by consensus. Measure improvement Improve collaboratively, evolve experimentally Jens Wilke, LangFox,
  42. 42. Kanban Board, with WIP limits Jens Wilke, LangFox,
  43. 43. The little difference between Scrum and Kanban boards Jens Wilke, LangFox,
  44. 44. Scrum board is reset between each iteration Jens Wilke, LangFox,
  45. 45. More on this – Don‘t move items back on Kanban board Jens Wilke, LangFox,
  46. 46. If you want, you can add more rules, e.g. a product owner for prioritizing the items Kanban + more rules … leads us towards scrum Jens Wilke, LangFox,
  47. 47. Scrum has built in feedback loops Scrum has clear roles Kanban is directed primarily to change management Scrum has more extensive product backlog Scrum is more structured Kanban has more freedom Scrum backlog items must fit in a sprint … See Scrum vs. Kanban PDF – Scrum vs. Kanban, selected differences … you can also see scrum as extension of Kanban Jens Wilke, LangFox,
  48. 48. Scrum vs. Kanban, more detailed differences Jens Wilke, LangFox,
  49. 49. For example Scrum-Ban – You can also see scrum as extension of Kanban What ever works is fine –Agile is a toolset, not a religion –Remember the agile manifesto Mixing methodoligies is ok Jens Wilke, LangFox,
  50. 50. Visualizing the workflow Limiting work in progress (and managing flow) for getting testing done on time for the end of sprint Late binding of work Leave out estimation, and use a task limit for sprint … Kanban ideas worth considering to use in Scrum Jens Wilke, LangFox,
  51. 51. Having roles, e.g. product owner –Product owner can prioritize continuously Timeboxed iterations Estimating velocity, if you need to estimate a product completion date … Scrum ideas worth considering to use in Kanban Jens Wilke, LangFox,
  52. 52. General software development -> Scrum –You can generally plan pretty well ahead Bug management or maintenance mode -> Kanban –It’s hard to plan out the bugs –Kanban can be also great for research, as the next steps depend on the previous and are not foreseeable You can extend the other with the other When to use Scrum or Kanban Jens Wilke, LangFox,
  53. 53. Recommended materials –Scrum Guide – a brief overview –Scrum vs. Kanban –For the CSP – Certified Scrum Professional 1.Succeeding with Agile: Software Development Using Scrum 2.Agile Estimating and Planning 3.Agile Software Development with Scrum For more info Jens Wilke, LangFox,
  54. 54. Jens Wilke, LangFox, Q&A