Scrumban Demystified

SCRUMBAN DEMYSTIFIED
MORE THAN JUST SCRUM + KANBAN
Official Licensed Material Copyright Code Genesys, LLCtraining@codegenesys.com | @codegenesys

Section 1 of 8
Foundations

Agile Recap
Principles of Agile Behavior
 Business value focus
 Dynamic requirements management
 Direct, active communication
 Direct Business / IT collaboration
 Develop working increments
 Sustainable pace
 Simplicity and direct utility
 Continuous improvement
 Motivated, empowered teams
 Technical excellence
 Self-organizing teams
 Success is working solution
Characteristics of Agile Practice
 Balanced value/risk prioritization
 Incremental planning & development
 Low ceremony; high productivity
 Hierarchy of adaptive planning
 Rapid feedback cycles
 Regular rhythms
 Clear definitions of “done”
 Information radiators
 Multidisciplinary teams
 Peer development and review
 Collaborative, shared responsibilities
 Automation of build, integration & test
 Regular reflection and improvement
Agile is a combination of principles & practices
These principles & practices represent a significant body of knowledge
3
Designed for
responsiveness, quality,
innovation & scale

Lean Recap
Principles of Lean Behavior
 Relentlessly eliminate waste
• Muda – useless or superfluous
• Mura – irregular or inconsistent
• Muri – excessive or unreasonable
 Continuously amplify learning
• Kaizen – improvement or drive to excel
 Decide as late as possible
 Deliver as early as possible
 Empower the team, with support
 Build quality in, from the outset
 Optimize the whole, not just part
Characteristics of Lean Practice
 Balanced value/risk prioritization
 Continuous planning & development
 Low ceremony; high productivity
 Simple, focused, adaptive planning
 Rapid feedback cycles
 Workflow-driven rhythm
 Minimal work-in-progress
 Information radiators (kanban tokens)
 Teams structured to the work
 Peer development and review
 Collaborative, shared responsibilities
 Automation of build/integration & test
 Regular reflection & improvement
Introto Lean Designed for
responsiveness, quality,
regularity & consistency.
Agile & Lean principles & practices are complementary
4 Official Licensed Material Copyright Code Genesys, LLCtraining@codegenesys.com | @codegenesys

Kanban
”...Kanban (capital K) is the evolutionary change
method that utilizes a kanban (small k) pull system,
visualization, and other tools to catalyze the
introduction of Lean ideas into technology
development and IT operations”
David J. Anderson,
Kanban, 2010

6
The Inter-relationships Visualized

Section 2 of 8
Kanban Clarified

WIP Limits
Backlog Defined In-Progress Done Accepted
Blocked
Blocked
Limit = 12 Limit = 4 Limit = 3 Limit = ∞ Limit = ∞
1
4
3
2
A Visual Information Radiator
8
What Most People Associate with Kanban
Value Stream Pull

ajay@codegenesys.com @ajrdy Official Licensed Material Copyright David J. Anderson & Associates Inc. and Code Genesys, LLC
Dynamic - always changing
Cascading effects camouflage
causation
Amplification & dampening
effects make impact of actions
difficult to predict
Apply synthesis to understand
and manage the complexity
Weightier understandings are
required
It’s a Little More Involved
Systems Thinking…

ajay@codegenesys.com @ajrdy Official Licensed Material Copyright David J. Anderson & Associates Inc. and Code Genesys, LLC
… and Thinking Systems
Create adaptive capabilities
Connects those adaptive capabilities
to changes in your business
environment.
Example - Toyota’s Quality Circles
• Optional
• Collaborative
• Focused
• Empirical
• Common method

Defining & Visualizing Closed Systems:
Kanban Underneath the Surface
Inputs
• who generates work
demands?
• How does work reach
you?
• How much work is
demanded, and how
often does it arrive?
Outputs
• What is state of completed
work?
• Who is work delivered to?
• How much work is delivered
and how frequently?
Process
• When & where does responsibility for
work begin and end?
• What steps / phases does it pass through?
• Are phases the same for all work types?

100% resource utilization = 0% throughput
Henrik Kniberg
Max utilization, Slow flow Lower utilization, Faster flow
Limiting WIP
Utilization vs. Throughput

Lean Concepts
Waiting times double
between 80% to 90%
utilization and then
double again from 90%
to 95% utilization.
Source : Six Myths of Product Development
Harvard Business Review, May 2012
Donald Reinertsen & Stefan Tomke
Limiting WIP
Utilization & Wait Times

Source : Implementing Lean Software Development; Mary & Tom Poppendieck
Enabling Flow Efficiency

Kanban is a Complementary Framework
1. Supports and Improves Existing Processes
2. Enables More Reliable Forecasting / Predictability
3. Enhances Employee Involvement & Satisfaction
4. Integrates Methodical and Disciplined Techniques as
Part of an Active Management Framework
5. Improves Re-prioritization
6. Transparency of System Design & Operations
7. Fosters Emergence of “Higher Maturity” Teams

Section 3 of 8
Kanban Metrics

Core Measurements
Measure the Right Things. Give
them an Appropriate Weight
Measure with an Appropriate
Degree of Certainty & Precision
Make Sense of the Data -
Disciplined Collection and
Analysis
Kanban’s Bias on Measurements
Scrumban visualizes and leverages
Kanban’s additional metrics within
the Scrum context!

Cumulative Flow Diagram (CFD)
CFD shows the
quantities of work in
progress (WIP) at each
stage in the system.
CFD is a visual
representation of
Little’s Law.
Average Lead Time =
Average Work in
Progress / Average
Throughput

Lead Time Histogram

Throughput as an
Indicator of Continuous Improvement
Throughput represents the number of work items delivered in a given time
period.
-- used as an indicator of how well the organization is performing
-- demonstrates continuous improvement

Flow Efficiency as a
Measure of Potential Improvement
5-40%
• Calculated as touch time
against lead time.
• It indicates how much
room there is for
improvement by
eliminating waste without
changing engineering
methods.

Section 4 of 8
Kanban & Active Risk Management

• Kanban seeks to actively identify, manage and set
appropriate expectations around work / work types with
different risk characteristics.
• 3 areas upon which risk is commonly evaluated
• market-based
• work-based
• environment-based
• Cost of Delay functions are easily integrated into a Kanban
system’s visualizations & metrics
• Major distinction from Scrum framework
• embeds purposeful risk management as an added dimension
• visualization and active management facilitates local optimization (vs.
premature optimization such as commitments in form of Sprint Backlog)
Actively Managing Risk

Common Profiles
Urgent / Emergency Profile - highest risk and
most immediate impact to the business.
Typical policy is for all resources to
immediately stop other work & expedite these
items to completion.
Fixed Cost Profile - medium to high risk, with
immediate impact to business if completed
after required delivery date. Typically
associated with legal commitments &
regulatory requirements. Should be selected
for delivery over standard work when due
dates are looming.
Standard Cost Profile - medium risk with a
shallow and immediate impact. The typical
policy around such items are to process them
on a First-In-First-Out basis.
Common Risk Profiles

Common Profiles
Intangible / Investment Cost Profile - almost no
risk with a low to moderate impact on the
organization. Typically has no measurable cost
of delay in the near future, and is performed
as needed so the team may continue
developing with high quality and
speed. Examples of such work include
dealing with technical debt, emergent
architectural issues, and general improvement
efforts.
Common Risk Profiles (cont.)

Example of Risk Visualization
Enhances information upon which to make a pull decision
27

Section 5 of 8
Scrumban Demystified

Starting Context = Scrum
Source: Scrum Alliance

75% of organizations using Scrum will not succeed in
getting the benefits that they hope for from it.
“ “
-Ken Schwaber, co-creator of Scrum
Why Scrumban Matters
(one reason)

Look at What’s Happening…

Visualizing Scrumban

The Learning Landscape
• Work Items / Work Cards
(user stories)
• Work Size Estimate
(story points)
• Definition of Done
(acceptance criteria)
• Daily Standups
• Work Type
• Workflow
• Pull
• Ready / Buffer Columns
• Blockers
• Classes of Service
• Capacity Allocations
(explicit WIP limits proto-kanban)
Concepts Familiar to Scrum Teams
New Concepts

Scrumban can be adopted to help improve
understanding and management of these
practices:
• Product Definitions (MVP / MMF)
• Work Item Prioritization (less subjective
evaluations)
• Release Planning (more reliable forecasts)
• Iteration Planning
• Measuring & Managing Flow (new
capability)
• Story Points / Estimation (accurate
correlations with product delivery)
• …and more
Common Targets

Scrum Roles
Description / Purpose Common Challenges How Scrumban Helps
• Cross-functional and self-
organizing teams.
• Designed to optimize
flexibility, creativity and
productivity.
• Maximize feedback &
accelerate ROI by efficiently
delivering iterative Product
Increments.
• Team empowered to organize
and manage work.
• Collective responsibility
fostered by discouraging sub-
teams and specialization.
• Psychological barriers to
change.
• Operate on their own versus
having specific individuals
direct people and processes
(adapting to Scrum Master
role can be particularly
challenging)
• Building effective cross-
functional skillsets within a
development team takes time
and effort.
• Emphasize system
understanding and stability
ahead of change.
• Respect & retain current roles
while developing a shared
understanding of current work
process and policies.
• Work more effectively while
evolving at a comfortable
pace.
• Aid transition to a prescribed
Scrum destination or adapt
roles, ceremonies and
processes to a state that
works best for a given systems
at a given time.

Scrum Ceremonies
• 4 formal events for inspection
and adaption: Sprint Planning,
Daily Scrum, Sprint Review
and Sprint Retrospective.
• Each ceremony serves a
specific purpose and is
essential to Scrum.
• Typically involve degrees of
collaboration designed to
promote:
 mutual understanding
(transparency)
 individual buy-in
 shared commitment
toward a commonly
understood outcome
 a culture of continuous
improvement
• Many organizations modify or
omit ceremonies as a solution
to exposed problems and
dysfunctions (benefits Scrum
would otherwise deliver are
never realized).
• Less mature teams tend to
focus on the wrong issues and
unnecessarily lengthen time
investment.
• Seasoned Scrum Masters can
help teams learn to manage
ceremonies more effectively,
but individual capabilities can
vary significantly and the end
result is often hit or miss.
• Can replace function of
modified or omitted
ceremonies
 Teams can work more
effectively in “broken”
systems as they’re
enabled to evolve.
 Scrum-like frameworks
aren’t condemned to
under perform.
• Reduce or eliminate time
required to complete many
ceremonies by effectively
incorporating their functions
within daily work or other
mechanisms.

Product Backlog
• A dynamic, ordered list of
everything that might be
needed in the product.
 Product Owner is
responsible for the
content, availability
and prioritization.
• Maximizes transparency of
key information to promote a
shared understanding of work
and business objectives.
• Team is collectively
responsible for refining
backlog.
• Organizations often frustrate
purpose & function of P.O.
role by assigning multiple
individuals to serve.
• Subjective prioritization & risk
management techniques.
 Effectiveness depends
upon individual
capabilities.
 Inordinate focus on
templating language &
similar aids over value
& risk.
• Grouping mechanisms such as
theming and slotting are
invented with little business
awareness.
• Work demands from all
sources are visualized; can be
managed with greater
transparency.
• Scientifically based
mechanisms to identify and
measure risk are emphasized.
• Visualized Classes of Service
support JIT localized
prioritization (more informed
handling of work with
different value & risk).
• Visualization & measurement
of work flow through the
value stream helps overcome
inordinate focus on mechanics
(such as templating language).

Release Planning
• Planning in an Agile context
should be iterative, consistent
with self-organizing teams,
and support empirical process
control (meaning plans
emphasize insight over
direction or commitment).
• Agile Release Plans should be
dynamic, and increase in
accuracy as the results of each
Sprint are incorporated.
• Agile Release cycles should be
kept as short as possible
(definitely less than 1 year) to
assure “course corrections”
can be made as early as
possible.
• Planning and estimating in
largely depend upon a single
metric – velocity.
 Reliable forecasting
difficult to achieve as it
is subjective and
unique to each team.
 This fundamental
nature of velocity
makes estimating
difficult to scale.
• Though it’s possible to adjust
deadline, scope, resources
and quality for any given
project, only deadline and
scope tend to be effectively
controllable in most Scrum
contexts.
• Enhanced recognition and
management of risk factors,
additional metrics, and
techniques allowing for
probabilistic forecasting
(based on Little’s Law)
enhances the reliability of
forecasting and improves its
scalability across larger
enterprises.
• The integration of Options
Theory and similar models
into a Scrumban framework
affords more flexibility with
Release Planning.

Sprint Planning
• Time-boxed to a maximum of
4 hours (for a 1-month Sprint).
• Product Owner identifies the
business objective for the
Sprint and identifies Product
Backlog items that will
achieve this goal.
 Development Team
and P.O. agree upon a
Sprint Goal.
• Development Team forecasts
functionality to develop
during Sprint, and assesses
what it can accomplish based
on P.O.’s desires, teams
projected capacity, and team’s
past performance.
• Assumes business priorities
won’t change during Sprint.
• Less mature teams often
challenged to complete all
work within the time-box.
• Full scope of work can only be
discovered as work is done.
• Renegotiation of goals
 Pragmatically depends
on maturity of team.
 Rendered theoretical
because estimates are
viewed as promises.
• Risk of meeting business need
determined by ability to
achieve consensus.
• Additional metrics and
techniques
 Enable JIT mgmt. of
changing priorities
 Reduce time needed
to produce estimates
 Improves reliability of
forecasts
• Supports alternative
frameworks
 Continuous Flow can
eliminate Sprint
Planning altogether.
 SLAs can replace Sprint
commitment as main
trust mechanism.
• Risk of meeting business need
addressed through Lead Time
SLAs and Classes of Service.

Sprint Time-box
• Limited to 1 calendar month
to assure a routine inspect &
adapt cadence.
• Short enough duration that
market needs won’t change
between time work is started
and delivered.
• Protects team from scope
creep. Eliminates ad hoc work
requests that interfere with
productivity.
• Team only commits to
completing work it estimates
is realistic to achieve.
• Duration often established
based on organizational desire
for alignment, but actual
nature & complexity of work
can vary from team to team.
• Some environments are more
rapidly changing than others,
meaning market needs can
change during Sprint.
• Insulating team from work
requests is rarely pragmatic.
Emergency work is a part of
business and we need some
mechanics for managing it.
• Full scope of knowledge work
only discoverable as work is
performed.
• Discovering & understanding
the systems across which
work is performed is used to
set Sprint duration (or
transition out of time boxed
development altogether).
• Prioritization & commitment
to specific work not limited to
the start of a time-box.
• Visualization & Cost of Delay
metrics (CD3) reduce
subjectivity and allow for JIT
prioritization throughout
workflow.
• Visualization of different
Classes of Service improve
recognition and management
of different business needs.

Daily Stand-ups
• 15-minute time-boxed event
to synchronize activities and
plan next 24 hours of work.
• Optimizes the probability of
meeting the Sprint Goal.
• A key inspect and adapt
meeting to help eliminate the
need for other meetings,
improve communications,
promote quick decision-
making and improve team’s
overall knowledge.
• Turn into meaningless “status”
meetings rather than true
synchronization & planning
efforts.
• Impediments managed after
they manifest themselves.
• Probability of meeting the
Sprint Goal still subject to
inherent variability of work.
• Less likelihood of developing
disciplined approaches for
recognizing patterns with
impediments because
continuous improvement
efforts are managed outside
Scrum’s core framework.
• Kanban board as a “real-time”
information radiator shifts
focus away from status and
impediments to opportunities
for inspection and adaption.
• Greater focus on the work and
not the worker reduces need
to manage psychological
barriers.
• Visualization enables scaled
stand-ups across larger or
multiple teams (improving
shared understandings).
• Bias toward integrating
disciplined approaches (katas)
improves scaling and mobility
of team members.

Sprint Review
• 4-hour, time-boxed meeting
(for 1 month Sprints) to
inspect Product Increment.
• Inspect and provide feedback
on completed work plus
collaborate to identify ways to
optimize value. Revised
(reprioritized) Product Backlog
is produced defining probable
work items for the next Sprint.
• Opportunity for entire team
to improve knowledge of
business objectives and
suitability / quality of the
incremental product delivery.
• Often perceived as the
measure of performance and
accountability to stakeholders.
Ends up being misused to
protect reputations in low
trust environments rather
than improve delivery.
• Work is frequently optimized
prematurely in order to meet
the presentation demands
from stakeholders.
• Supplemental mechanisms for
building trust are more or
equally as effective as the
Sprint Review (making it less
likely for the Review to be
misused).
• Multiple Definitions of Done
across each value adding step
improves overall work quality
and reduces likelihood of
premature optimization
aimed at preserving
stakeholder trust.

Sprint Retrospective
• 3-hour, time-boxed meeting
that occurs after the Sprint
Review & before the next
Sprint Planning Meeting.
• A continuous improvement
process to counteract the
natural forces of entropy
(moving from order to chaos)
and sustaining higher levels of
agility and performance.
• Opportunity to inspect how
the last Sprint went in terms
of people, relationships,
process and tools.
 Identify potential
improvements to the
way team works
 Create a plan for
implementing them.
• Sprint mechanism does not
naturally encourage or
provide for capacity to be
allocated toward ongoing
improvement efforts.
• Recognized opportunities to
improve tend to be subjective
or based on anecdotal
evidence rather than
empirical analysis.
• Visualization framework eases
management of striking
balance between delivering
work and executing against
improvement efforts.
• Greater emphasis on the
analysis of empirical data (and
providing more such data to
measure) makes the
process more effective and
more scalable.
• Disciplined, scientific
approaches to problem-
solving, risk management and
(katas) create more adaptive
“Thinking Systems.”

Section 6 of 8
GetScrumban Game
Official Licensed Material Copyright CodeGenesys, LLCtraining@codegenesys.com | @codegenesys

Scrumban Systems are Queuing Systems
(layered within a Scrum Context)

Games Help Us Learn
• Humans think & learn
immeasurably better as part of a
network than on their own.
• Games are a terrain in which to set
our minds free and wander around.
• GetScrumban is an interactive
game where players collaboratively
learn and improve their
understanding of key concepts.
1. Evolutions in Visualizing &
Managing Workflow
2. Evolutions in Recognizing
and Managing Risk
3. Evolutions in Maximizing
Business Value through
Service-Orientation

Starts in a typical Scrum context –
• An existing Scrum Board
• A Sprint Planning session where
teams estimate stories and
select their Sprint backlog.
As players compete they –
• confront a variety of common
scenarios to manage
• experience how Scrumban
improves shared understanding
s and enables teams to shape
and control demands.
Game Play

Game play encourages new
ways of thinking by:
• Calling on players to use
both old and new metrics to
inform their decisions
• deciding what changes in
their way of working makes
the most sense.
Game play reflects how
Scrumban works in real life.
• every context is different.
• continuous discovery and
experimentation is an
effective path to better
outcomes.
New Ways of Thinking

Players can compare and
contrast performance metrics
across teams and games to:
• Learn how to recognize
visible patterns within
performance data and
understand their
significance
• Proactively address issues
before they manifest
themselves as impediments
Mastering Skills

The Get Scrumban Game
http://GetScrumban.com

Section 7 of 8
Shaping Demand with Scrumban

• Most process improvement efforts focus on improving
capabilities.
• Shaping and influencing demand is another way to help bring
systems in balance
• We do this by setting expectations through
probabilistic forecasting
• Starting point with Kanban / Scrumban is:
• Release Planning / Sprint Planning with Little’s Law
Shaping Demand
Establishing Meaningful Expectations

Project Planning Process
• Concept is Developed
• Project Parameters are Established
• Minimum Viable Product / Minimum
Marketable Features are Defined
• Features are Prioritized
• Estimates of Required Time and Resources
are Established
Official Licensed Material Copyright CodeGenesys, LLCtraining@codegenesys.com

The Moving Targets
The amount of work requested.
The amount of time needed.
The amount of resources allocated.
The level of quality delivered.

The Headaches
Estimating Skills – some individuals /
teams are better than others at
estimating.
Work Item Variability – the development
process has too many variables that
influence “lead time.” Outliers are
inevitable.
Non-uniform Metrics – the most
performance metrics are rarely apples to
apples comparisons.
Politics – estimates are invariably
perceived as commitments.

Scrum Systems – Estimation & Velocity
• Estimation of hours or
story points is subjective
and imprecise
• Velocity measurements
are only relative and not
comparable across
multiple teams
• Velocity is essentially a
“throughput “-based
measure.

Kanban Systems – Flow Based
Queuing system design plus granular tracking of work types and
workflow enables probabilistic forecasting.
Example of visualizing a single
workflow through which all
work types flow. Enables
forecasting based upon
objective measurements vs.
subjective sizing.
Example of visualizing
multiple workflows that
relate to specific classes of
service (each of which may
have different rates of flow).
This system typically allows
for more precise forecasting.

Lead Time Focus
Traditional Labels – typically
measured as the amount of time
required to deliver a work item.
-- measured from the date of
commitment through delivery
into the first infinite queue
Alternative Labels – shifts
focus to realization of
business value.
-- “flow time” + “delivery
time” is the cycle relevant to
our forecasting process.

Applying Little’s law
Departure rate approximately equals
arrival rate (λ).
No work items get lost and none
remain in the system indefinitely.
Little’s Law holds for queuing
systems where:
training@codegenesys.com Official Licensed Material Copyright CodeGenesys, LLC
Can be applied at both iteration and release
levels...

The Basic Math
Use with care – there are many variables that
influence reliability of any forecast.
Best Use is to attain improved understandings
& to influence expectations vs. making explicit
commitments.

But Wait… What About the Z-curve?
Little’s Law can only be
reliably applied to work
performed during the 2nd
leg of the project /
release z-curve…

Accounting for
Uncertainty
Natural ebb & flow (associated with the
1st & 3rd legs of the z-curve)
Dark Matter (work expansion that comes
from a better understanding of the work
being undertaken)
Failure Load (defects & technical debt, for
example)
When calculating Project (or Release) lead time,
we need to account for uncertainty in terms of:
Source: Dimitar Bakardzhiev

Managing the
Uncertainty
• 1st & 3rd Legs of Z-curve
• Dark Matter
• Failure Load
• Other Risks?
Calculate and Manage Against a Project
Buffer Accounting for:
Have Team Focus on Median Lead Times
Project Buffer =
Z-curve coefficient
x
(1 + ave. failure load + ave. dark matter)
x
(# of stories / ave. throughput)

What About Sprint Planning?
The techniques applied in Release Planning can also be employed
at the Sprint Planning level:
• Little's Law provides an additional check and balance on the
correlation between velocity and actual throughput.
• Teams that actively manage risk through embedded Risk
Management techniques (such as Cost of Delay calculations
and / or class of service mechanisms) are enabled to improve
their story selection & prioritization capabilities, improving the
likelihood of meeting their Sprint commitment.

Why Risk is Relevant
• Higher Risk Means Greater Variability in Lead Times
• greater variability means less predictability
• Factors that Influence Risk
• having to interact with other systems to deliver completed work
• having to work with new systems or technologies
• having to learn about new new business domains
• and many more...
• Quantifying, Tracking & Visualizing Risk
• improves shared understandings of project health
• enables early discovery and intervention

The Result – Better Decisions
Which of these projects is more likely to be completed on time?

Back to Sprint Planning
Improving the Likelihood of Meeting Your Sprint Commitment
• 70 User Stories remain in the Product Backlog.
• Risk has been quantified on each on a crude scale:
• High Risk Items: 20 User Stories
• Medium Risk Items: 36 User Stories
• Low Risk Items: 14 User Stories
Historical Team Data
• Average Lead Time for All Stories: .9 weeks
• Average Lead Time for High Risk Stories: 1.6 weeks
• Average Lead Time for Low Risk Stories: .4 weeks
# stories = duration x (ave. WIP / ave. lead time)
Proposed Sprint Backlog

Where You Can Go
Modeling & Simulations
• Modeling is used when greater precision is required, or when we need to
isolate and measure the impact of specific risk factors in a more granular
fashion.
• Modeling reality through repetitive simulations produces the rough equivalent of
actual performance data
• Past performance data (or its equivalent) improves our understanding of the
probability of various outcomes that would otherwise remain elusive.
• Elevated levels of uncertainty and risk
means greater difficulty developing
accurate forecasts.
• Poor forecasting erodes trust and sense
of predictability with non-technical
leadership.
• Trust & predictability are essential to
sustained agility and high-performance.

Section 8 of 8
Retrospective

The most important things cannot be measured“
“
-Deming, W. Edwards. Out of the Crisis.

A GREAT WAY TO START!
Learn More :: Scrumban Kickstart
Start using Scrumban
in Less Than a Day!
WHEN: Monthly - Fourth Wednesday
8:00 AM – 1:30PM
WHERE: Code Genesys
15 Main Street
Hopkinton, MA
Just $249
(pre-registration required)
Private Programs Available
Contact Code Genesys for details
WHY SCRUMBAN?
 Simple & Easy – Starts With What
You’re Already Doing and Makes
Those Practices More Effective
 Improves Focus & Flexibility
 Adds Ways to Identify & Reduce
Wasted Work / Wasted Time
 More Reliable Forecasting &
Planning Capabilities
 Increased Efficiency
 Greater Sustainability
What you walk away with:
 Mastery of Core Principles & Practices
 Analysis of Sources of Demand (where
work is coming from) & Dissatisfaction
(what business needs aren’t being met)
 Value Stream Mapping of Current Process
 Initial Kanban Board Design
 3 Month Gold Level Subscription to
ScrumDo.com plus Follow-up Mentoring

Advanced Training Opportunities
Kanban Foundations (2 Days)
Kanban at Scale (2 Days)
Advanced Practitioners
Private Training
Customized to Your Needs / Delivered on-site
More Details at:
http://codegenesys.com/events
Contact us:
training@codegenesys.com

Scrumban Demystified

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Scrumban Demystified

Similar a Scrumban Demystified (20)

Último

Último (20)

Scrumban Demystified

Notas del editor