Gen AI in Business - Global Trends Report 2024.pdf
Scrumban (Lean-Agile Fusion) v1.1
1. “SCRUMBAN” –
A LEAN-AGILE FUSION
Michael O’Rourke
Product Manager. Agile & Lean Enthusiast.
LinkedIn
2. WHAT’S THE INTENT HERE?
Expose complaints about your products to determine
where improvements must be made
Review your current product development processes
Justify the necessity of injecting new “Lean” philosophies
into your work
Compare the finer points of Scrum & Kanban
Define what Scrumban is
Show opportunities where improvements can be made to
better quality, performance & meet user/buyer
expectations
2
3. WHAT ARE YOUR OPEN WOUNDS?
Is your software quality poor?
Are your releases continuously late?
Has the amount of hotfixes (or patches) increased?
Are you an enterprise disguised as a small business?
Are you a flat organization catering to an imperial
organization?
Do you serve many masters in different groups – groups
rarely agreeing or communicating with one another?
The problem is not you personally
The problem is not agile, either
3
4. PROCESSES YOU USE TODAY ARE NOT
SCALABLE & ADAPTABLE TO DEAL WITH
YOUR BUSINESS DYNAMICS
5. WHAT’S DISRUPTING YOUR DEVELOPMENT PROCESS?
Don’t have what’s needed to start work, but
forced to commit to it anyways
New stories constantly injected (force-
added) after committing to a Sprint
Constant task-switching that reduces
productivity
Unclear “Definition of Done” for many
backlog items
Team roles & responsibilities overlap –
causing extra work for everyone
Too many stakeholders with all the power
& none with their skin in the game
Impossible to schedule recurring demos
with all the stakeholders’ meeting conflicts
Indecisions about priorities encourage Dev
Teams to find work on their own
5
6. DEVELOPMENT PROCESSES YOU USE TODAY
Today, you use Scrum – a framework that derives from
the Agile software development methodology
- Scrum is more than just a process – it’s a value system
- It’s core component is the double-feedback loop – without it
you’re not Agile
kind of
Scrum works for you
- Early, constructive feedback to make early adjustments
- Frequent knowledge sharing & internal communication
improves our performance
- Teams inspect each iteration thoroughly & adapt quickly
- Continuous involvement of QA
- Able to mitigate risks & resolve issues easily & quickly
- Nearly instant patch releases for critical issues
- Heavy, up-front requirements were rarely necessary
6
7. WEAKNESSES OF SCRUM IN AN ENTERPRISE
Limited visibility of where the Team is in their
development cycle
Nearly impossible to scale-up with enterprises going
through organizational changes
Being in constant crunch modes encourages cutting
corners – leaving you with piles of technical debt
Scrum Master & Product Owner roles sometimes conflict
& overlap, making excessive work for both of them
Lacks flexibility for Teams during transitions – Scrum
demands for normalized Teams before starting work
“Pig & Chicken” lore encourages Dev Team’s to push out &
diminish Product Owners authority
Any slack in a Sprint can be filled with unauthorized work
You need processes that are flexible, predictable
& practical
7
8. SO, WHY NOT CHANGE HOW SCRUM WORKS?
That should be your exact Kanban-
Lean
intentions processes
You don’t need to scrap Scrum
Rather, you need to layer new Scrumban
Kanban philosophies on top of
your Scrum framework
This approach is called Scrum
SCRUMBAN Framework
8
9. WHAT’S KANBAN?
Pronounced kahn-bahn
Derives from Lean – a software development methodology
Unlike Lean, Kanban is not a framework or methodology – it’s
a process model similar to Scrum
Starts with 3 basic principles
1. Start with what we do now
2. Agree to pursue incremental, evolutionary change
3. Respect the current process, roles, responsibilities & titles
Draws on 5 core properties
1. Visualize your Work
2. Limit WIP (Work-in-Progress) We’re not pioneers. Pro-Lean
subcultures started to emerge within
3. Make Process Policies Explicit
product development communities back in
4. Manage Flow 2008. Since then, companies like Dell,
5. Improve Collaboratively FedEx, eBay, Telerik & SAP have
welcomed Lean thinking into their
software endeavors.
9
10. WHY SCRUMBAN IS A GOOD FIT FOR YOU?
Instills Lean principles
Reduces time devoted of planning & estimating
Promotes constant flow of work
Spawns a “continuous improvement” culture
Emphasizes on continual delivery while not
overburdening the development team
Encourages a “Think big, act small, fail fast, learn rapidly”
philosophy
Rally claims customers get to market 50% faster and are 25% more
productive when they employ Lean and Agile hybrid methods
10
11. DIFFERENCES BETWEEN SCRUM & KANBAN
Scrum Kanban
Time-boxed Iterations Cadences (Time-boxing is optional)
Commit to chunks of work each Iteration Commitment is optional
Velocity is the default metric for planning Lead Time is the metric for planning
Cross-Functional Teams Specialists (Cross-Functional Teams are optional)
Decompose work to fit in a sprint No sizing requirements
Burndown Charts Cumulative Flow Charts
WIP limited by Sprint WIP limited by State
Estimation prescribed Estimation optional
Can’t change Sprint in process Add whenever there is capacity
Sprint backlog owned by Team Kanban board shared by Multiple Teams
Scrum board reset between Sprints Kanban board is persistent
Prioritize backlog Prioritization is optional
Requires WFT (Well-Formed Teams) before starting a
Focuses on Flow rather than Team forming & norming
project
No tactic for enforcing explicit policies Allows explicit policies
Visibility of development input & output only – work is
Visibility of development input, work & output
black-boxed
Management is kept at bay Management is inclusive
11
12. BLENDS THE BEST OF BOTH WORLDS…
Scrum Kanban Scrumban
Time-boxed Iterations Cadences (Time-boxing is optional) Cadences (Time-boxing is optional)
Commit to chunks of work each Iteration Commitment is optional Commitment is optional
Velocity is the default metric for planning Lead Time is the metric for planning Lead Time is the metric for planning
Cross-Functional Teams Specialists (CFT’s are optional) Cross-Functional Teams
Decompose work to fit in a sprint No sizing requirements No sizing requirements
Burndown Charts Cumulative Flow Charts Cumulative Flow Charts
WIP limited by Sprint WIP limited by State WIP limited by State
Estimation prescribed Estimation optional Estimation prescribed
Can’t change Sprint in process Add whenever there is capacity Add whenever there is capacity
Sprint backlog owned by Team Kanban board shared by Multiple Teams Kanban board shared by Multiple Teams
Scrum board reset between Sprints Kanban board is persistent Kanban board is persistent
Prioritize backlog Prioritization is optional Prioritization is optional
Requires WFT (Well-Formed Teams) Focuses on Flow rather than Team Focuses on Flow rather than Team
before starting a project forming & norming forming & norming
No tactic for enforcing explicit policies Allows explicit policies Allows explicit policies
Visibility of development input & output Visibility of development input, work & Visibility of development input, work &
only – work is black-boxed output output
Management is kept at bay Management is inclusive Management is inclusive
12
13. WHAT CHANGES NEED TO BE MADE?
This goes… …and gets replaced with this
Time-boxed Iterations Cadences (Release)
Sprint Planning Dynamic Planning
Fine-grained Stories Coarse-grained Stories
Estimating Tasks Estimating Stories only
Velocity is replaced by Cycle Time
cycle time
13
13
14. SCRUMBAN: IN LAYMAN’S TERM…
Eliminates a constant iterative
cycle
Also eliminates need for a Sprint
backlog
Encourages a pull by demand
system, rather than a “push by
force” system
Promotes constant flow of work
MUST SEE!
Click here to watch a short, informative
video about applying Kanban to Scrum –
compliments of bti360
14
15. WITH A “LEAN” APPROACH, YOU WILL
FOCUS ON CONTINUOUS FLOW &
QUALITY, RATHER THAN TIME-BOXED
ITERATIONS