How We Got Here
1969
Waterfall Development
2000
Scrum: 2005Kanban: 2012
Feb 2, 2015
Strengthened Commitment to Agile
and Lean
The Premise
• There is no standard project management approach that works for all projects.
• The choice of the approach for managing a project depends on various factors such as: • Complexity and type of project,• Experience in conducting similar projects within the
organization, • The Client’s willingness to be involved in the project• The norm in the industry
Agile Development
Requirements and solutions evolve through the collaborative effort of self-organizing teams
Characteristics• Adaptive planning,• Evolutionary development, • Early delivery, • Continuous improvement, • Rapid and flexible response to change.
• Eliminate Waste
• Empower the Team (Respect
People)
• Defer Commitment
• Amplify Learning (Build
Knowledge)
• Deliver Fast
• Build Quality In
• See as Whole
Reference:
1. Poppendieck, Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit, Addison Wesley, 2003
What is Kanban:A systemic, lean approach that aligns capacity and work-items across all functions/roles within a software delivery team in order to create “flow”
On Deck DesignIn Prog Done
Test Done
DoneIn ProgCodeSpecifying
In Prog Done
Cycle Time
Essential elements of Kanban are:
Visualizing the flow of work (value stream)
Queues
Pull vs. Push
Limiting work in progress
Explicit Policies
Catalyst for Continuous Improvement
WIP SLAs
* Planning, Review, Retrospectives, Daily meetings not prescribed.
METRICS OF FLOW
Cycle Time – How long does it take to complete a unit of work
Throughput – How many units of work (stories) are completed in a day/week/month
WIP – How much work in progress do I have in the system
Little’s Law
Average Cycle Time = Average WIP
Average Throughput
Scrum v Kanban - Similarities
• Both are Lean and Agile (Kanban has more focus on Lean concepts)
• Both based on pull scheduling (Scrum via Sprint planning , Kanban via Continuous Flow)
• Both limit WIP (Scrum via Sprints , Kanban via 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 and Cycle)
Adapted from Henrik Kniberg
• Considerations• Scrum
• Team like/needs discipline of prescribed ceremonies and timeboxed delivery• Team is new to Agile and Scrum ceremonies instill a sense of discipline• Team is cross-functional• Team is coming from a traditional model• Delivering enhancements on a fixed schedule is a requirement
• Kanban• Support or other queue-based work• Team can release on their own schedule and wants to release as soon as work is
completed• Team can break work down into small batch sizes where each adds value and can
be released independently (if possible)• Team has several specialist roles• Team has responsibility for end-to-end process has tasks outside of software
development• Team wans a focus on Lean / Systems thinking and use lean metrics for
continuous improvement
• Either• Team wants to limit WIP• Team wants to continuously improve
Which One Should I Use ?