Scrum Frustrations

Our move to Kanban from traditional Scrum centered around the following frustrations to which I have answered:

Customer/Product Owner get frustrated that they have to wait for a sprint to end before new work will be considered

With Kanban you can dispense with sprints/timeboxes. As soon as an item is complete you pull in the next priority item from the queue. Therefore the wait time to inject a new request is minimal.

Planning meeting attendance is poor as the customer doesn’t have the time to spend 2 hours every 2 weeks planning.

You dispense with the ceremony of sprint planning, you plan only when you need to (when the queued upstream work is running short) and only for as long as you need to get enough new items in the queue to keep things flowing.

Sprint planning would last for a couple of hours, everyone would leave the session happy to what they have committed to. Within a couple of days an urgent support issue or 2 would come into the team and our planning was thrown, we would try and adjust then someone would be pulled onto another project for a hotfix or someone would go sick, our plans soon became meaningless and this would frustrate the team.

We now plan when you need to (Just in time planning) based on the need for more items to fill a queue that is drying up. You dont try to predict the future!

If an item is complete why should I wait until the end of the sprint to start using it?

You release as soon as something of value to the customer is ready. Release planning becomes smaller, easier and less risky.

Releasing a feature within a 2 week sprint sometimes isn’t possible, so we start having to arbitrarily trying to break that feature up or carry it over into the next sprint which kind of defeats the goal of releasing per sprint

Kanban imposes no such limitation. We strive to have small enough items to be released little and often, however if in order to receive value from a feature it requires the sum of all of its parts to be released then so be it!

We find ourselves trying to arbitrarily set a sprint goal or not setting one at all! The goal becomes how many points can you do in this sprint compared to the last?

The new goal becomes “When we agree to take on a work request, we intend to deliver it within n days”

Our Scrum Task board is full of cards, its hard to see what is going on and it tends to get ignored during our standups.

The Kanban board becomes cleaner and clearer due to setting limits on each state. The team begins to use it more as it actively reflects the teams progress. It becomes a true information radiator.

Blockers get raised but dont get removed.

Blockers are discussed in the standups as they are attached to the items on the board, upstream team members start discussing them as they are stopping them from pulling work into their queues.

The customer doesn’t get point estimation

In our team estimates are made in Small, Medium and Large. Based on data we can equate these to the real time it takes to accept an item in the queue and get it live. This is really what the customer wants “if you start this tomorrow when can I expect to see it on my PC?” This is really easy to track, items going in have a start date, items going out have an end date written on the card. You can then easily track and subsequently predict average cycle times for Small, Medium and Large items. You start talking a language again that the customer understands.

Our tester keeps getting overloaded

Kanban limits the items that you work on at once. If the developers produce more work than a QA can test then everyone jumps in on the testing to free the production line.

A Scrum team is necessarily limited to fewer than 10 people, because its practices do not scale well beyond that size. A project team that requires a larger team will be split into sub teams that fit the Scrum limits.

A Kanban pull system is more focused on work and workflow than the first generation Agile processes. Nowhere does this difference in emphasis show more clearly than in the daily standup meeting. Kanban projects have no trouble in scaling up to 40 people or more.

Many Agile methodologies such as Scrum assume you are starting a new project; sprint 0, calibration sprints, hardening sprints etc
What if your project is already underway or if you are incrementally enhancing an existing product set?

Using Kanban you can bootstrap an existing project. Kanban does not require you to be starting from zero or working on a traditional greenfield project.

Its important to note that I am not jumping on the Scrum bashing bandwagon with this post!