Where Scrum Falls Short, Scrumban Comes To Rescue

#SridharPeddisetty #Agile #Scrum #Kanban #Scrumban #ScrumFails #ScrumDoesNotWork #ScrumPrinicples #ScrumbanPrinciples 

What is Scrum?

Scrum is an iterative and incremental lightweight Agile based software development methodology, which is based on following core principles:

• Scrum employs transparency, inspection and adaptation through its ceremonies (Daily Scrum, Sprint Planning, Sprint Review & Sprint Retrospection)
• Work is organized in time-boxed cycles (2-4 weeks) referred commonly as Sprints
• Product Owner defines the Sprint goals and shares during the Sprint Planning ceremony 
• Product Owner defines work goals through user stories and prioritizes them during the Sprint Planningceremony
• Scrum Team are cross functional and decides how many user stories it can work on in a Sprint during theSprint Planning ceremony 
• Scrum Team are self-organizing and estimates how much time each user story in the Sprint will take during the Sprint Planning ceremony 
• Team member with specialized skill(s) can decide how to do the work for each user story but overall accountability of delivery in the Sprint lies with Scrum Team
• There is no interruption for the Scrum Team during a Sprint and its the responsibility of Scrum Master to ensure that
• Scrum Team is answerable to the Product Owner for Sprint deliverables while Scrum Master plays the role of a Servant Leader
• Scrum Team measures its performance by tracking Velocity during the Sprint
• Scrum Master is responsible for removing impediments for the Scrum Team that could be shared during Sprint ceremonies or through osmotic communication

What is Scrumban?

Scrumban combines the core principles of Kanban with some of the core principles of Scrum. In my earlier post Kanban & DevOps - Forming a Perfect Alliance, I had shared the basics of Kanban, which includes:

• Visualize Work In Progress (WIP)
• Limit the WIP
• Maximize Productivity (by minimizing lead time)

Essentially in Scrumban we employ Kanban's ‘pull’ approach rather than Scrum’s ‘push’ approach while using theScrum principles with some modifications. So core principles of Scrumban translates to  

• Sprint – In a Sprint instead of limiting it as time–boxed, team ‘pulls’ prioritized ‘just in time’ (JIT) work items in the Sprint based on team's bandwidth. In other words, Sprint is ‘limiting the WIP’ instead of time-boxing the Sprint
• Sprint Planning - In the Sprint Planning, team plans for JIT work items. Since Sprint is not time-boxed, team does not necessarily spend time on doing estimations but rather focus on understanding the work item goals, dependencies and how to do the work
• Daily Scrum – Team continues with Daily Scrums answering basic 3 questions  

                 o    What did they do since last Daily Scrum? 

                 o    What is the plan to do till next Daily Scrum? 

                 o    What are current impediments (if any)? 

• Visualizing Work In Progress (WIP) - Team uses board to visualize JIT work items including the respective state of the work items and swim-lanes they belong to 
• Sprint Review – Team uses Sprint Review for showing demo of work items to the concerned stakeholders & 
• Sprint Retrospection – Team uses Sprint Retrospection for doing retrospection, providing an opportunity for continuous improvement. Ceremony can be used for identifying bottlenecks and opportunity for optimizing the work flows. In my earlier post 'Metrics For Maximizing Productivity In Kanban SDLC’, I had shared on how to maximize productivity in Kanban SDLC

Where Scrum Falls Short?

Scrum falls short when team spends too much time upfront in doing Sprint Planning and in the middle of the Sprint, there is a priority change for one or more User Stories. In some situations, an entire Sprint could be cancelled by the Product Owner or the Management for various reasons including budget constraints, change in priorities or the work items in Sprint are allocated to another project team. All this not only impacts team’s productivity but also at times the morale of the team. Another concern commonly heard in Scrum Retrospections is that the velocity is not helping do accurate estimations or the Sprint backlog is not achieving desired forecasting. Lastly, in my experience I have seen some teams following Scrum fixated on following the “process" rather than focusing on delivering value.    

How Scrumban Come To The Rescue?

Since Scrumban is based on the lean principle of focusing JIT work items, team remains committed to the WIP. Scrumban provides the flexibility of prioritizing and reprioritizing work items and since team is not doing any heavy lifting of upfront planning, they remain focused on delivering value faster. Scrumban also provides the flexibility to the team for switching gears to work on expedite work items which is not possible in Scrum especially when in the middle of a Sprint without causing some serious feathers to ruffle. Lastly, since Scrumban is based on Lean values, it focuses less on following the ‘how of the process’ and focuses more on delivering the value through continuous improvement. 

Summarizing

In summary, Scrumban is a lightweight SDLC process that combines Scrum to be more Lean & Flow oriented. In Scrumban, team achieves optimized productivity by remaining focused on JIT work items and faster cycle times. Team gets better at spending less time in doing deep dive up front estimations and instead uses more cycle-time based forecasting, which provides team with more time in actually delivering quality work item.

I will be sharing case studies, process improvements and best practices specific for Scrumban in my future posts. Meanwhile let us know if you have any questions or comments. For any questions, please reach out to me at sri_ped@yahoo.com 

Where Scrum Falls Short, Scrumban Comes To Rescue was originally posted under Prokarma Blog on Sep 12th 2015