Are you using Scrum? And do you feel that it's not providing the benefit, or any benefit, that it's supposed to?
Maybe Scrum wasn't your choice, maybe it was forced on you by your organisation. But you can't escape that feeling that little niggle scratching away at you that Scrum isn't working for you, the team or the company.
So how do you know when to use Kanban over Scrum? I think this is a great question so let's chat about it.
Now have you heard of the Dead Horse Theory?
It goes something like this, When you discover that you're riding a dead horse the best strategy is to dismount.’ Pretty sound logic eh.
But in business this rarely happens, we never seem to get off our dead horse. Instead we try and come up with a range of more 'advanced' tactics such as;
Buying a bigger whip
Changing riders
Appointing a committee to study the horse
Lowering standards to include dead horses
Providing additional training to improve the horse's performance
Or my personal favourite, it always worked before so why change.
The list of things we try is endless other than actually getting off the dead horse and onto one that is actually alive.
Now I'm sure you've come across this scenario before, it's obvious to you, but everyone else seems oblivious to the blatantly obvious solution.
Okay a dead horse might be a more visual clue to a problem than we actually get in the real world, so how do we tell if Scrum has become our dead horse and it's time to switch to Kanban?
Well, you first have to be aware that Scrum is not the holy grail and that it's very often not the best framework for you and secondly you have to look for the signs
I'm going to walk you through the 14 biggest tell tale signs that I've seen over the years that Scrum is not working and if you've got more than a few of these then you need to seriously consider a switch to Kanban.
1. Product Owners simply gather requirements
Okay so first up is when product owners are simply gathering requirements rather than trying to solve problems.
Let me explain.
The clue is in the name, product owner, they own the product. The PO should have a full and deep understanding of the product be close to the customer and understand their needs, know the market the competition, and have a vision of where to take the product. They should be solving customer problems and needs.
Now when they simply gather requirements from key stakeholders and fill the backlog up with what's essentially a wish list just to keep people happy this is a sign that Scrum is not the right framework for you.
2. How Product Owners manage the backlog
The number two sign is how Product Owners manage the backlog which can reveal a lot about an organisation’s agility.
Now does your product backlog have any of these;
It's massive and has hundreds if not thousands of items on it stretching back a year or two
Anything is allowed to go onto the backlog, it's pretty much a dumping ground because no one ever wants to say no
Nothing is ever deleted from the backlog, once it's on there it stays there forever because no one wants to have the difficult conversations that can lead to conflict
The items on the backlog are really a set of requirements instead of problems that need solving.
Now if this sounds familiar it's another sign that Scrum is most likely the wrong framework for you.
3. The focus is on output not outcomes
Number three is that there's a clear sign, that the focus, the pressure is on output, get all those stories done, more is better!
Rather than focusing on the outcome for the customer, you're basically a feature factory. You don't concentrate on problem solving yet another sign that Scrum is the wrong framework for you.
4. Your roadmap is a list of things wanted
Right number four, how about your roadmap, now does it simply list what you're going to do over a time period rather than focusing on what to achieve. It's basically a list of things that stakeholders want, yes it's their wish list, rather than things you want to achieve for your product or service that answers problems that customers have that would actually improve their experience.
5. Team composition
How about the makeup of the team? Do you have a developer, a lead developer, a business analyst, a tester, a test lead? This is such a common one.
There is a reason that the members on the Scrum team are called developers and nothing else
The reason is, if you have all of these roles then what happens is that you first have to wait for the BA to write the story, then maybe the test lead adds some additional acceptance criteria, then the developer develops and hands it over to the tester to test and maybe the BA will want a final look as well. This is waterfall, yes really.
Everyone on the team needs to be able to write stories develop and test them otherwise you're going to be sitting around waiting for each other, waterfall! And what about team size? How many people are in it? If it's over nine this is another bad sign, you're more of a small department than a close-knit team. Is everyone permanently assigned to the team or do you find that you have to share people with other teams or projects.
If you're in this scenario you need to make changes but if you can't then Scrum is not going to be working for you, switch to Kanban.
6. Customer access
You know that you're supposed to be working with the customers, the client, in order to develop and problem solve with them, but they are conspicuous by their absence.
You only ever get to deal with middlemen or middlewomen, proxies, who can never actually answer your questions and even then they have to run off to find time with yet another proxy to try and answer your queries.
The customer is central to solving a problem, without their direct involvement and input you're just guessing at what they may or may not want.
7. Sprint Goal
And in at number seven is when a Scrum team doesn't use a Sprint and Product Goal. You've tried but the work you're doing just doesn't lend itself to them.
You struggle to see a clear Product Goal in the backlog of work that you have and because of that it means the creation of a Sprint Goal just isn't possible.
I won’t go into any more detail here except to say that if you can't use a proper single Sprint Goal it's extremely likely that Scrum is the wrong framework for you.
8. Daily Scrum
Number eight, is your Daily Scrum simply a status update? You still use the dreaded three questions, you're just there waiting for your turn to speak but for most of it it's just a waste of your time.
The Scrum Master rigidly facilitates it and often waits to start until some senior figure joins or asks you to repeat what you've already said when that senior person joins.
And you never talk about progress towards a Sprint Goal because there isn't one.
9. Sprint Planning
Sprint Planning feels really forced, there's no Product Goal so you can't create a Sprint Goal that has any meaning.
You're discussing multiple unrelated items with multiple product owners and it takes forever, it feels very painful for little benefit.
10. Sprints
Okay your focus is on Sprints because, well, you're doing Scrum after all. But you never actually deliver any real value and it all feels a bit artificial and forced because the type of work you're doing isn't appropriate.
It feels more like a tick box exercise.
You've tried changing the cadence of Sprints from two to three and maybe even four weeks in an effort to actually deliver some real value but it never really pans out.
11. Sprint Review
What is your Sprint Review like? Is it yet another status update where you demo something.
Do your stakeholders ever turn up?
Do you have multiple different stakeholders because you working on a lot of different products?
Do you have to juggle your Sprint Review to accommodate them because they don't want to waste their time listening to the other products you've been working on.
Is the Sprint Review just used as a sign off exercise?
These are all signs that Scrum is not the right framework for you.
12. Retrospective
How about that Retrospective? Is it just used to have a moan about people who aren't even in the Retro?
Is it just yet another tick box exercise to say that you've had it? But nothing ever comes from the Retrospective it's just feels like another waste of your time.
You never actually see any incremental or continuous improvement, everything just seems to stay the same and you always end up talking about the same thing.
13. The Scrum Master
Is the Scrum Master basically the team's assistant?
Do they basically just do admin like setting up meetings, facilitating by making sure everyone speaks, that's not how you facilitate by the way!
Do they chase people up, gather status updates for management and hound people to move Jira tickets around the board, and then do it themselves when no one else does it. This is not what the Scrum Master should be doing, it's yet another sign of Scrum decay.
14. The work is mainly bug fixes and support tickets
The work you're doing, is it mainly support tickets and bug fixes with the occasional small Improvement? You never seem to be working on solving a customer problem, something that would provide real value or competitive advantage
It sometimes feels like you're working a call centre or help line blindly reacting to whoever has the loudest voice or seniority. This is another sign that Scrum is the wrong framework.
So there we have it.
Does any of this resonate with you? How many of these signs can you spot in your workplace?
If you've got a few of them present my strong suggestion is that it's time for a change as what you're currently doing isn't working.
Have a good hard look at Kanban it will almost certainly be a better option for you rather than persisting with Scrum that isn't designed for the work you're doing and the scenario you're in.
Comments