Things to consider when you want to change from Scrum to Kanban

Scrum or Kanban?

A common problem with agile teams is whether they should choose Scrum or Kanban as their primary methodology. Scrum is the usual starting point for most teams and the current market forerunner when it comes to selecting your agile weapon of choice. According to the 13th State of  Agile report 54% or teams surveyed claim they are using Scrum, with a further 10% claiming they do a Scrum/ XP hybrid. Kanban trails behind at 5% with Scrum-ban hybrid adding a further 8%

"Scrum doesn't work for us!" I often hear teams saying that scrum doesn't work for them. When I ask "why?" I usually hear the following:

We can't finish anything in a 2 week sprintThere are too many meetingsOur list of priorities keeps changingWe can't plan for 2 weeks. Our product owner keeps changing his/her mind
They often feel like Kanban is a silver bullet because:

It doesn't ask you to finish anything in 2 weeksIt doesn't impose any meetingsIt allows for chang…

Why you need WIP limits

Why is this crazy person telling me to limit my WIP? As an agile coach I often come across situations where I need to encourage teams to reduce the amount of work they have in progress. Even though it sounds and feels counter intuitive to do less work, the fact is your team will get more DONE by doing fewer things at the same time.

Activity != Progress
In our scrum teams we naturally tend towards keeping everybody busy. Developers working on development tasks, testers working on testing tasks. History has skewed our mental model of what people should do at work so that we feel like we should always be busy, always processing work. 
This is a good model for the mass production of widgets or the processing of mountains of paperwork BUT a bad model for the production of complex, functional, high quality software.
We use user stories to represent units of complex, functional, high quality software and in scrum the game is to finish a number of these units every sprint. This goal is often…

The "right" way to do stand ups

In my last post about daily stand up meetings dated(2011!!) I mentioned the standard format these typically take:

What did you do yesterday?What do you plan to do today?Do you have any blockers or impedimentsWe are all familiar with the approach. However, I often see teams losing focus of their progression against sprint goals due to executing the stand up poorly. 
If you find that going "round table" for individual updates is not providing any clarity on the progress of stories then it might be time for a change. Take this example: Yesterday, I had some meetings. I caught up with my emails and i had a dentist appointment in the afternoonToday I will catch up with Jane & Mike about Project DilbertNo blockersThe format is correct BUT the content was of little or no value. Why? Because the update was not pertaining to any of the user stories in the sprint and the progress being made towards its completion.
My previous post states that we should "focus on progress". A…

Agile is a team game

Agile software development is a team sport. I see so many issues when working with software teams that I have also come across in a sports team context. Teams are collections of people and to get a collection of individuals motivated and organised to achieve a common goal is not easy. I am convinced there is much we can learn from  the sporting arena to help us perform better as software teams. One example is the concept of Individual efficiency vs group efficiency.
Individual v team efficiency
A lot of what is important for the success of sports teams is also valuable for software teams. We create teams with a view to the Team achieving more together than the individuals would on their own or because the task/ deadline before us is unachievable without extra man power. 
Example: Amazing footballers like Lionel Messi, Cristiano Ronaldo, Diego Maradona could not  achieve anything on their own, they need to operate within a team structure to achieve any great success

Often organisations are…

Slice the peach

When should you split a user story? Think "when would you slice a fruit?"

A banana is big but manageable you'll probably eat it whole. You might want to slice it in certain circumstances.A peach could get messy so i'd rather slice itA kiwi is small but its hairy, i'm definitely slicing that!Deciding when to slice a user story is not always easy. Often its difficult to apply hard rules. Its usually a balance of size and complexity.
In the above examples, a banana represents a big story that isn't complex, should size alone determine whether to split it? The kiwi represents a story that is small but highly complex, we know its hairy, we know we shouldn't bite straight into it but how to slice it is not obvious either? peel first? slice first?

The peach represents the story I see most often. It represents uncertainty. Once you bite into a peach you discover if it is hard, soft, juicy, extremely juicy! If you slice it up first then you know exactly what you'…

Moving beyond tasks

One of the most common agile anti-patterns I witness is a compulsion towards breaking user stories into tasks.
Tasks take focus away from stories The problem with tasks is that they take the focus away from user stories. Teams that focus on completing tasks risk losing sight of the real value which lies in the stories. They are often unable to see the wood for the trees.

How often have you seen sprints that are? •             On day 9 of 10, but <30% of story points are complete •             On day 5 of 10, but <10% of story points are complete •             On day 9 of 10, with 90% of tasks complete, but still <30% of story points complete
I firmly believe this is a by-product of too much focus on tasks and not enough focus on stories. Tasks themselves add little or no value on their own. I often see tasks such as “Manual QA”, “Code Review”, “Write test cases”, “Database work”, “Front end work”, “Back end work”. People often argue to me that the task breakdown ensures the…

A short story about fish