In this article, part of my series explaining better ROI from software development, I’ll be giving some advice when considering Scrum. If you are not familiar with Scrum, please refer to my primer here.
A brief note on intended audience; this article is not intended as a training guide for Scrum. There are a lot of resources out there. Much better than I could every produce. This is much more an introduction from a Return On Investment perspective aimed at business leaders.
Probably one of the first questions for anyone that has looked it Scrum.
In general there isn’t one particular part of Scrum which is more important than any others.
I have however seen individual parts have a greater benefit than others in different organisations – but that is generally environment specific. Rarely do two environments have exactly the same problems and thus the same solutions.
You may find that the Product Owner role produces massive benefit if you traditionally have many “chiefs” – you development team are more focused, can concentrate on the priorities – thus generally get more done because they aren’t being inefficient handling competing priorities.
You may find that your wider business becomes so much more engaged with the software development through the regular short sprints. Rather than seeing nothing out of IT for months or even years in some cases, they are seeing usable software. It helps to produce a regular cadence - a heartbeat for your organisation – a constant source of change & innovation.
You may find that having an ordered backlog gives your business more opportunity to plan for change – to organise around those upcoming changes.
You may find that your teams are getting better and better, more productive and efficient through regular Retrospectives – the whole organisation is benefiting and becoming a happy better place.
And there are countless variations from where your organisation may see the most benefit – and this could be leading you into thinking that you should be cherry-picking the parts that will solve your more obvious problems.
I’d always advocate taking anything and trying it to improve; and maybe that wouldn’t be a bad start if you want to ease into Scrum.
To never implement it fully however is a massive missed opportunity.
I’ve read books & articles, listened to podcasts & watched a good few conference talks and the advice is always the same – implement the whole thing.
It has been designed and evolved by experts. They have taken many years of learning, research and experience to give us the Scrum guide.
And while sometimes some of the benefits may not be instantly obvious within your environment, you wouldn’t be the first to find unexpected results. That part of the advice that you saw no benefit in – could very well be the one that shines a light on a problem you never realised that you had.
The Scrum Guide gives you the opportunity to stand on the shoulders of giants – why wouldn’t you?
No, of course not.
Scrum is no guarantee that you will produce good software. There is no guarantee that your software project won’t fail.
Plenty of Scrum projects do fail or simply don’t live us to organisations expectations.
Research however does show that projects have a much greater chance of success if delivered under Scrum compared to the more traditional Waterfall method.
And this follows a fair level of common sense. In Scrum, the principals follow the Agile guidelines, thus quick feedback and thus an ability to resolve problems before they go too far wrong. With more traditional Waterfall methods, you can be years & millions of pounds invested before your realise that it’s been headed in the wrong direction.
But I’m not going to pretend that Scrum will make your organisation a land of Unicorns and Rainbows. If anything it can sometimes feel like it throws up nothing but problems.
And if it is, then it’s working.
Scrum is good at find problems (or impediments to be more correct). Many that you didn’t know you had. And all this time those problems have been slowing down your organisation. They have been making you less effective and productive. They have been costing you money.
The Scrum process is very good at shining a light on those things that are hindering better productivity.
As I’ve said Scrum isn’t perfect.
And there is a fairly large body of work that criticises its approach, highlights its shortfalls and generally doesn’t think it’s a good idea.
It would be foolhardy of me here to try and address that. While I’d certainly expect an amount of that negativity to be “fashionable” due to Scrums success and a certain amount to be because an organisation has failed to implement it correctly, I don’t think it would be fair to dismiss others opinions so lightly.
If we go back to the Agile Manifest, it is very clear that we are always learning. There may well be a better method that Scrum. Certainly some methods fit some teams, organisations and situations better than Scrum.
But, I would still advise you start with Scrum if you are starting down the Agile journey.
There are many paths to the top of the mountain.
There is nothing stopping you taking a different path than Scrum. And even if you do take Scrum, you may find that you deviate from it in the future.
I would advise you to ensuring you are doing so with eyes (and mind) wide open.
You (and your development team) should research alternatives – look at the pros and cons of each.
If nothing else, the act of looking will likely greatly improve how you are going about your Software Development.
In the next article, I want to look at some of the benefits I perceive in individual parts of Scrum.