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

http://www.langfox.com/

• 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, www.langfox.com

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


https://help.rallydev.com/glossary

https://help.rallydev.com/glossary

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


http://www.slideshare.net/RossC0/kanban-vs-scrum





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


http://leansoftwareengineering.com/ksse/scrum-ban/




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)

Software

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