If Scrum "isn't working" could we try Kanban?

If your team is currently struggling in their Scrum practice, you may be ready to give up or try something else.  Kanban is becoming quite popular and I'm recently a Kanban convert so I can understand the allure especially having seen it work so fantastically for teams.  However, as a coach, it's my responsibility to find out the root cause of the team's problems with Scrum first.  Sometimes it's a simple change that can get them back on track and well worth the cost savings of another training expense.

Here are some questions to ask when scrum "isn't working":

• Are the timeboxes too short? or too long?
• Is the backlog volatile? (many priority changes during a sprint or changes in stories planned)
• Are there impediments consistently through every sprint that delay the work of the team that are either not resolved or outside the team's control?
• Is team size larger than 9 people?
• Is planning and forecasting of work being done and communicating?
• How are the team's stakeholders reacting to the scrum practices?
• Is management supportive of the scrum team and their practice?

There aren't right or wrong answers to the questions above, but they do give a good picture of where the pain points are with the team and their stakeholders so that you can take the next step which is to begin trying new techniques or refreshing old ones to get the team back on track.

So when do I recommend Kanban for a team?  It depends. Don't you love that answer?!  It happens to be very true regardless of how flippant it may sound.  These are the cases where I've seen Kanban "fit" better for a few teams I've coached.

1. Team A had been practicing scrum for years and very poorly.  They had varied sprint lenghts, team members that would be borrowed by another team for an entire sprint, non-existent Product Owner and never did estimation or forecasting for future sprints.  There was such a bad taste in everyone's mouth for scrum that we decided it would be best to just try something new with less prescription and more adaptivity and a newfound energy to make it work with a strong agile coach.
2. Team B had never done anything but Waterfall or organized chaos working with different team.  They were an operations team that had several stakeholders across the company so their manager was essentially operating as a pseudo-Product Owner/Intake manager.  Kanban was chosen since the work they received was a steady flow of changes deployed as soon as they were completed.  Kanban works really well for maintenance and operations project teams since the work is relatively small and steady for those teams. 
3. Team C had been practicing scrum for over a year and they consistently met only 50-65% of their sprint commitments.  After repeatedly trying to get the team to accept less into their sprint plan (4 week sprints), reduce their sprint length to 2 weeks and getting their team members cross trained, I decided to show them how to implement Kanban flow and WIP Limits into their sprints; the ScrumBan approach.  We created more "states" on their sprint board from "Not Started, In Progress, Done" to "Ready Queue, Dev In progress, Dev Done, Test In Progress, Test Done, Demo and Done".  Then we updated the WIP limit for each state. These two small changes would allow them to see how work progress through each stage, limited how much they could do and also raised awareness across the team where work was not moving.

Some important things to remember with Kanban is to be diligent about keeping the ready queue current and populated for the team so they can keep moving through the backlog, and honoring the WIP limits and adjusting them as needed when you first start out so you can find that sweet spot.  Equally important is metrics.  Too many teams forget about this or use it just as a status report but don't take the time or know how to really analyze the metrics so they can explain the cycle time for outliers, make improvements or adjustments on the WIP to smooth out the flow and reduce the bottlenecks and watch the CFD (Cumulative Flow Diagram) to see trends so they can highlight success areas and recreate those situations to have more in the future.

Kanban Q & A with VersionOne references

With so many teams attempting to try out Kanban for the first time, I receive tons of questions.Here are a few of the questions I've received and the answers I gave at the time.  Keep in mind that as my knowledge of Kanban grows and changes, so do my answers so keep in mind these were from earlier this summer.

QUESTION:

1) what Story Points scale have you found useful with your teams?

• we are considering using 1,2,3,5,8 with "8" representing the largest size of work (basically high unknowns, probably "XL") but wondering if this provides a broad enough range of buckets
• also interested to know if teams have found that stories larger than perhaps the first 3 buckets, need to be decomposed further before going onto the board

ANSWER:

The numbers a team uses for story points doesn't really matter since they mean something unique to each team and should not be compared across teams. Just pick a set the team agrees to represent sizes relative to other stories. A "5" for one team does not mean the same story for another team should be a "5" and the choice of the numbering should be made by the team not management.

As teams estimates become more stable, they will see more clustering of cycle time metrics. This is true whether they are done by hand or through VersionOne. Teams should just annotate their metrics where significant changes are observed in the metrics to offer explanation and give themselves a documented memory of changes they made and the impact those changes made to their flow of work through metrics. 

We discussed a few of these scenarios at the last Agile Project Leads meeting and we'll be doing another session on it again at the next one. 

Oh and we NEVER change estimates for completed work. It's considered "waste", in agile, since we consider those instances where we estimated incorrectly a learning opportunity and a case where annotating our metrics will show WHEN we began changing the way we estimate and what impact it made to our flow, and by annotating changes we can see how long we tried something before we made another change. This can be especially helpful when teams realize they aren't making progress because they didn't give the "change" enough time to work before trying something else. Making changes too often, too frequent or just too many can be disruptive enough to keep flow from stabilizing which prevents the team from becoming predictable. 

QUESTION: 

• If these stories are left open until next week what does that do to our burn down and other metric reporting in Version One?
• Should we move the stories to the next sprint or put that them back on the back log?
  
• Can a team continue to work on stories and tasks after a sprint is closed during the grooming week? 

ANSWER:

• Move all stories that will not be completed by Friday/tomorrow to the next sprint
• Close the current sprint tomorrow – this will also track the REAL velocity of what was actually completed from the original committed plan
• Then next week while most of the team should be scheduled for quarterly grooming sessions all week, others not involved may get a jump start on the next sprint's stories.Remember that on Monday the 11th when the team does Sprint Planning, they will need to RESIZE the stories that were not completed this week and moved to Sprint 3.1 so that the size represents the size of the remaining work only.  This will also give a better picture of velocity at the end of sprint 3.1.