Advance Agile Handout

ADVANCED AGILE METHODOLOGIES
1
Broad Topics
Distribute Agile and Scrum of Scrums in Practice Discussion
Case Study on Distributed Agile
Discussion on Quality aspects in Agile Environment and Case
Scrum & Kanban and Scrumban Introduction and Pearson Case
Critical Success Factors in Agile Implementation Case mpirical
Research on Critical Success Factors of Agile Software Process
Improvement
Agile Process Flow and Agile Factory Model Going Agile Case
Study
Human Aspects in Agile Software Transition Case How Human
Aspects Impress Agile Software Development Transition and
Adoption
Value Driven Delivery 1 Case Business Value is not only Dollars
Results from Case Study Research on Agile Software Projects.
Value Driven Delivery -2 Case Do we Know Enough about
Requirements Prioritization in Agile Projects
Value Driven Delivery -3 Risk Adjusted Agile, ROI, NPV and IRR
Models and exercises
11-01-2017 2
Scaling Scrum
50 People
(Architects, Coders, Testers, Analysts, UI Designers, Technical Writers, etc.)
11-01-2017 3
Scaling Scrum
Team A Team B Team C Team D Team E
11-01-2017 4
Scaling Scrum
Feature Teams

Cross-Functional Cross-Functional Cross-Functional Cross-Functional Cross-Functional
(Designers, Coders, (Designers, Coders, (Designers, Coders, (Designers, Coders, (Designers, Coders,
Testers, etc.) Testers, etc.) Testers, etc.) Testers, etc.) Testers, etc.)
11-01-2017 5
Scaling Scrum
1 Feature A
2 Feature B
3 Feature C
4 Feature D
5 Feature E
6 Feature F
7 Feature G
8 Feature H
9 Feature I
10 Feature J
11 Feature K
12 Feature L
13 Feature M

Cross-Functional Cross-FunctionalCross-Functional Cross-Functional Cross-Functional
11-01-2017 6
Scaling Scrum
1 Feature A
2 Feature B
3 Feature C
4 Feature D
5 Feature E
6 Feature F
7 Feature G
8 Feature H
9 Feature I
10 Feature J
11 Feature K
12 Feature L
13 Feature M

11-01-2017 7
Scaling Scrum
Chief Product Owner
Product Owner Product Owner Product Owner

11-01-2017 8
During the Sprint
Scrum of Scrums
Daily Meeting of Team Representatives
Coordination, Dependencies Mgt, Block Surfacing
11-01-2017 9
Project Growth
10
SPRINT SPRINT SPRINT SPRINT SPRINT
11-01-2017
Synchronizing Sprints
11-01-2017 11
Dependencies: Day-to-Day
Make direct team-to-team communication as easy as possible for
everyone on the project
Use the Scrum-of-Scrums actively
Make sure all teams have some slack (extra buffer) in every Sprint, to
be able to help each other
11-01-2017 12
Dependencies: Backlog-Level
Team A Team B
Identify the dependency
Backlog Item #1 before Sprint Commitment is
made
Then, either
Product Owner A reduces
priority of #1
or
Product Owner B increases
priority of #18
or
Product Owner A shifts #18
to Team A Product Backlog
and Team A builds it
or
Team A uses mock object in
Backlog Item #18 place of #18, and replaces
with actual #18 later
Product Backlog Product Backlog

11-01-2017 13
Distributed Scrum Practices
Example 1: Product Owner in US, Team in India
One Common Approach

ScrumMaster is located with team in India
Start with short Sprints (for example, 2 weeks)
Team holds Daily Scrum in their own location, at a
convenient time
ScrumMaster emails blocks list to Product Owner for
assistance clearing in US
11-01-2017 14
Distributed Scrum Practices
Sprint Planning
Sprint Planning 1
1 hour real-time call with Team and Product Owner to review highest priority Product Backlog
Items and the Definition of Done
Monday evening India / morning US
Sprint Planning 2a
Team spends 2-3 hours doing preliminary analysis and breakdown of Product Backlog Items)
Tuesday daytime India
Sprint Planning 2b
1 hour real-time call with Product Owner to complete analysis and breakdown of Product Backlog
Items, and make commitment)
Tuesday evening India / Tuesday morning US
Sprint begins
Wednesday morning India
Sprint Review and Retrospective
2-3 hour call with Team and Product Owner
Friday morning India / Thursday evening US
11-01-2017 15
Distributed Team
Example 2: Team split between two locations

4 team-members in India, 4 team-members in Europe
To be effective, true team formation must take place
Ideally, colocation for a minimum of 1-2 Sprints
Ongoing ambassadorship
Multiple forms of continuous live communication
If you cant make this investment, will probably be better to
split them into two different Scrum teams
Daily Scrum
Live via webcam if timezones overlap, otherwise try
cameraphone video recording
Scrum Artifacts (Sprint Backlog, Burndown Chart) done
electronically, in a shared location
11-01-2017 16
Distributed Scrum Best Practices
Product Owner travels to India for project kickoff
All real-time meetings between team and Product Owner
must be visual audio is not enough
Videoconference + Desktop Sharing
Extensive use of Wikis / other live doc solution
Product Backlog and all related requirements /
background info
Current list of blocks / impediments
Personal contact information and OK hours for contact for
Product Owner, ScrumMaster and Team
At least 1 weekly 1-hour real-time check-in between Product
Owner and team
In-person planning and review regroup in India between
Product Owner and team every 3-4 months
11-01-2017 17
Start of the Project During the Project
T
R
U
S
T
C
O
M
M
U
N
I
C
A
T
I
O
11-01-2017 18
N
11-01-2017 19
11-01-2017 20
11-01-2017 21
11-01-2017 22
11-01-2017 23
11-01-2017 24
11-01-2017 25
11-01-2017 26
Distributed Agile Leading Financial Services Provider, UK
Case Study
September 2011
TCS Confidential
Distributed Agile Projects A field Example
About the Relationship
Leading Financial Services Provider

A leading Private Medical Insurance provider
Program:
Launch new Policy administration platform
Enhance Claims management system
Services :
Application Development & Enhancements
Application Support and Recovery
Application Testing
Delivering services using proven onsite offshore model (67 + Associates & 78% Offshore)
Distributed Agile methodology for Development, Enhancement and Testing Projects (50 + Associates & 83%
Offshore)
Technologies : C#, Java, Mainframe and Visual Basic
Geographies : UK : Edinburgh & Bournemouth & India : Chennai
Agile Specifics
Blend of Scrum and XP with the mix of best practices

Iteration Duration : 2 to 6 weeks (Generally 4 weeks)
Scrum Team size : 6 to 9
# of parallel scrums : 4 to 7
Distributed Agile in Partnership - Step, Walk, Run
Distributed
(Offshore)
Distributed environment
simulation (same town 2
offices) Distributed
Coordinators in 1 office, 2 Iterations
(Near Site)
team in other office
Communication, process Adopt to bigger team
mechanism learnings- Review & Refine Continuous improvement in
documentation, processes / mechanisms
collaboration, Task
allocation
2 Iterations
Co-Location
Small team with representation
from each Technology streams
C#, JAVA, Mainframes
Co-Sourced : Work closely with
client Analysts and Developers
Understanding of client Agile
Pre- processes , application,
Engagement architecture
Planning
Client
Company
Distributed Agile Execution Model
Client & Company Design, Verify, Accept and Implement

Burn Down Charts
Scrum Master, Client & Company Onshore Velocity
Onsite Daily Scrum Meetings Feedback Reports
Product
Backlog
Scrum Master Client Product Owner
Company Onshore Company Scrum Master
Product Owner
Onshore Client
Scrum Master
Company Onshore
Client & BA
Sprint Sprint
Sprint Scrum Weekly
Backlog Scrum of Scrum Retrospective
Planning Technical Scrum Catch-up Meeting
Meeting
Offshore Team Company Offshore Company Offshore

Scrum Master
Offshore Daily Scrum Meetings

Scrum Master, Company Onshore
Design, Build, Test, and Deliver Feedback Reports
Company Offshore
Iteration N-1, 4th Week Week 1 Week 2 Week 3 Week 4 1st Week of Iteration N+1
Planning for Iteration N* Company Offshore Iteration N Retrospective of Iteration N
Scrum Master
* Client Follows 4 week Iteration
Offshore Scrum Master - From Company Offshore team
Product Owner from Client & Onshore Scrum Master Either from Client or Company Onshore Team
Achievements & Critical Success Factors
One Team
approach
Focus on Proactive
Continual Increased Time to Engagement
Improvements Market at lower cost Management
Rarely & Unused Code

only 9% (Industry
Average - 45%)
14% - 110% more
Productive
Early Recognition Best Use of

of Challenges in Technology /
Multi-Location Social Computing
Delivery Tools
Shortlisted as the Top ten IT Project Team of the Year 2009 by British Computer Society IT Industry
31
Distributed Scrum Challenges and Best Practices
ChallengesChallenges
& Best Practices / Enablers Best Practices / Enablers
Open up communication across team enabled by tools Tele Conference, Video Conference, Instant Messenger,
Webcam
Establish appropriate governance provisions for setting Governance meetings at Technical, Operational, Strategic
directions and managing the overall outcome and Steering committee level
Make an effort to get to know people Ambassador Visits by Customer
Onshore Offshore Rotation
Focus on Knowledge Management Focused scrums to build knowledge repository
Encourage Out-of-the-Box thinking Technical Scrums, Value Benefit Tracker
Implementation of Planning and Tracking Tools XPlanner

accessible to both onsite & offshore teams
Virtual ScrumBoards and Issue Tracker through Wiki
Focus on continual learning and improvement through Drives to focus on specific areas through fun filled activities
fun filled activities
QFest To focus on Quality Process and Lean Principles
DFest To Enhance Domain Knowledge
Assign mentors for new / inexperienced team members Pair Programming through WebEx
Open Estimation Techniques Poker Planning through Video Conference and Webcam
KANBAN
These steps include user story creation, development, test and

deployment.
Doesnt utilize a time-box for each development sprint.
Instead, Kanban imposes work in progress limits from each
development step.
The overall process can be optimised by imposing and adjusting
these limits.
Team members focus on system bottlenecks to reduce the overall
feature throughout time by eliminating waste (muda) throughout the
process
Unlike other Agile processes which use velocity as their key metric,
Kanban uses throughput for individual features like key metric.
Improving speed and effectiveness of inhouse
software development
Scrum(ban)
11-01-2017 35
11-01-2017 36
11-01-2017 37
11-01-2017 38
11-01-2017 39
11-01-2017 40
11-01-2017 41
11-01-2017 42
11-01-2017 43
11-01-2017 44
11-01-2017 45
11-01-2017 46
11-01-2017 47
11-01-2017 48
11-01-2017 49
11-01-2017 50
11-01-2017 51
11-01-2017 52
11-01-2017 53
11-01-2017 54
11-01-2017 55
11-01-2017 56
Kanban cards limit excess work in
progress
Kanban literally means visual
card, signboard, or billboard.
Toyota originally used Kanban cards
to limit the amount of inventory tied
up in work in progress on a
manufacturing floor
Not only is excess inventory waste,
time spent producing it is time that
could be expended elsewhere
Kanban cards act as a form of
currency representing how WIP is
allowed in a system.
57
Kanban simulation
Lets simulate a simple process, then see if we can
improve it by adding a Kanban system.
Ill need 5 volunteers to manufacture the latest in

high-tech aircraft
58
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
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
59
Inside an iteration, effort across roles is
uneven
Development work often continues throughout a cycle while

testing starts late and never seems to get enough time
60
Using a Kanban approach in software drops time-boxed
iterations in favor of focusing on continuous flow.
61
How to set up a simple Kanban system
for a software development team.
62
1. Define a work process flow
This simple process flow has the steps:

1.elaboration & acceptance criteria
2.development
3.test
4.deployment
Look at the typical flow for features, stories, or work

packages and describe typical process steps
63
2. Lay out a visual Kanban board
Place an expedite track above the main

left to right queue
Place done and waiting queues between

each work queue
(in this example theyre placed below)
Place a goals column on the left, then a waiting queue, the

process steps, and a final done column to the right
64
3. Decide on limits for items in queue
and work in progress
This board uses painters tape to indicate

available slots for work in progress
A good limit is a factor of the number of people in a role that can

work on an item in a given process step. Start with number of people
* 1.5
65
4. Place prioritized goals on the left
column of the board
Having goals visible:

promotes focus
helps us prioritize
helps us manage feature scope &
requirements
A good goal describes the outcome we hope to achieve after software

ships. Goals help keep focus on the larger outcome.
66
5. Start the board by placing stories or
features in queue
Product owners manage the waiting

queue
Mark on the story or feature card the date it entered the queue. This
begins our measurement of cycle time.
67
6. Move features through the process
flow as work is completed
As the story enters the first process step, mark that date on the card.
This is the start date. As its finished, mark that date on the card.
This is the finish date.
68
7. Use the dates on the cards to calculate
cycle time
Cycle time = finish date start date

The average cycle time from the date the
item enters the board is the wait time
from this point in the queue
Use average cycle time to set wait times from different points on the board.
Pay attention to flow and bottlenecks: relieving bottlenecks as quickly as
possible.
69
Display and manage cycle times
Disneylands
public display of
cycle-times
70
Reduce the number of Kanban slots allowed until cycle
time remains unchanged
Reduce the size of development items
Work in progress is actually the number of items * the

average size of items
Identify and act on bottlenecks immediately
Relieve repeated bottlenecks by changing the number

and types of people in each role and cross training
11-01-2017 71
Kanban Boards
72
Kanban Boards
73
Kanban Boards
74
Kanban Boards
75
Kanban Boards
76
Explode large process steps into tasks to
improve visibility
When a feature, user story, or work item is large:
Takes longer than a couple days to complete
Requires that multiple people collaborate on its completion
Decompose that step into cards to track independently
Feature to Tasks in Tasks Feature

develop Tasks in queue progress complete complete
77
Kanban Board with Task Decomposition
78
Use cumulative flow diagrams to
visualize work in progress
www.agilemanagement.net/Articles/Papers/BorConManagingwithCumulat.html
79
Use cumulative flow diagrams to
visualize work in progress
www.agilemanagement.net/Articles/Papers/BorConManagingwithCumulat.html
80
Keep time-boxed product and process
inspection
Keep regular time-boxes in your process as a cue for product inspection:
Evaluate the quality of the growing product from a functional, engineering,
and user experience perspective
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 youre using
Use a process reflection session to identify changes you could make to
improve your product or pace
Ending cycles right: http://www.stickyminds.com/s.asp?F=S14865_COL_2

81
Begin looking at your process using Lean thinking
Cockburns Software Engineering in the 21st Century:

http://alistair.cockburn.us/Software+engineering+in+the+21st+century.ppt
82
Since were engaged in knowledge work look at
the cycle time of validated decisions, or knowledge

83
Often the feedback loop is overlooked its the
invisible backed-up queue

84
Setting up a simple Kanban
system starts to focus the team on
the cycle-time of delivered work
and gives a way to detect and
begin to resolve bottlenecks
85
Kanban Vs Scrum
8
6
Scrum in a nutshell
Split your organization
Split your product
Large group spending a long time building a big thing

Small team spending a little time building small thing
... but integrating regularly to see the whole
Optimize process
Optimize business value
$$$
Split time
January April
8
7
Kanban in a nutshell
To do Dev Test Release Done!
5 3 2 3
Visualize the workflow Limit H D C A

G
WIP (work in progress) Measure
B
K
& optimize flow
FLOW
8
8

Roots of Kanban Kan
(Toyota) Ban
Visual Card
Buyer Supplier
Consume Detach Receive Ship Allocate Manufacture
The two pillars of the Toyota production system

are just-in-time and automation with a human
touch, or autonomation.
The tool used to operate the system is kanban.
Taiichi Ohno
Father of the Toyota Production System
8
9
Kanban in software development
9
0
Kanban and Scrum are both process tools
Physical tools Process tools
a.k.a. organizational patterns
Product Owner role
Pair programming
Brownbag meetings
9
1
Prescriptive vs adaptive
More prescriptive More adaptive
RUP XP Scrum Kanban Do Whatever

(120+) (13) (9) (3) (0)
Architecture Reviewer Business use case realization
Business Designer Business use-case model Wholeteam Scrum Master Visualize the workflow
Business-Model Reviewer Business vision
Coding standard Product Owner Limit WIP
Business-Process Analyst Change request
Capsule Designer Configuration audit findings TDD Team Measure and optimize lead time
Change Control Manager Configuration management plan Collectiveownership Sprint planning meeting
Code Reviewer Data model Customer tests DailyScrum
Configuration Manager Deployment model Pairprogramming Sprint review
Course Developer Deployment plan Refactoring Product backlogt
Database Designer Design guidelines
Planning game Sprint backlog
Deployment Manager Design model
Design Reviewer Development case Continuous integration BUrndown chart
Designer Development-organization Simpledesign
Graphic Artist assessment Sustainable pace
Implementer End-user support mateirla Metaphor
Integrator Glossary Small releases
Process Engineer Implementation model
Project Manager Installation artifacts
Project Reviewer Integration build plan
Requirements Reviewer Issues list
Requirements Specifier Iteration assessment
Software Architect Iteration plan
Stakeholder Manual styleguide
System Administrator Programming guidelines
System Analyst Quality assurance plan
Technical Writer Reference architecture
Test Analyst Release notes
Test Designer Requirements attributes
Test Manager Requirements management plan
Tester Review record
Tool Specialist Risk list
User-Interface Designer Risk management plan
Do not develop an attachment

Architectural analysis Software architecture document
Assess Viability of architectural proof- Software development plan
of-concept Software requirements specification

Capsule design
Class design
Construct architectural proof-of-

Stakeholder requests
Status assessment
Supplementary business specification
to any one weapon
or any one school of fighting
concept Supplementary specification
Database design Target organization assessment
Describe distribution Test automation architecture
Describe the run-time architecture Test cases
Design test packages and classes Test environment configuration
Develop design guidelines Test evaluation summary

Develop programming guidelines
Identify design elements
Identify design mechanisms

Test guidelines
Test ideas list
Test interface specification
Miyamoto Musashi 17th century

Incorporate design elements
Prioritize use cases
Review the architecture

Test plan
Test suite
Tool guidelines
samurai
Review the design Training materials
Structure the implementation model Use case model
Subsystem design Use case package
Use-case analysis Use-case modeling guidelines
Use-case design Use-case realization
Analysis model Use-case storyboard
Architectural proof-of-concept User-interface guidelines
Bill of materials User-interface prototype
Business architecture document Vision
Business case Work order
Business glossary Workload analysis model
Business modeling guidelines
Business object model
Business rules
Business use case
b 8
Henrik Kni erg
Scrum prescribes roles
PO SM
9
3
Scrum prescribes iterations
Scrum team week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Kanban team 1 Sprint 1 Sprint 2
Plan & commit Demo

(release?) Retrospective
Kanban team 2 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Retrospectives (4w)
Planning cadence (2w)
Release cadence (1w)
Kanban team 3 week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8
Retrospectives (4w)
Planning (on demand)
Release (on demand)

Both limit WIP, but in different ways
Scrum board Kanban board
To do Ongoing Done :o) To doOngoing Done :o)

2
A A
B B
C C
D D
FLOW FLOW
WIP limited per unit of time WIP limited per workflow state
(iteration)
Both are empirical
Capacity Lead time Quality Predictability

(aka velocity) (aka cycle time) (defect rate, etc) (SLA fulfillment, etc)
Kanban is more configurable
Many small teams Few large teams Great! More options! Oh no, more complicated!
Low WIP limits High WIP limits
Few workflow states Many workflow states
Short iterations Long iterations
Little planning Lots of planning
.... etc ... .... etc ...

Example: Experimenting with W I P limits
Monday, Week 1 Monday, Week 2 Monday, Week 3 Monday, Week 4
To do Ongoing Done :o) To do Ongoing Done :o) To do Ongoing To do Ongoing
Done :o) Done :o)
1 8 8 8
B A C A D
C B A A
D E D H E B E B
E F I C L F C
F
F G
G
ZZZZzzzzzz
I
Were idle & bored! Problem with J
Lets increase WIP integration server. K
limit to 8!
Cant finish D & E!
Well work on F & G Oops. WIP limit
instead! reached. Now we
HAVE to stop and
Lets reduce WIP
Monday, Week 5 fix the integration
limit to 4, so we
server!
To do Ongoing react earlier next
Done :o)
4 time!
N L J
O M K
P
Id like to have E!
Scrum doesnt allow change in

mid-iteration
PO
Wait until a To Do slot

becomes available!
Wait until next sprint! Or swap out C or D!
Scrum Kanban
To do Ongoing Done :o) To do Ongoing Done :o)

2 2
C A C A
D B D B
FLOW FLOW
Scrum board is reset between each
iteration
Scrum
First day of sprint Mid-sprint Last day of sprint
Kanban
Any day
Scrum prescribes cross-functional teams
Scrum Kanban example 1 Kanban example 2
Specialist Specialist
Cross-functional team
Cross-functional team
Cross-functional
team
team
Scrum backlog items must fit in a sprint
Scrum
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Kanban
Long running task

WIP limit = 3 Long running task
In Scrum, estimation and velocity is
prescribed
V= 8 V= 7 V= 9
1 2 2 1 1 2
Likely velocity: 8 per sprint
2 3 1 3 1 2 2 1 (sustainable pace?)
Sprint 1 Sprint 2 Sprint 3

Both allow working on multiple products
simultaneously
Scrum example 1 Kanban example 1
Color-coded tasks
Green Product Yellow Product
Green team Yellow team
Scrum example 2 Scrum example 3 Kanban example 2

All products All products Color-coded swimlanes
Cross-product team Cross-product team
1. Base your management decisions on a Long-Term Philosophy, Even at the
Expense of Short-Term Financial Goals
2. Create Continuous Process Flow to Bring Problems to the Surface
Both are Lean 3.

4.
Use Pull Systems to Avoid Overproduction
Level Out the Workload (Heijunka)
and Agile
5. Build a Culture of Stopping to Fix Problems, to Get Quality Right the First Time
6. Standardized Tasks are the Foundation for Continuous Improvement and
Employee Empowerment
7. Use Visual Controls So No Problems are Hidden
8. Use Only Reliable, Thoroughly Tested Technology That Serves Your People and
Processes
9. Grow Leaders Who Thoroughly Understand the Work, Live the Philosophy, and
1. Individuals and Interactions over Teach It to Others
Processes and Tools
10. Develop Exceptional People and Teams Who Follow Your Companys Philosophy
2. Working Software
over Comprehensive Documentation 11. Respect Your Extended Network of Partners and Suppliers by Challenging Them
and Helping Them Improve
3. Customer Collaboration over
Contract Negotiation 12. Go and See for Yourself to Thoroughly Understand the Situation (Genchi
Genbutsu)
4. Responding to Change over
Following a Plan 13 Make Decisions Slowly by Concensus, Thoroughly Considering All Options;
Implement Decisions Rapidly
14. Become a Learning Organization Through Relentless Reflection (Hansei) and
Continuous Improvement (Kaizen)
Lean
Quality Cost Lead Time
People
Just in Stop the
Time Line
Kaizen
Waste
reduction
Operational stability 2200

Minor difference:
Scrum prescribes a prioritized product backlog
Scrum: Kanban:
Product backlog must exist Product backlog is optional
Changes to product backlog take Changes to product backlog take
effect next sprint (not current effect as soon as capacity becomes
sprint) available
Product backlog must be sorted Any prioritization scheme can be
by business value used. For example:
Take any item
Always take the top item Always take the oldest
item
20% on maintainance items, 80% on new features
Split capacity evenly between product A and product
.. but many teams combine these approaches B
Always take red items first
Minor difference: Scrum prescribes daily meetings
... but many Kanban teams do that anyway.

Minor difference:
In Scrum, burndown charts are prescribed
No specific types of
diagrams prescribed in
Kanban. Teams use
whatever they need.
Example: Scrum board vs Kanban board
Scrum
Product Sprint backlog
backlog
Committed Ongoing Done :o)
E F G
E F G H
A
B
H I C
J
K D
L M
Kanban
Dev
Backlog Selected 3 In production
2 :o)
D E B A X
F C R
G
H Q
I
J M
LK
Scenario 1 one piece flow
Dev
Backlog Selected 3 In production :o)
2
Ongoing Done
A
B
G
C
F
D
H
I
J L E
M K
Dev
2
Ongoing Done
A
G
B
C
F
D
H
I
J L E
M K
Dev
2 Ongoing Done
A
G
B
C
F
D
H
I
J L E
M K
Dev
2
Ongoing Done
C
A
G
D
B
F
H
I
J L E
M K
Dev
2 Ongoing Done
C
A
G
D B
F
H
I
J L E
M K
Dev
2 Ongoing Done
F D C A
G B
E
H
I
J L
M K
11
4
Scenario 2 Deployment problem
Dev
2
Ongoing Done
A
B
G
C
F
D
H
I
J L E
M K
11
5
Dev
2
Ongoing Done
A
G
B
C
F
D
H
I
J L E
M K
11
6
Dev
2 Ongoing Done
C A
G
D B
F
H
I
J L E
M K
11
7
Dev
2 Ongoing Done
C A
G
D B
F
H
I
J L E
M K
11
8
Dev
2
Ongoing Done
A
C
G
B
D
!?
F
H
I
J L E
M K
11
9
Dev
2
Ongoing Done
A
G !?
D B
F E C
H
I
J L
M K
12
0
Dev
2
Ongoing Done
A
G
D B
F E C
H
I
J L
M K
12
1
Dev
2
Ongoing Done
A
G
D B
F E
C
H
I
J L
M K
12
2
Dev
2 Ongoing Done
D A
G
B
E
F
C
H
I
J L
M K
12
3
Kanban vs Scrum www.crisp.se/henrik.kniberg/kanban-vs-scrum.pdf
Summary
Similarities
Both are Lean and Agile

Both based on pull scheduling Both limit WIP
Both use transparency to drive process improvement
Both focus on delivering releasable software early and often
Both are based on self-organizing teams
Both require breaking the work into pieces
In both cases the release plan is continuously optimized based on
empirical data (velocity / lead time)
4400
Scrum Kanban
Timeboxed iterations prescribed. Timeboxed iterations optional.
Team commits to a specificamount Commitment optional.

of work for this iteration.
Uses Velocity as default metric for Uses Lead time as default metric for
planning and process improvement. planning and process improvement.
Cross-functional teams optional.
Cross-functional teams Specialist teams allowed.
prescribed.
No particular item size is prescribed.
Items broken down so they can be
completed within 1 sprint.
No particular type of diagram is

Burndown chart prescribed prescribed
WIP limited directly (per workflow
WIP limited indirectly (per sprint) state)
Estimation prescribed Estimation optional
Cannot add items to ongoing Can add new items whenever
iteration. capacity is available
A sprint backlog is owned by one A kanban board may be shared
specific team by multiple teams or individuals
Prescribes 3 roles (PO/SM/Team) Doesnt prescribe any roles
A Scrum board is reset between A kanban board is persistent
each sprint
Prioritization is optional.
Prescribes a prioritized product
11-01-2017 125
Most importantly:
Start with
retrospectives!
41
Scrumban
What it is and when to use it.
75% of organizations using Scrum will not succeed in
getting the benefits they hope for from it.
-Ken Schwaber
1
3
1
Consistent Problem Areas
Cargo Cult implementations
Productivity or Perceived
Productivity Predictability
TRUST
Disconnection with economics
Cargo Cult implementations
Organizational Apathy
Worker or Work focus not value
focused
1
Official Licensed Material CodeGenesys, LLC 3
2
Starting With The End In Mind
How can you tell if youre on the right path if you dont know where youre going?
Would you tell me, please, which way I ought to go from here? asked
Alice.
"That depends a good deal on where you want to get to," said the Cat.
"I don't much care where " said Alice.
"Then it doesn't matter which way you go," said the Cat.
" so long as I get somewhere," Alice added as an explanation.
"Oh, you're sure to do that," said the Cat, "if you only walk long enough."
1
Official Licensed Material CodeGenesys, LLC 3
3
Scrumban
A misunderstood concept
Whats Your Perspective?
Which of these descriptive labels would

you apply to scrumban?
Agile without Sprints / Time-boxes No
Scrum Master or equivalent role No
estimation
kanban inside Scrum
Scrum inside Kanban No project burn
downs
10
Official Licensed Material CodeGenesys, LLC
Scrumban : Original manifestation
Backlog Dened In Progress Done Accepted
Pull System
Limit = 4 Limit = 3 Limit = Limit = Single piece flow
Blocked
Blocked
13
5
Scrum
Team-centric & focused on promoting agility. Framework Values Kanban
Service delivery & evolutionary change
Supporting successful outcomes
Focus Understanding Transparency
Agreement
Courage
Respect
Openness Leadership
Commitment Collaboration
Flow
Customer Focus
Respect
Balance
TRUST
Official
Scrumban
Grow sustainably
Framework Values
Supporting successful outcomes
Constructive Interaction
Empiricism There will always be competing
Empirical approaches are always favored over management
theories, and verifiable results over dogma. frameworks and methods. Scrumban
emphasizes constructive debate that
Humility improves understanding of the strengths
Systems are complex and constantly changing,
and limitations of each over blind
and we are constantly learning. We must always
acceptance that any one framework
be ready to challenge our beliefs. Improved
represents the only or best way of
understandings and approaches can come from
achieving a particular outcome.
any source.
TRUST
What is Scrumban?
Three EssentialFlavors
Using Kanban as a lens through which we can view

and manage a Scrum work process.
Recognized Manifestations
1 A framework for evolving from Scrum to

a unique set of processes and practices.
2 A framework for introducing and

adopting Scrum as a software
development methodology.
A framework for overcoming common

3
challenges with scaling Scrum across
an Enterprise.
CodeGenesys, LLC
Applying the Kanban Lens to Scrum
Different lenses for different perspectives
Using Kanban as a lens into

existng systems enables us
to focus on the right
things even when theyre
outside of our dened
processes.
CodeGenesys, LLC
Lead Time
A productivity measure
Amplify Scrum
Understand, Identify and Improve
Scrum commonly does well around
These bring additional perspectives and capabilities to the Scrum context
Team focus aiding vision alignment
Importance of cadence, rhythm
Focus on shorter term planning compared to tradi2onal methods
Call for customer partcipation; Value from customers stand point
Focus on smaller batches.

Key Enabler: High trust
Collaboration enabler environment
Shared ownership, Cross functional work

Scrum commonly does not do well around
These bring additional perspectives and capabilities to the Scrum context
Nature of work- specically - Its arrival, its unpredictability Longer term

considerations such as architecture Addressing psychological barriers in
implementation Product owner role eectiveness and scale
Scaling constructs unreliable beyond the team
Sprint Commitments relationship to Market Risks Longer term quality
considerations
Deterministic planning
Share ownership emergence
Reliance on top down/vertical buy-in with armations of servant
leadership
22
Scrumban: Amplify Scrum
A framework for evolutionary change and continuous improvement
Four familiar principles
Start with SCRUM you already Agree as a Scrum team to pursue

do incremental changes to improve the
way you work
Respect the Scrum Master, Encourage acts of leadership at all

Product Owner and other current levels
roles
Started with Improved Visualization
Understanding the current context

New Metrics Exposed New Understandings
Understanding the current context
Evolved Existing Visualizations
Responding to improved understandings

More Metrics, Deeper Understandings
Using Kanban as a lens, the team better understood what to focus upon in terms of addressing challenges.
Sprint Flow Eciency
Working Time Working Time + Waiting Time
63%
30
Initial Improvements
Effects from using Kanban as a lens after just 10 weeks
Key Enablers
Trust in the workers and the system
Mapped the Value Stream
Analyzed Flow, Visualized External

Dependencies
Captured Objective Data and

Negotiated SLEs

1. Challenges and 2. Potential eorts are
opportunities are contextualized as to whether
iden2ed and added to
a backlog of
Visualizing Improvement they are reactive or pro-ac2ve
(top vs. boeom quadrants) and
potential eorts. Adding discipline & visualization to continuous improvement paradigm-changing or
paradigm-consistent (leg vs.
right quadrants)
3. Team prioritizes
change eorts and
undertakes a
disciplined, iterative
approach toward
target conditions.
Visualizing Improvement
Adding discipline & visualization to continuous improvement
Common Scrum functions /

practices can be visualized to
reect core mechanisms to try
using as countermeasures for
moving from current condition to
target condition.
Harmonizing with other methods and frameworks
This Mammoth Bank Team

incorporated A3 Problem Solving
and the Cynen Complexity
Management framework as part
of their continuous improvement
discipline.
This worksheet was developed

through the point of
implementing and measuring the
impact of their countermeasures.
Note the visualization of current
conditions.
Harmonizing with other methods and frameworks
Note the con2nued emphasis on

visualizing of results and
iden2ca2on of next steps in this
itera2ve process.
Scrumban
Scrumban
Disruptive
Scrumban
Cargo Cult
Core principles of
Implementations
Common Implementations
Emphasis on Active risk recognition start with what you do
systems thinking and and management now and respect
Challenges understanding of improves ability to aeack
Broken current roles and
current context helps highly variable work items responsibilities
Amplifying Scrum assure teams and Commitments
early. minimizes psychological
organizations dont Expanded opportuni2es barriers.
just blindly apply to build trust through Preference for
prescribed roles and probabilisticly determined evolutionary vs.
ceremonies. SLEs vs. just a Sprint revolutionary change
commitment. minimizes disrup2on.
Scrumban
Inexperienced Scrumban Scrumban Scrumban
Product
No Owner
longer reliant
on individual Not all systems are Visual board radiates Additional prac2ces
capabili2es of created equal, and status. and mechanics allow
Product Owner. Risk sometimes the right Emphasis on the teams to eectively
and economic size falls outside of - ow of work over the collaborate from
prioritiza2on is Scrums recommended activities of individual diverse geographic
visualized and can be 7-12 person limit. workers mitigates risk locations.
of meaningless Scrumban aids in
actively managed at
Arbitrary Team Longconversations
Standups on
Forced Co-location
building trust.
every phase of the
value stream. Size status. 37
@ajrdy Official Licensed Material CodeGenesys, LLC
ajay.reddy@codegenesys.co
m
57
Before Sprint planning meeting
During Sprint
Burndown : DEVELOPED vs. INSTALLED
Cumulative flow diagram
Cumulative Flow Diagram
160
140
120
100 ESTIMATED
IN PROGRESS
DEVELOPED
80
INSTALLED
BEING USED
60
40
20
0
01.04.2009 06.04.2009 11.04.2009 16.04.2009 21.04.2009 26.04.2009 01.05.2009 06.05.2009 11.05.2009 16.05.2009

Advance Agile Handout

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Advance Agile Handout

Încărcat de

Drepturi de autor:

Formate disponibile

ADVANCED AGILE METHODOLOGIES

Team A Team B Team C Team D Team E

Team A Team B Team C Team D Team E

Team A Team B Team C Team D Team E

Team A Team B Team C Team D Team E

Chief Product Owner

Product Owner Product Owner Product Owner

Team A Team B Team C Team D Team E

Team A Team B Team C Team D Team E

Use the Scrum-of-Scrums actively

Product Backlog Product Backlog

One Common Approach

Example 2: Team split between two locations

About the Relationship

Leading Financial Services Provider

Blend of Scrum and XP with the mix of best practices

Client & Company Design, Verify, Accept and Implement

Offshore Team Company Offshore Company Offshore

Offshore Daily Scrum Meetings

Rarely & Unused Code

Early Recognition Best Use of

Implementation of Planning and Tracking Tools XPlanner

These steps include user story creation, development, test and

Ill need 5 volunteers to manufacture the latest in

Common problems include:

Development work often continues throughout a cycle while

This simple process flow has the steps:

Look at the typical flow for features, stories, or work

Place an expedite track above the main

Place done and waiting queues between

Place a goals column on the left, then a waiting queue, the

This board uses painters tape to indicate

A good limit is a factor of the number of people in a role that can

Having goals visible:

A good goal describes the outcome we hope to achieve after software

Product owners manage the waiting

Cycle time = finish date start date

Reduce the size of development items

Work in progress is actually the number of items * the

Identify and act on bottlenecks immediately

Relieve repeated bottlenecks by changing the number

Feature to Tasks in Tasks Feature

Evaluate your pace of development:

Ending cycles right: http://www.stickyminds.com/s.asp?F=S14865_COL_2

Cockburns Software Engineering in the 21st Century:

Cockburns Software Engineering in the 21st Century:

Cockburns Software Engineering in the 21st Century:

Split your product

Large group spending a long time building a big thing

Visualize the workflow Limit H D C A

Consume Detach Receive Ship Allocate Manufacture

The two pillars of the Toyota production system

Product Owner role

More prescriptive More adaptive

RUP XP Scrum Kanban Do Whatever

Do not develop an attachment

Kanban team 1 Sprint 1 Sprint 2

Plan & commit Demo

Planning cadence (2w)

Release cadence (1w)

Planning (on demand)

Release (on demand)

To do Ongoing Done :o) To doOngoing Done :o)

Capacity Lead time Quality Predictability