Agile and Kanban Overview

AGILE&KANBAN

AgileSolutions

Keith Klundt, [email protected]@WebSolvewww.linkedin.com/in/keithklundt• 15 years in product and technology

leadership• Agile/Scrum/Kanban trainer and coach• Scaled Agile Framework (SAFe) Program

Consultant

Introductions

© 2013 AgileSolutions

mailto:[email protected]

Agile Manifesto


We are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items onthe right, we value the items on the left more.

agilemanifesto.org

Agile Principles


1. Deliver value early2. Welcome change3. Deliver value often4. Customers and

creators work together daily

5. Involve only motivated people

6. Convey information face-to-face

7. Outcomes are the main measure of progress

8. Work at a sustainable pace

9. Technical excellence

10. Simplify11. Self-organize12. Reflect and improve

Agile Characteristics


Empirical – relies on objective measurementIterative – builds value over timeAdaptive – adjustments made periodically based on results


Behind The Decision to Try Agile


Actual Benefits from Agile


More prescriptive More adaptive

RUPDSDM

XP Crystal

Scrum Kanban

Agile Methods & Practices

Agile Methods & Practices


Scrum



• Commitment• Focus• Openness• Respect• Courage

Scrum Values

Scrum Artifacts: Product Backlog



Scrum Artifacts: User Story or PBIGood Story FormWhere <user type> is a persona or entity that we define that can take action or perform a function:

As a <user type>, I want to <function> so that <benefit> or<user type> <action> <because>

Good Examples• As a passenger, I want to set the temperature of my seat so that I

am comfortable• As a laptop user, I want to de-clutter my screen so that only the

application I'm working with is visibleBad Examples• The current clinician clicks the icon to find out what

contraindications exist• The system alerts the clinician because the patient prescription

limit has been reached

User Story – 3 CsCardJust enough information to identify the requirement and let everyone know what the story is. Common reference point for all: Product Owner, Stakeholder, Developer, QA.

ConversationThe card is an invitation to have a conversation: an exchange of thoughts, opinion, feelings and ideas. The conversation takes place over time—when the story is first introduced, during subsequent grooming and sizing, and at iteration planning. Conversation may be supplemented with documents and prototypes.

Confirmationkey aspects of the story that will be used by the Product Owner as acceptance criteria.


Acceptance CriteriaWhat is it?

• Details from the user story conversation• Expectations of how the customer team expect the user

story to work • Used to validate that the development for the user story

is doneWhy does it need to be done?

• Used to validate that the development is done• Acceptance criteria is folded into use cases and used for

the life of the product• Used for documenting how the product works

Who creates the acceptance test?• The customer and/or Product Owner• Team members should participate


Agile Planning

http://commons.wikimedia.org/wiki/File:XP-feedback.gif



Sprinting


The heart of Scrum is a Sprint, a time-box during which the team creates a potential releasable product increment.

During the Sprint:• No changes are made that would affect the

Sprint Goal• Development team composition remains intact• Quality goals do not decrease• Scope may be clarified and re-negotiated

between the Product Manager and Development Team as more is learned.

Sprint Planning


• Time-boxed to 8 hours for a one-month Sprint (4 hours for a two-week Sprint)

• Answers the questions:1. What will be delivered in the increment

resulting from the sprint?2. How will the work needed to deliver the

increment be achieved?• Inputs include:

1. Product Backlog2. Latest product increment3. Projected team capacity during the Sprint4. Average historical velocity of the team

• Team commits to the Plan

Product Backlog Grooming


• Provide clarity • Establish acceptance criteria• Establish more detailed estimates

As stories move to the top of the backlog we increase the details of the story and break them down as needed

Sprint Review


• Scrum Team and Stakeholders collaborate on what was done and what should be done next

• Product Owner identifies what has been done and accepted

• Development team provides an overview of what went well and how they solved problems

• Development team or Product Owner demonstrates work done

• Product Owner updates stakeholders on what’s likely to happen in the near future

Sprint Retrospective


• Opportunity for the Scrum team to self-inspect and create a plan for improvement in the next Sprint

• Evaluate how the last Sprint went with regard to people, relationships, process, and tools

• Identify and order major items that went well and opportunities for improvement

• Create a plan to implement improvements to the way the team does its work

Daily Scrum


• Time-boxed to 15 minutes• Primary purpose is to synchronize the team and

commit to a plan for the next 24 hours• Held at the same time and place each day• Each Development Team member explains:

1. What s/he has accomplished in the past 24 hours

2. What s/he will complete before the next meeting

3. What obstacles are in the way• Daily work is evaluated in the context of the

Sprint Goal. An effective Daily Scrum should help the team increase the probability of achieving their goal.

Scrum Artifacts and Ceremonies


Prioritized Items desired by Customer

Potentially Shippable Product

Increment

Sprint Planning Meeting•Review Product Backlog•Estimate Sprint Backlog•Commit to 3 weeks of work

Backlog tasksexpanded by team

•Product backlog items assigned to sprint•Estimated by team

Daily Scrum Meeting•Committed to yesterday•Commit to today•Obstacles?

Sprint Showcase•Demo done items•Retrospective on the Sprint

Kanban ̶ A Lean Practice

Toyota Production System House of Quality

Kanban


Lean Principle: Eliminate Waste

Seven Wastes of Manufacturing Seven Wastes of Software Development

Inventory Partially Done WorkExtra Processing Extra Processes or

DocumentationOverproduction Extra FeaturesTransportation Building the Wrong Thing

Waiting Waiting for InformationMotion Task SwitchingDefects Defects

Source: Esther Derby, “Three Encouraging Developments in Software Management,” CrossTalk, January 2009 http://www.stsc.hill.af.mil/crosstalk/2009/01/0901Derby.html


http://www.stsc.hill.af.mil/crosstalk/2009/01/0901Derby.html

Scrum and Kanban Similarities• Lean and Agile shared values• Pull scheduling• Limit WIP• Transparency drives process improvement• Deliver releasable software early and often• Self-organizing teams• Break work into pieces• Release plan is continuously optimized

based on empirical data (velocity in Scrum, lead time in Kanban)



Contrast

Scrum KanbanTime boundaries (iterations) Work unit boundaries (batch sizes)

Narrow appeal to SW engineering

Broad appeal to Product Management, IT Ops, IT support, etc.

Radical change Minimally invasive, evolutionary

Requires high trust culture Can succeed in relatively lower trust culture

Requires cross-functional team

Allocates specialized knowledge and skills

Focuses on delivery team capacity Expresses system capacity

Kanban Emphasizes Continuous Flow• Work-in-progress (WIP) limits• Pull system• Just-in-time work• Collaboration around process

problems• Systems approach to

continuous improvement© 2013 AgileSolutions

Name Writing Project

Step 1: Estimate how long it takes to write:

1 name1 + n names

Step 2: What factors influence the time it takes?


Name Writing Project


Name Writing Project – Round 1




Estimate Actual

1 Name5 Names

Name Writing Project – Est v Actual


Estimate

Round 1 Actual

Round 2 Actual

1 Name5 Names

Reflect


• How did the two rounds feel to you as Developer and Customer?

• What was it like to be the last customer in round 1 v round 2?

• What do you think about the statement, “if we start early, we’ll finish early?”

• What causes us to do this? Why is it so common?Henrik Kniberg, http://

blog.crisp.se/2011/12/07/henrikkniberg/multitasking-name-game

http://blog.crisp.se/2011/12/07/henrikkniberg/multitasking-name-game



The Kanban Board – Left to Right1. Goals – on the far left side of the Kanban board is a column

labeled “goals.” Prioritization of the Backlog should reflect something in the goals column.

2. Backlog – stories standing in line waiting to be worked by the team. Team always pulls from the top of the Backlog


3. Story Process Steps – columns for the process steps a story needs to go through to be called “done.”

4. Done – stories that are ready to be deployed.

Kanban Goals Focus on The System• Deliver high quality• Improve predictability• Improve employee

satisfaction• Continuous process

improvement• Simplify prioritization• Provide transparencyDavid J. Anderson, Kanban


Foundation Principles

1. Start with what you do now2. Agree to pursue incremental,

evolutionary change3. Respect the current process, roles,

responsibilities and titles


Practices• Visualize the workflow• Limit WIP• Manage flow for just-in-time value delivery

CONstant Work in Process (CONWIP); new work is pulled into an activity when there is capacity in the local WIP limit

• Make process policies explicit (criteria that must be met before work can be pulled into the next phase)

• Improve collaboratively (PDCA cycles)• Work for uniformity in work item size© 2013 AgileSolutions

Create The Board


1. Agree on the goals for introducing Kanban

2. Map the value stream

Define the attributes required to accept a request into the system

3. Define the point where you want to control input

4. Define the exit point beyond which you do not intend to control

Create The Board


5. Define a set of work item types based on the types of work requests that come from upstream stakeholders

6. Analyze the demand for each work item type

Type A – BurstType B – SteadyType C – IntermittentType D – SteadyType E – Cyclical

Create The Board


7. Meet with the upstream and downstream stakeholders to discuss:• Policies around capacity of the piece of the value stream

you want to control and get agreement on a WIP limit. For example, you may want to put in place a policy for Environment issues that states they will be addressed within 24 hours and can exceed the WIP limit on any state within the value stream.

• Discuss and agree on an input-coordination mechanism with upstream partners.

• Discuss and agree on a release/delivery-coordination mechanism with downstream partners

• Introduce the concept of classes of service, if needed• Agree on a lead-time target for each class of service of

work items.

Create The Board


8. Create a card wall to track the value stream you are controlling

Create The Board


9. Agree with the team to have a standup meeting every day in front of the board. Each team member reports on his/her work with:• What I accomplished yesterday• What I will commit to doing today• Impediments in my way

In addition to the Daily Standup, agree on a cadence and next meeting dates for:• Queue Replenishment – to be held with a group of business

stakeholders or product owners weekly• Retrospective – team members meet regularly (e.g., weekly or

every 2 weeks) to reflect and work on process improvement. Among other things, the team reviews:• Average throughput based on latest results• Average cycle time based on latest results• Feedback from customers on process and delivery• What the team feels it should keep doing, start doing, and

stop doing to achieve even better results

Scrum or Kanban Cadence


Queue Size Control PrincipleFor real-time control and system optimization:

1. Don’t control capacity utilization

2. Don’t control cycle time3. Do control queue size

Donald G. Reinertsen, Principles of Product Development Flow


Monitor WIP per Team Member

Rally Software: The Impact of Agile Quantified, 2013© 2013 AgileSolutions

• Lower WIP produces fewer defects

• The right WIP level optimizes throughput and quality

Mature Lean OrganizationLean Assumption #1 – A mature organization looks at the whole system; it doesn’t only focus on optimizing disparate or separate parts

Lean Assumption #2 – A mature organization focuses on learning effectively and empowers the people who do the work to make decisions

M & T Poppendiek, Lean Software Development© 2013 AgileSolutions

Kanban Measures Continuous Flow

http://www.targetprocess.com/userguides/userguide.html© 2013 AgileSolutions

http://www.targetprocess.com/userguides/userguide.html

http://www.targetprocess.com/userguides/userguide.html

Frequent Review and Incremental Improvement


Make Policies and Flow Explicit


Meetings

• Grooming• Prioritization / Planning• Standup


“Since our last meeting, two slots have become free. Our current cycle time is

6 weeks to delivery. Which 2 thing would you most like delivered 6 weeks

from now?”

Making The Transition


Causes of Agile Failure

Transition Backlog Example


Schedule Recurring Agile Governance meetings to inspect and adapt, and to review status of transition backlog itemsBacklog Item Responsible Status Due Date

Publish goals for using KanbanSet expectations that change is needed and will require commitment, work and creativityMeet with stakeholders to describe the changeDetermine how to communicate progressDecide on tools

Inspect and Adapt


Keep Doing

Stop Doing

Start Doing


Get It DoneThe Cult of Done Manifesto

1. There are three states of being: Not knowing, action and completion.

2. Accept that everything is a draft. It helps to get it done.3. There is no editing stage4. Pretending you know what you’re doing is almost the same as

knowing what you’re doing, so just accept that you know what you’re doing even if you don’t, and do it.

5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.

6. The point of being done is not to finish but to get other things done.

. . . 9. People without dirty hands are wrong. Doing something makes

you right.10.Failure counts as done. So do mistakes.

http://www.brepettis.com/blog/2009/3/3/the-cult-of-done-manifesto.html


Appendix

Scrum and Kanban – A Case Study

• 2001 – 2006 used waterfall process with annual release cycle: design -> implementation -> testing -> deployment

• 2007 moved to Scrum with 3-week sprints• 2013 moved to Kanban with emphasis on

uninterrupted flow and WIP limits• Measured lead time (from next in line at the

start to ready for release at the end of the board), quality, and productivity

http://www.infoq.com/presentations/kanban-for-software




Stuff from David Anderson

Kanban allows us to implement my (David’s) recipe for success:• Focus on Quality• Reduce (or limit) Work in Progress• Balance Demand against Throughput• Prioritize


Slideshow only: http://www.slideshare.net/deimos/david-anderson-kanban-at-q-con

http://www.slideshare.net/davidpeterjoyce/kanban-overview-and-experience-report-export-3593596




http://www.slideshare.net/deimos/david-anderson-kanban-at-q-con



Stuff from David Anderson

Case Study: XIT one of Microsoft’s 8 IT departmentsXIT Sustained Engineering• Small team• Change requests• Supports over 80 applications (and growing)• Engineering responsibilities moved from

Redmond to Hyderabad in 2004• Hyderabad vendor is CMMI Level 5 and uses

TSP/PSP• Initial quality is very high





Agile and Kanban Overview

Documents

Transcript of Agile and Kanban Overview