Agile is on everyone’s minds today, as more and more organizations are eager to reap the benefits of rapid iterations using customer-centric approaches. Organizations tend to run to Scrum first because it is the most recognized agile framework. But is Scrum always the right answer for a team and a business? Heidi Araya discusses the types of scenarios and projects in which Scrum may not be a good fit. She shares other frameworks—including Kanban and Scrumban—as potential alternatives to consider to ensure teams and projects select the right fit and can deliver great software efficiently. Some considerations include organizational culture, size of teams, team composition, types of work, industry requirements, overall project size, and type of project. Go back to your organizations and confidently select the right frameworks for your current and future roles and projects—and explain to management why the framework chosen is appropriate.

1. AT8
Agile Techniques
11/17/2016 1:30:00 PM
Scrum, Kanban, or Scrumban: Which Is
Right for You?
Presented by:
Heidi Araya
BrightLogic
Brought to you by:
350 Corporate Way, Suite 400, Orange Park, FL 32073
888--‐268--‐8770 ·∙ 904--‐278--‐0524 - info@techwell.com - http://www.stareast.techwell.com/

2. Heidi Araya
BrightLogic
The founder of BrightLogic, an agile consulting company, Heidi Araya consults
worldwide, both virtually and on-site, with customers who need agile coaching,
transformation, and process improvement. Her specialty is assessing business
needs, and establishing the right methodology and process to achieve strategic
and team goals. Process improvement has been Heidi’s passion since the mid-
90s. With almost twenty years of experience in software, technology, project
management, and process improvement methodologies, Heidi has assisted
numerous companies and industries improve business processes, create better
teams, increase customer satisfaction—and save millions of dollars.

3. Scrum,
Kanban or
Scrumban
Which is right for
you?
BrightLogic Group
November 17, 2016
Agile Dev East
Orlando, FL

4. About me
Heidi
“there’s got to be a better way”
Araya
• Agile & Lean enthusiast
• Process improvement aficionado
• Systems thinker
2
Enabling happy
workplaces by making it
fun to work together to
deliver value for the
business.

5. What will you learn today?
• Basics of three frameworks
• Similarities & differences
between them
• How it’s possible to select the
best one for your particular
situation
3

6. Various ideas to select from
4

7. Change is terrifying
“People will use what they know
won't work if they don't have an
alternative that doesn’t
completely terrify them.”
(Al Shalloway, in a webinar entitled, “WhyYou
Should Never DoWaterfall, Often Be Agile and
Always Use Lean”)
5

8. Why does everyone want to do Scrum?
6

9. What’s right for you?
7
Tricks
NO

10. Why go Agile?
• Better products?
• Faster time to market?
• Faster ROI?
• Risk reduction?
• Predictability?
• Alignment?
• Attempt to change culture?
• Everyone’s doing it?
8

11. Consider the environment
• Culture & communication norms
• Reward systems
• Who will benefit
• Competency to lead, plan & execute change
• Degree to which company is willing to face
the truth
• Nature of demand for product development
• Challenging product (technical, cutting-edge,
research)
9

12. Scrum – who’s doing it all the way?
• Raise one hand if you are
doing Scrum
• Raise both hands if you are
following all Scrum practices
(there are no optional
practices in Scrum)
10
Credit: Martin Patten
Scrum is like your mother-in-law. It
points out all your faults.
– Ken Schwaber

13. Scrum main concepts
• Timebox work
• Self-organizing teams
• Cross-functional teams
• Close collaboration
• Inspect and adapt: fail fast
• Deliver potentially shippable
increments
11

14. Scrum – common challenges
• Teams fall into mini waterfalls
• No Product Owner available
• Urgent interruptions during sprint
• Cross-team dependencies
• Misunderstood rituals
(estimation, standup)
• Sprints are arbitrary and can create poor behaviors
• Difficult to transform large organization
12

15. Scrum – when it won’t work
• Team makeup inappropriate
• Team members not fully dedicated
• Limited & specialized skill sets
• Time-boxes inappropriate
• Direction changes daily
• How value delivered is measured (time vs.
results)
• Mismatch between Scrum roles &
company culture
13
If all you have is a hammer,
everything looks like a nail.

16. Scrum – when it won’t work
14
SALLY, YOUR OUTPUT
ISN’T CUTTING IT. YOU
ONLY PRODUCED 15
LINES OF CODE.
OH, ARE YOU
REFERRING TO THE 15
LINES OF CODE THAT
CURED CANCER?
YEAH, 15 LINES OF CODE
JUST ISN’T ENOUGH. WE
REALLY NEED MORE…

17. Scrum advantages
• Less superfluous specifications
• Less handovers
• Flexibility in roadmap planning
• Less risk due to short iterations
• Visible progress
• Commitment to a goal can raise
productivity
• Cross-functional teams provide great value
15

18. Scrum is best for…
• Team is new to agile
• Teams are stable
• Collocated – or same time zones
• Priorities don’t change on a daily basis
• Stakeholders are easily accessible
• Organizations with a steady pace of work
• Environments which encourage
collaboration
16
“The questions remain the same. It’s the
answers that keep changing.” – A. Einstein

19. Scrum
Does anyone have any
additional challenges or
advantages of Scrum that
I haven’t mentioned?
17
“If you have a culture of fear,
none of your fancy practices or
processes will help”
― Jürgen Appelo, Management 3.0

20. Group activity
STAND UP if you’re
doing Kanban
(at any level in the
organization)?
18
“Of course, speed is most useful if it is
in the correct direction”
― David J. Anderson, founder of Kanban for Software

21. Is Kanban Agile?
• Kanban comes from Lean
manufacturing*
• Michael Sahota – Kanban has “Agile
on the inside”
• Alan Shalloway - Kanban is a "2nd
Generation Agile Method”
• DavidAnderson – Kanban is "an
alternative path to agility”
19
*Lean aims to make the work simple
enough to understand, do, and
manage.

22. Kanban method
• A model for introducing change via incremental improvements
“a process to change the process”
• Major Goal: Improved performance through process improvements introduced
with minimal resistance
• Kanban matches amount of work in progress to the team's capacity
• Sometimes misunderstood to mean ONLY visual aid
• Board visualizes the service delivery workflow process, the work-in-progress &
the Kanban
20
“Kanban is about optimizing for continuous flow of customer recognized value. Know
what you are delivering to whom and why.” - Mike Burrows

23. Four Kanban principles *updated per David Anderson
1. Start with what you do now
2. Agree to pursue
evolutionary change
3. Respect the current
process, roles,
responsibilities & titles
4. Encourage acts of
leadership at all levels in
your organization*
21

24. Six Kanban general practices *updated per David Anderson
22
1. Visualize (the work,
workflow & risks)
2. LimitWIP
3. Manage flow
4. Make policies explicit
5. Implement feedback loops
6. Improve collaboratively, evolve experimentally (using
models & the scientific method)*

25. Kanban establishes an adaptive environment
23
• Foundation for an adaptive
capability in an organization
• Enables ability to cope with and
respond to complex
environments
• Processes emerge rather than
being designed

26. Kanban – requirements
• High degree of visibility into work
process
• Respect forWIP limits
• Commitment to pull-based flow
• Focus on quality
• Board reflects the work; it does not
direct people’s work
24

27. Kanban – when it won’t work
• Existing process needs to be revamped
• Team can’t discuss sources of dissatisfaction
openly
• Management won’t respect theWIP limits
• Unwillingness to define exit criteria to make
policies explicit
• Team can’t define the work/work types to be done
• Team doesn’t want to improve the current process
25

28. Kanban – advantages
• Use current process
• Visible progress in each stage
• Priorities can change anytime
• Continuous flow vs start-stop
• Fewer organizational, personnel and setup changes
• Acknowledges human psychological reactions to change
• Person does not have to be dedicated 100% to a sprint/team
• Lead times emerge vs team committing to work
26

29. Kanban is best for… any of these conditions
• Platform & component teams; support &
maintenance; or team too large for Scrum
• Team doesn’t respond well to big changes
• No prioritization is needed
• Want to add stories on the fly
• Don’t need iterations (sprints)
• Estimation isn’t necessary
• Want the ability to release anytime
• Continuous improvement is already emphasized
• Want to improve delivery flow
• Culture is skeptical of Agile; Culture won’t mesh with Scrum principles
27
SOMETIMES I GET
TIRED OF BEINGTHE
ONLY SMART PERSON
AROUND HERE!

30. Kanban
Does anyone have any
additional challenges or
advantages of Kanban that I
haven’t mentioned?
28
“If you are not continually improving, but you
are doing all of the other parts of the Kanban
method, you are missing the point. It’s a little
like the concept of “doing” Agile but not
being agile.”
- David J. Anderson

31. Kanban and Scrum … how are they similar?
29

32. Kanban vs. Scrum… how are they different?
Scrum Kanban
Predefined roles, cross-functional teams No prescribed roles; specialist roles allowed
Timebox Continuous delivery
Work pulled in batches Work pulled in single pieces
No change mid sprint Change at any time
Prioritize work ahead of time No pre-prioritization required
Commitment to specific amount of work Commitment is optional
Items - completed within a sprint Items - small & estimable, but no size prescribed
WIP limited indirectly WIP limited directly
Estimation a customary practice Estimation not needed
Cannot add items to ongoing iteration Can add new items whenever capacity is available
Sprint backlog owned by one team Kanban board may be shared by multiple teams/individuals
Board is reset Board is persistent
Metric -Velocity Metric - Lead/Cycle time
Burndown chart prescribed No particular diagram prescribed
Workflow not visible Workflow is visible to everyone
Adopt all at once Adopt at your own pace
Trust the Scrum Master Trust the team
30

33. Kanban – common scenarios
31
• Maintenance and research work where
estimation & time boxing adds overhead
with little value
• Teams are too large for Scrum and can’t
break them up
• People who are nervous about agile and
don’t see how it will work for them
• People with specialized skills not 100%
dedicated to teams

34. Why does Kanban work where Scrum will not?
32
• Manages pieces of a chaotic
environment well
• Specialization is often the only viable
route in organizations
• Designed to be adopted in an
incremental way with little
disruption, unlike Scrum
• Kanban trusts teams to improve the
process

35. FinalThoughts… Scrum vs. Kanban
Start with Scrum if…
• Your organization is really stuck and
needs a big change
• You have a good & committed leader
Start with Kanban if…
• Culture isn’t willing to accept mindset
shift
• You have a decent process in place and
want to improve it over time
33

36. Scrumban
STAND UP if you’re doing
Scrumban (however you
define it)
34
“Frameworks should be
extracted from a collection of
successful implementations,
not built on speculation.”
– Mary Poppendieck (cofounder of Lean
Software Development)

37. What is Scrumban? (as defined by the ‘fathers’ of Scrumban)
“The Scrumban method builds on …Scrum practices in order to introduce pull, flow,
standard work, throughput metrics, and continuous improvement to the Scrum
framework, while also reducing the overhead associated with planning batch
transfers.” – Corey Ladas, 2009
“Scrumban is the Kanban method applied to Scrum as the starting and
underlying process framework.” – Ajay Reddy, 2012
“Although Scrumban has evolved as a framework over the years, it has no definitive
guide or definition. In fact,… several ‘authoritative’ sources disagree about what
Scrumban actually represents.” – Ajay Reddy, 2012
35

38. Scrumban (*as defined byCorey Ladas & Ajay Reddy)
• Contains defined roles of Scrum (PO, SM)
• Same Scrum meetings can take place; frequency can vary
• Specialized teams & functions allowed
• Can break out work into as many columns as needed
• Board stays persistent
• WIP limits per stage are followed
• Tasks assigned by pull (at last possible moment)
• Focus on getting tasks to done
• Prioritization is optional; plan on demand
• Estimation is optional
• Can have one team taking work from different backlogs
36

39. Scrumban is good for…
• Scrum team grows with no easy way to split it
• Fast-paced & dynamic process such as startups
• Multiple team ownership
• Scrum team wants to move away from time boxes
• Teams want to tweak the process to include
more steps
• There are dependencies to external specialties
• Other teams depend on this team
• Several product owners exist
• Scrum team wants to improve their flow & lead times
37

40. How do I start doing Scrumban?
1. Start with what you do now - either
Scrum or Kanban
2. Add elements of either Scrum or Kanban
that you think would be useful, e.g.:
• Measuring lead/cycle time
• Observing WIP limits
• Adding or removing timeboxes
• Adding exit criteria
3. Inspect and adapt
38

41. 39
Frameworks as an evolution…
• Scrumban can be an
evolution to Scrum…
… or away from Scrum
• Kanban can be an
evolution away from
waterfall…
… or away from Scrum
39
By Ricardo - AllGizah Pyramids,CC BY-SA 2.0, https://commons. Liberato
wikimedia.org/w/index.php?curid=2258048

42. 40
… or simply advanced Scrum?
• Teams may love Scrum and decide to advance in the Scrum
space
• Hyperproductive Scrum
metrics
– Focus Factor
– AdoptedWork
– FoundWork
– TargetedValue Increase
– Accuracy of Commit
– Accuracy of estimation

43. Tying it up…
• Best framework depends on your project, team & goals
• Take principles & practices from various frameworks as needed
• As team matures, they may have ideas of their own
• Try other things aside from Scrum, Kanban & Scrumban 
41
“Failure at an organizational level seems to come from the
inability to customize processes and make them their own.
Trying to apply someone else’s template to your organization …
leaves out too many important details of the previous successes
and ignores your company’s specific situation.”
- Kent Beck, Extreme Programming founder

44. 42