I have a problem with Scrum – although the problem isn’t really the Scrum methodology itself, but rather some of the people who (attempt) to adopt it.
I’d liken it to Harley Davidson motorcycles or perhaps Gibson guitars – both great products, especially if they’re acquired by people who know what they’re buying and how to use them. Unfortunately, what tends to happen is that they’re also purchased by people from the outside – usually in their first foray into the sector, without any understanding of what they actually need to make full use of their purchase. For a motorcycle, where and how you ride should normally be an important factor in the type of motorcycle you purchase. Likewise, things like target musical genres and any preferred style of play will dictate what type of guitar you will want to buy (if you regularly play songs in different tunings, you may regret having that Floyd Rose tremolo on your guitar). There are obviously a huge number of other factors to consider, but I’ll avoid digressing further for now. My point is, if you don’t completely understand what you need, you’re likely to go in the wrong direction.
Going with the flow?
So, how does that relate to Scrum? Well, when you’re looking at changing the way you work, you’ll probably have a number of things to consider: what size are your teams and how many do you have, how complex are the products you’re developing, what constraints are you working with (budget, time, organisational structure) and so on. In life, there are very few solutions where one size truly fits all – but a great many tend to make this assumption with Agile – especially in relation to Scrum. More often than not – Scrum is adopted without any form of analysis about what it provides and where it fits. Ask people to list just three pros and cons about what they’ve chosen and many will struggle. Ask them why they went with Scrum and they’ll often tell you that it’s the most popular – so it must be great, right?
Now, the vast majority of people who bought their new Harley or an awesome Gibson SG will find themselves very happy with what they’ve got – but not all… While a bad purchase may have some resale value, chances are that making a bad decision about your approach to delivering software will not see a good a return. At worst, you might have failed to deliver a viable product, drove away your best talent and spent all your money. Game over.
Measure, evaluate, adjust.
Ok, so maybe that’s extreme and in most cases you’ll probably do alright. However, I’d expect a good team to do more than blindly following a prescribed way of working and instead, actually look at what pain-points they have and where their greatest inefficiencies lay. You should have some understanding of where you could improve and what benefits addressing area that could bring. You can do that at any point – before you transition to Agile, after, during – or even if you never chose to adopt an Agile methodology.
Even if Scrum (or any other particular methodology) is a good fit, it’s probably not going to be perfect. If you want confidence that you’re doing the best you can, you should have some understanding of at least some alternative approaches. There’s actually a large number of agile ways of working – some sharing ideas, some diverging. If you adopt a continuous improvement mindset, you should be regularly evaluating what you do and why you do it. Don’t just follow the masses.
Now, you may be aware that Harley Davidson isn’t the worlds only motorcycle manufacturer. If they were “the best”, why do other brands still exist and why do people continue to buy them? Depending on what you measure, who “the best” is can vary quite dramatically. Scrum benefits from being relatively easy to understand and limited in scope (divorcing itself from engineering practices). That might make it a good choice for starting to learn about Agile – but does it continue to add as much value in the different stages of your journey?
A bad workman blames his tools.
One constant I’ve observed is that who you have on your team is much more crucial than the processes, tools or methodologies at hand. A team of motivated, talented people can achieve a huge amount very quickly.
For me, a good methodology provides the least amount of interference required to ensure that all the effort expended is in the right direction (and also provides a clear measure of progress). I’d assert that the level of “interference” should probably take into account the level of skills in your team, their previous track record and how well understood the project’s goals are. Done badly, Scrum can come across as micro-managing and almost condescending. It’s an old adage, but if you’ve hired good people – get out of their way! Let them demonstrate how they’d approach things given a free rein.
If you’ve got bad people, sorry but Scrum isn’t going to magically fix that. Nothing is. However, be careful who you consider to be the “bad” people. Quite often, the developers or delivery team get left with the blame for any project going awry, simply because they’re at the end of the chain. Sometimes it genuinely is poor tooling (yes, you can blame your tools) or a number of other upstream issues that really derailed the project long beforehand. It wasn’t a bad workman. As often as not, the core issue actually relates to poor planning, unclear direction or bad management decisions completely outside of their control. Too many companies shoot the messenger without realising that is what they’re doing.
Nowadays, it’s very tempting to adopt fashionable trends – especially when they promise so much (transformation to an efficient, ultra productive nirvana). Scrum is one of many tools at your disposal, just try to ensure you have a clear understanding about the problems that it’s potentially going to solve for you. Agile is very much in vogue at the moment – use it wisely, don’t just be someone with “all the gear”…
Setchu - Agile at Scale 