SlideShare a Scribd company logo
“SCRUMBAN” –
          A LEAN-AGILE FUSION




Michael O’Rourke
Product Manager. Agile & Lean Enthusiast.
      LinkedIn
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
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
PROCESSES YOU USE TODAY ARE NOT
SCALABLE & ADAPTABLE TO DEAL WITH
     YOUR BUSINESS DYNAMICS
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
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
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
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
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
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
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
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
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
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
WITH A “LEAN” APPROACH, YOU WILL
  FOCUS ON CONTINUOUS FLOW &
QUALITY, RATHER THAN TIME-BOXED
            ITERATIONS

More Related Content

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