Agile-Kanban

Tushar K Pradhan
Joydeep Sarkar

Intr 1 1 Introduction to Scrum | 2013 © 2014 IBM Corporation

odu
Agenda

 Overview of Agile – Kanban

 How Kanban is used in software Development and Maintenance
 Case Study
 Q&A

2
22 Introduction to
Introduction to Scrum
Scrum || 2013
2013 © 2014 IBM Corporation
The Agile Manifesto – 2001

We are uncovering better ways of developing

software 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 on

the right, we value the items on the left more.

3
33 Introduction to
Introduction to Scrum
Scrum || 2013
2013 © 2014 IBM Corporation
 Agile Framework Agile Framework

Agile is a conceptual framework for undertaking software

engineering projects

Extreme Dynamic Systems

Programming (XP) Scaled Agile Feature
SCRUM Unified Process Crystal Development Kanban
Framework Driven Dev
Method (DSDM):

•Based on values •Small teams of •Frequent •interactive •3 primary phases: •Develop feature •Incremental,
•Simplified version
of simplicity, 8-12 people Delivery knowledge base Pre-Project, list, Plan, Design, Evolutionary
communication, of Rational Unified
for implementing Project Life-Cycle , Build by Feature Change
feedback, Process – reduced •Reflective agile practices
•“Backlog” defined improvement Post-Project
courage, requirements that at enterprise •Kanban board
and respect will be addressed scale help team
understand how
in each Sprint •Based on Lean they are doing
•Start with simple
solution, add and Agile and also what to
•Daily 15 min. principles do next
complexity Scrum meeting
through to discuss
refactoring work for the day

Agile Techniques: The above methods involve a range of techniques including:

Test-driven development Continuous integration Static Analysis

Planning game Design improvement Coding standard

Pair Programming Small releases Sustainable pace

Refactoring Simple design Whole team

4
44 Introduction to
Introduction to Scrum
Scrum || 2013
2013 © 2014 IBM Corporation
Why Kanban

Time-boxed iterative development has challenges

Common problems include

• Short time-boxes give more frequent opportunity to measure progress and inspect
software but force development items to be smaller. In reality some items need
longer time to finish(ex: Problem Management in Maintenance phase)
• Smaller development items are often too small to be valuable and difficult to identify
• Quality of requirements suffers as analysts rush to prepare for upcoming cycles
• Quality of current development suffers when busy analysts are unable to inspect
software or answer questions during development
• Quality often suffers as testers race to complete work late in the development time-
box

© 2014 IBM Corporation

What is Kanban

Using a Kanban approach in software time-boxed iterations are

dropped in favor of focusing on continuous flow

 Kanban is a system based on Lean and the Theory of Constraints

 Named after the Japanese word for taskboard
 It works on a continuous flow basis and dispenses with planning
iterations.
 Instead it works by limiting work in progress to team capacity
 Developed by David Anderson

© 2014 IBM Corporation

What is Kanban

Characteristics
• Visualize Work Flow
• Limit WIP
• Manage Flow
• Make Process Policies Explicit
• Improve continuously and Collaboratively
• Aims are improving the efficiency (cycle time) by optimization over a period of time

© 2014 IBM Corporation

 Overview
Kanban Model for Enhancements and Problem Management
 Identify Minimally Viable Feature (MVF) of a Business Need
 Translate MVFs into business deliverables called User Stories
 Each User Story defines the business need and the 'Done When' criteria
 User Stories sizing is on points incorporating business value, technical size and complexity
 Stories are immediately available for release after completion
 Team starts working on next highest priority story (even if the story was created today!)
 Status is represented in a Kanban Board

Ready For
In Story Writing Ready for Sizing Ready to Pull In Progress On Hold Acceptance Ready For Release Delivered

User Stories

Salient features of the model Keys success Factors

 On demand prioritization  One team model; high collaboration and trust
 Minimize Cycle Time (Concept to Delivery  Technical Team is co-located
 Faster time to market  Team is multi skilled and self-sufficient
 Effective resource utilization  Enhanced ownership for team, with decision making
 Early detection of risk powers`
8
© 2014 IBM Corporation
 Overview

Cycle Time Reducing Time to Market

9
© 2014 IBM Corporation
Kanban - Advantages

 Shorter cycle times can deliver features faster.

 Responsiveness to Change
 When priorities change very frequently, Kanban is ideal.
 Balancing demand against throughput guarantees that most the customer-centric features are
always being worked.
 Requires fewer organization / room set-up changes to get started
 Reducing waste and removing activities that don’t add value to the team/ department /
organization
 Rapid feedback loops improve the chances of motivated, empowered and higher-performing
team members

© 2014 IBM Corporation

Kanban vs Scrum
KANBAN SCRUM
No prescribed roles Scrum prescribes Roles like Scrum master,
Product owner and team member

Work is ‘pulled’ through the system (single Work is ‘pulled’ through the system in batches
piece flow) (the sprint backlog)

Measured by Cycle time Measured by Velocity

Continuous Delivery Time Boxed Delivery

Changes can be made at any time No changes allowed mid-sprint

More appropriate in operational environments More appropriate in situations where work can
with a high degree of variability in priority be prioritized in batches that can be left alone

© 2014 IBM Corporation

Kanban – Best Practices

Evaluate the quality of the growing product from a functional, engineering, and user
experience perspective on a continuous basis

Evaluate your pace of development:

• Look at the number of development items completed relative to goals
• Look at the average cycle time per development item
• Calculate the ratio of developer days per completed item. Use this ratio to estimate
the completion time for undeveloped items
• Adjust your development plan as necessary

Evaluate and adjust the process you’re using

• Use a process reflection session to identify changes you could make to improve
your product or pace

© 2014 IBM Corporation

Case Study

Intr 13 13 Introduction to Scrum | 2013 © 2014 IBM Corporation

odu
Case Study: Getty Images – Project Background
About the client
 Leading provider of imagery, film, and digital asset services
 Over 20 million images and video clips on gettyimages.com
 Over 8 million site visits and 3.2 billion thumbnails monthly
 More than 3,000 photographers and filmmakers; nearly 200 image and footage
partners
 Global infrastructure supports users in more than 170 countries
 Getty Images Media Management Services is a leading DAM solution provider in
Software-as-a-Service model

 IBM is associated with Media Management Services portfolio

 Successful partnership since May 2007
 Provides full range of services including technical solutions, platform upgrades,
product roadmap planning, standby support and maintenance
 Started with Scrum in 2009 and moved to Kanban 2 years back

© 2014 IBM Corporation

Case Study: Getty Images – Agile implementation evolved
over time
 Getty Implemented Agile Scrum in 2009
 After one year there were clear and visible benefits. The features to the production improved
significantly. The dependencies were getting resolved quickly. There were very few post
production defect release after release. Teams at offshore was discussing solutions rather
than the implementation.
 However there was still problem in seamless visibility of project status across all the levels,
prioritization was still a problem area as sometimes the product back long did not accurately
reflect the business priority. This led to two significant developments. It was felt that Kanban
will suit better to the environment and there is a need for Agile Portfolio Management.
 Getty decided to partner with Rally to develop the Kanban board which connected the
business priorities to the IT projects. It provided visibility at all levels that in turn improved
prioritization process and predictability
Benefits at a Organization Level
 Getty Images' teams eliminated hard timeline commitments in project road maps
 Although the company plans at a high level what work will be accomplished, at a detailed
level, it commits only to work that's about 60 days out and reviews those commitments at a
regular cadence
 Ball park estimates suggest the project throughput increased by at least 20%

© 2014 IBM Corporation

 Deep Dive - Need for Kanban
 Increasing the frequency of new feature roll outs
 Changing the priority on the fly is critical to Getty’s business which is
event driven
 Common understanding of WIP though out the organization

 Portfolio Management:
• Integration of the projects with the High Level Business Epics were difficult. A Kanban board gave a
integrated view of the entire portfolio to all the stakeholders including the business
 Frequent change requests
• Change request caused an average of 10% more work in each sprint than initially planned. This
caused the developers to stretch a lot to meet the time-boxed deliverables
 Increased idle time for individuals in time-boxed sprint
• Individuals used to remain idle once work was complete in time-boxed model till next iteration.
• Testers used to be idle in the beginning of sprint since developers just got started
 Multiple small projects executed at the same time
• 3-4 projects simultaneously producing 6-8 activities approximately making it difficult to manage within
a sprint cycle
• Difficult to manage an activity overlapping two iterations
 Frequent production releases
• 2-3 releases a month per product
• Unplanned releases impacted the Sprint deliverables
© 2014 IBM Corporation
Daily Mantra
 Is the board up-to-date?
• Always keep the dashboard updated. In Kanban dashboard should reflect the correct
and updated state of activities at any point of time

 Are you respecting WIP limits?

• The team always maintain a smaller number of activity in WIP(3-4 max) for a 5/6
people team. The team concentrates more in getting an activity done faster than
doing more activities.

 Are you showing blockers and working to remove them?

• Always treat blockers with higher priority. Remember that it is interrupting the
momentum and eating up your velocity. Daily calls with the stakeholders to remove
the blockers if necessary

 Do you know which task you should be working on and what is next?
• Always be aware of the next tasks that clients want to get done. It gives some time
to prepare and highlight the concerns up-front. Be updated about your “To-Do” list.

© 2014 IBM Corporation

Benefits – Team Level
 Visualization of workflow
• General awareness: Developers are always up to date with current status
• A platform to iteratively improve workflow

 Better understanding of project status

 Better handling of change requests

• Once the requirements are frozen, changes are not made in the user story
• Change requests are always in form of a new story that goes through the entire
lifecycle in the dashboard

 Better release management

• Releases are more planed and controlled. A release also requires a user story that
has traversed thru its life cycle. Unlike time-boxed model, developers get time to
plan and prepare before the release.

© 2014 IBM Corporation

Case Study: Getty Images

Getty Images: Kanban dashboard on Rally

© 2014 IBM Corporation

Case Study: Getty Images – Throughput

© 2014 IBM Corporation

Case Study: Getty Images – Productivity

© 2014 IBM Corporation

Metric - Kanban

image.net

© 2014 IBM Corporation

Case Study: Getty Images – Challenges

 Getting developers to follow workflow

• The Kanban requires some level of agile maturity to understand and follow the workflow. New
developers required close guidance and education on Kanban

 Getting developers to respect WIP limits

• starting on more tasks than one can handle sometimes created a problem. In Kanban
Manageable WIP is a key success factor

 Getting developers to team up on bottlenecks

• Since individual developer can be dedicated to a single task, it is difficult to shift their focus if
there is any blocker

 Handling exceptions to the flow

• In case of exceptions the developers do not know what to do as there is no clear guideline. e.g.
A user story in WIP became insignificant due to the changed requirement. Since there was no
point doing any further work , developer did not know what to do

Close collaboration is required to overcome the challenges

© 2014 IBM Corporation

 Agile Community @ IBM
Agile@IBM India

https://w3-
connections.ibm.com/wikis/home?lang=en#!/wiki/W9d84733e3267_4565_a7b4_7
ff0f9177fa5/page/Agile%20Center%20of%20Competency

24
24
24 Introduction to
Introduction to Scrum
Scrum || 2013
2013 © 2014 IBM Corporation
 25
25 Introduction to Scrum | 2013 © 2014 IBM Corporation