In Part 1, we provided a quick primer on Scrumban and discussed how the challenges a Scrum team faces can change during the lifecycle of a project. In this blog entry, we will look at the following five Scrum "smells" and see if you should consider a switch to Scrumban:
Story Points Per Sprint Graph Follow a Sawtooth Pattern
Look at the Story points you complete for each Sprint. Do you see an alternating up-and-down pattern (i.e. a sawtooth pattern)? This may be due to some Stories "almost" completing in one Sprint and being closed in the next (with full credit given in the Sprint that the Story was closed). This can happen if your Test engineers are sometimes idle at the beginning of the Sprint, but are scrambling towards the end to complete all the testing needed in that Sprint. Scrumban addresses this "smell" by having a continuous workflow model. For example, once a Test engineer finishes testing one Story, they pull a Story from a "Development Done" stage to a "Testing" stage and start working on it immediately. There are no gaps or pressures caused by an artificial time boundary. Do you really want your Test engineers to rush testing? I don't.
The Team Artificially Decomposes Stories During the Planning Phase in Order to Fit Them Into a Sprint
Artificial decomposition usually happens in this manner: During Grooming, the team has decomposed a Story into a minimal viable product. At Planning, the team points the Story at a number they can't traditionally complete in one Sprint. At this point one of two things usually 
happens: the Story is decomposed into two Stories (maybe one for Development and another for Test), or an Engineer is encouraged to start on the Story before the Sprint begins, thereby reducing the "risk" it won't be completed in one Sprint. Neither of these approaches is very good, and the first often creates an "unbalanced" team for a few Sprints. Scrumban is based on the concept that work will be completed when it is done. If one Story takes one week and another takes three weeks, this is easily supported in a continuous workflow model. Because you are always measuring Cycle and Lead Times, you can give a stakeholder a decent estimate as to when something will be completed.
Team Is Susceptible to Interrupts
Often within mature product teams, the same team has to create new features while supporting production issues. If the Sprints are relatively short, then enforcing a "don't interrupt the team" approach works fine (bugs are triaged and worked during the next Sprint). Some organizations have even created a sustainment team for production issues, but many organizations have moved away from this. If your Scrum team supports both new features and interrupt-driven production issues, then you may have created a separate "level-of-effort" Story to handle bugs. The person assigned to this Story will work to triage bugs, and if any are a high priority, then they will be worked on immediately. This can lead to a bug started in the middle of one Sprint and finished in the next. It can also lead to unbalanced demands on the team. Scrumban can address this by having any high-priority bugs picked up as the very next work item. To a large degree, this will lessen interruptions. Preferably, someone can finish a task, then grab the bug; however, if the bug is a show stopper, then someone can stop working on their current task, work on the bug, and pick it up again once the bug is completed. This happens very smoothly in Scrumban due to the lack of Sprint boundaries and the continuous flow model.
External Team Members Are Required by Organizational Standards or Processes
Everyone may be committed to your project, but some of them may be allocated to the team for only a certain percentage of their time. These people are often experts in something that is needed to support the team (e.g. user design, security, etc.). Problems can occur when their other commitments are not steady and when spikes across teams occur at the same time. All of a sudden tasks aren't completing at the end of a Sprint since the required resources can't commit during a narrow window of time. In Scrumban, the engineer on the task would visually indicate that the task is ready for the expert and start working on something else. The expert would pick up that task as soon as they could fit it in (e.g. once the spike is over). This keeps things flowing naturally on the team and it is visually clear where any bottlenecks are occurring during a daily Agile board review meeting.
Learn how to integrate security into Agile, download the whitepaper: Secure Agile Development
Technical Debt (or Similar) Stories Are Often "Pushed" to a Later Sprint
There are always certain types of Stories the team agrees need to be worked on (e.g. technical debt stories), but that may have less of an immediate impact than a new feature. These Stories are very susceptible to being moved to a later Sprint during the Planning phase. For example, the team points all the Stories during Planning and finds the total points are greater than what the team can complete in one Sprint. The Product Owner then recommends the technical debt Story be moved to the next Sprint. This happens a few times in a row until the technical debt Story is moved towards the back of the Backlog. Scrumban makes it easy to get buy-in for technical debt stories as putting one technical debt on the Ready state requires very little commitment. Additionally, large Stories are easy to add to a Ready state and can be started on almost immediately.
All of these five "smells" can be fixed within the Scrum process framework. For example, it is easy enough to come up with an approach to tackling technical debt stories within Scrum if the proper understanding and buy-in is applied to those stories. For teams that are interrupted frequently due to production issues, having shorter Sprints that are not interrupted can be effective (and if it is truly a showstopper, then raiding the Sprint is OK). However, if your team faces several of these "smells," and if they are persistent, then consider moving to another process framework, such as Scrumban, and see if that would better serve your team's needs.
More Posts From the Veracode Engineering Team
Get More Out of Your Agile SDLC - by Scott Gray, Principal Software Engineer
