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

Jens Wilke, LangFox, www.langfox.com
1
Agile Scrum Training, Day 2
Jens Wilke, LangFox, www.langfox.com 9 Dec 2014
Scrum: Team(s) working as a unit
Image: Harald Selke, Creative Commons

•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

Selected issues from session 1 revisited

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

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

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

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

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: http://www.martinfowler.com/articles/originalContinuousIntegration.html
Continuous integration also reduces technical debt
a
b

Sometimes cumulating technical debt is ok

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
Image: shortCHINESEguy, Creative Commons

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

Revisiting a release
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)

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
Image: Chris Golightly, Creative Commons

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

Making Product Backlog in practice
Image: ilker ender, Creative Commons

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
Image: Andy McLemore, Creative Commons

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

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

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

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

Product Backlog, a simple example

•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

•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
Prioritization of stories with customers

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

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

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

Kanban
The name 'Kanban' originates from Japanese, and translates roughly as "signal card"

•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

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

Kanban is a tool, that is not specifically a software development tool, but can be used for it.
Kanban is a change management tool

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
Image: Gabriela Pinto, Creative Commons
Image: Ray Morris, Creative Commons

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

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)

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

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

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

A specific Kanban board physically limiting the flow
Many SW tools support limiting work items too
Visualize the workflow

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
Image: Ray Morris, Creative Commons

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

•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

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

Kanban Board, with WIP limits

The little difference between Scrum and Kanban boards

Scrum board is reset between each iteration

More on this
–http://zsoltfabok.com/blog/2010/09/never-move-items-back/
Don‘t move items back on Kanban board

If you want, you can add more rules, e.g. a product owner for prioritizing the items
Kanban + more rules … leads us towards scrum

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
–http://www.slideshare.net/RossC0/kanban-vs-scrum
Scrum vs. Kanban, selected differences … you can also see scrum as extension of Kanban

Scrum vs. Kanban, more detailed differences

For example Scrum-Ban
–http://leansoftwareengineering.com/ksse/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

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

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

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

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

Q&A

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

More Related Content

What's hot (20)

Viewers also liked (15)

Similar to Agile Scrum Training (+ Kanban), Day 2 (2/2) (20)

Recently uploaded (20)

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