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

Metrics For Maximizing Productivity In Kanban SDLC

#SridharPeddisetty #Agile #Kanban #SDLC #Productivity #BestPractices #Metrics #EngagementManagement

“Measure what is measurable and make measurable what is not so” –Galileo

In my earlier post Kanban & DevOps - Forming a Perfect Alliance, I had shared the basics of Kanban. In this post, we will look at the metrics for identifying bottlenecks while using Kanban as the software development lifecycle (SDLC) methodology. With experience and motivation to improve quality comes working out the right metrics, which measures areas of continuous improvements. In my earlier post 10 Ground Rules on the Right Metrics for Your Business, I had shared some rules on selecting the right metrics that is tied to the desired business outcomes. As summarized in the blog post, data collection, analysis & management is most often cost and labour intensive, so its important to always weigh in against the benefit derived from the selected metric.

One important principle of Kanban is to maximize productivity by optimizing the flow of work and managing work in progress (WIP) by removing bottlenecks. Before selecting the metrics, we need to assess what metrics is needed and then plan on using the processes and tools, which will provide the data for quantification in a shape and form that will allow us to measure. Presently Organizations are competing to provide faster value to their customers, which is effectively done by sizing and decomposing the requirements into minimal marketable features (MMF).

In Kanban, we can have have the Kanban board visualizing the WIP for states and swim-lanes. States could represent the following phases a user story (feature) or defect goes through the development lifecycle

• Product Backlog (Requirements)
• Defined (Analyzed) 
• In Progress (Development & Testing)
• Completed
• Accepted  

while the swim-lanes could represent WIP for 

• Expedite (Priority) user stories or
• Defects (Severity 1/2) or
• Different functional groups such as
  • Architecture,
  • UI/UX Designers,
  • Business Analysts / System Analysts, 
  • Development 
  • Operations
  • DevOps
  • QA
  • Technical Writers
  • others  

In some cases, Kanban board can represent one swim-lane for both expedite and non-expedite user stories or defects while just visualizing states.

Below is a sample ‘Cumulative Mean Lag Time’ metrics, which is measuring the time spent by a user story (USxxxx) or Defect (DExxx) both expedite or non-expedite in each of the following state

• Requested,
• Defined,
• In Progress,
• Peer Review,
• In QA, 
• In UAT and
• On Hold

From the metrics we can derive following information including identifying bottlenecks and areas of continuous improvement

• Expedite user stories (US7000 & US7674) are obviously prioritized by the team as the time spent in each state was short comparatively, thus faster overall cycle time. Information can be derived from the chart if the expedite items are distracting the team in effecting their WIP items by looking at the mean lag time an item is spending in each of ‘Defined’ or ‘In Progress’ or ‘On Hold’ states.  
• User story ‘US7626’ (second chart) was analyzed, developed, peer reviewed and tested in a short span (~2 calendar days) but spent ~9 calendar days in user acceptance test (UAT) state. One reason for this could be that the user story was not in the priority list for the stakeholders to be released or the priority lowered after the work started. As an opportunity for continuous improvement, we can look at the option where there is an opportunity to reprioritize the user story before the team starts the work.  
• User story ‘US7322’ (first chart) spent a lot of time (~25 calendar days) in ‘Requested’ state and then some time in ‘On Hold’ state (~12 calendar days).  As an opportunity for continuous improvement, we can work with stakeholders to make sure that we are getting the right requirements and acceptance criteria for the user story along with prioritization. The total cycle time for this user story could be also more because of the complexity and/or dependencies on the other integration deliverables. In either case, metrics shows the bottlenecks and provides an opportunity to optimize work flow for future such occurrences. 
• Above metrics also gives the overall cycle time for different sized user stories and defects, which helps in predicting for future work and ability to give a better commitment for the stakeholders 

Summary

User Story is like a fish, the longer its sits on the shelf, the less desirable it becomes. Use relevant metrics to measure lead time in each of the Kanban columns (states), which helps to identify the bottlenecks and to improve planning and forecasting. 

I will be sharing case studies, process improvements and best practices specific for Kanban 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 

Metrics For Maximizing Productivity In Kanban SDLC was originally posted under Prokarma Blog on Sep 8th 2015