Scrum: is the bullet really silver?

Scrum, being one of the most well-known lightweight agile process frameworks, is used a lot nowadays. But are we using it right? One might argue that an adaptable framework suggests no „wrong” uses – you’d simply tune it so that it suits your needs just perfectly. Although that might be the case in theory, but looking at how real-world Scrum projects cope with different situations, one might come to a conclusion that it isn’t as straightforward as it seems...

The framework itself is rather simple though, which is always emphasized as one of its core advantages. On the other hand, each and every Scrum training course that I’ve come across mentions somewhere very close to the beginning that Scrum is by no means a silver bullet. Okay, that might just mean that the authors are relieving themselves of any responsibility for how the framework is further used, but what exactly should we keep in mind in order to avoid shooting ourselves in a leg with this bullet – silver or not?

My experience shows that most of the misuses of the Scrum framework are very much obvious, when you really think about those. However, it seems that in this ongoing agile software development hype everyone just to hurries get going – with a hope that all the little glitches could be gotten rid of later. After all, we are in a flexible and agile environment, correct? Even so, it seems that there’s a point in thinking about possible pitfalls just a minute before you jump – especially if that doesn’t require a hell lot of analysis and effort.

So here are (in no particular order) some of the most frequently seen peculiarities in applying Scrum that you should probably try to avoid:

• Scrum in support/maintenance. The idea seems wonderful in the beginning: Scrum is flexible, it facilitates communication very well, we get decent estimates and a good structure to our process, despite of constant change of priorities... should be a perfect fit! Well, it isn’t. If you are planning to do a lot of maintenance work as a part of your project – same here, don’t do Scrum. The reason is that in this type of work the change is just too frequent! New incidents come in, priorities instantly change, and all that is happening on a daily basis. Scrum, on the other hand, is good at embracing a bit slower change – e.g. once every couple of weeks (or whatever your sprint length is), but given that you can protect your sprint scope from too many alterations. Scrum is very good at facilitating a shift from scope changes on quarterly or annual basis to adjustments on monthly or weekly basis, but in the support/maintenance scenario one should favour some kind of Kanban-like approach, perhaps.
• Scrum in a distinctively non-agile environment. Imagine a classic, very much “waterfally” organization, and its first Scrum project. How many chances of succeeding does that lone project have? Probably, not too many, and here’s why: none of the projects operate in a vacuum, all of those do integrate with the performing organization, partners and clients, all sorts of environmental factors. And if those surrounding factors are “configured” in such a way that a classic waterfall project is expected – it’s going to be hard for a Scrum team to operate in such conditions; for example, your external stakeholders would require reports and procedures that do not really fit in the Scrum framework. Sure, some of the contradicting process requirements might get handled one way or the other, “hacking” the Scrum framework along the way. But then, depending on the balance between external pressure and internal drive to implement agile methodology, the project will either gradually drift away from those same practices that yield the benefits of Scrum, or it will start conflicting with the external forces – at least some of which could have the power of shutting the rogue project down completely. So even though Scrum as such is of course best described as a “grassroots movement”, but for the success of the project it is best to assure senior management support: the organization should either be ready to make an exception for the project operating on a new paradigm (unlikely), or be ready to start adapting to the new approaches of delivering project results (a more complex of an endeavour, but the right thing to do).
• Scrum without a product owner. Somehow it seems less important to have a capable product owner than to setup a functional Scrum team – perhaps, it’s the case because PO is often viewed as some sort of an external force. Although that is true to some extent, one should never forget that the PO is a key success factor for any Scrum team. Not only should a PO be in place, but he/she should also have the authority to make important scope decisions – such as prioritization and bringing items in and out of product backlog. A typical mistake here is to appoint an analyst as a PO: an analyst might have more than adequate knowledge and understanding of the scope of the project, thus becoming an important asset to the team, but lacking the authority to make scoping decision an analyst PO would seriously impede Scrum team’s effective work. Another mistake is to pick a manager PO; yes, the authority is surely there, but what about deep knowledge of the scope, ability to answer team’s questions, availability for regular meetings and discussions? As managers often multitask heavily, it becomes close to impossible to ensure PO availability to the extent that the Scrum team needs it. So the ideal PO should be someone in between – with both knowledge and authority, available and willing to dive in the details; sure, it is very hard to find one – but inability to do so should probably question the choice of the methodology and process…
• Scrum as a part-time job. In many organizations employees might be working on a number of projects or initiatives in parallel, which is perfectly fine, however for the organization to be able to fully harvest the benefits of Scrum, it would make sense to assemble a stable team, fully dedicated to the Scrum project. Otherwise not only does capacity planning become more complicated, but it also becomes harder to actually be flexible along the way: schedule incompatibilities and the loss of focus make it increasingly tricky to establish and maintain a high-performing project team.
• Scrum of specialists. Often (especially in all sorts of integration projects) the team consists of highly specialized individuals, e.g. each person might be knowledgeable and skilled in one particular system that is within the scope of the project, but be completely ignorant about the rest. And that is fine – after all, that one system could be a universe of its own, mastering which on an expert level would take decades, and that makes team members’ desire to focus very understandable from the personal and professional standpoint. The Scrum team without true collective ownership of the scope of work would inevitably suffer in terms of flexibility and ability to adapt to changes – thus, again, deteriorating the benefits that the performing organization is willing to get by using Scrum in the first place.

Please note that I’m not saying that either of these factors is an absolute show stopper for using Scrum as the basis for your delivery methodology. Most certainly it is possible to work around any of these factors, and drive the project to success in any situation – but even if not, the team may still be functional and deliver some result, it’s just that neither the team itself, nor the performing organization will be able to enjoy the benefits of using Scrum framework. So be sure to sit down and think about the effort of adaptation in light of potentially reduced benefits – is it still worth going for it? And remember that Scrum and any other agile software development framework is only a tool, not nearly a goal in itself or the end of the road!

Need help with your Scrum project? Don’t hesitate to contact us with any questions or comments!