Scrumban (Lean-Agile Fusion) v1.1

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 INTENTHERE?  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 YOUROPEN 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 USETODAY ARE NOT SCALABLE & ADAPTABLE TO DEAL WITH YOUR BUSINESS DYNAMICS
• 5.
  WHAT’S DISRUPTING YOURDEVELOPMENT 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 YOUUSE 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 SCRUMIN 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 NOTCHANGE 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?  Pronouncedkahn-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 ISA 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 BESTOF 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 NEEDTO 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’STERM…  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