Don't slip on Scrum, understand it first

My top 5 things to avoid when it comes to Scrum

“Agile, agile! We need to become agile, then instantly everything will get better!”

It started years ago with the buzzword “agile” spreading like a virus on board level. Agile methodologies as cure-all wonder drugs in the IT. The most popular one? Scrum.

Actually, I did not want to explain Scrum at this point, just because the terms “agile” and “Scrum” are now considered so obvious and used so normally (and one assumes that everyone knows agile methodologies and scrum like the multiplication tables from one to ten). And yet I experienced several times that my colleagues were not familiar with Scrum, not even with the basics of it (which, to be clear, is absolutely legitimate).

So, what is Scrum? Scrum is a framework, a methodology on how to succeed in a project (ideally a product development) as a team. Although Scrum is originally rooted in the software development, it can be used in other areas, too. The ground rules consist of four types of regularly occurring meetings, three core roles and three products created during the process (“artifacts”). The Scrum promises? High quality, faster and visible results, increased productivity, transparency, motivated employees, complexity becomes more manageable, … … oh, and world peace of course!

Yes, Scrum can work out well. As an IT Project Manager I already got the chance to use Scrum in an ideal environment: a new software product had to be developed in a team of 17 members. Why are these optimal conditions? First of all, it is a project – which, by definition, is a one-time undertaking to achieve a specific aim, with limited resources. My team had a project, an aim that had to be achieved. The time was limited, and so were the resources. (And don’t worry, I split this too-big-for-proper-Scrum team into groups and used Scrum of Scrums…).

Although I had been trained extensively in Scrum and also had gained practical Scrum experience, I continually took care to acquire more Scrum know how to better understand its rules and, above all, their meaning. When you understand the enormous importance of a good sprint retrospective, you would never think of leaving it out. Phrases like ?retros do not lead directly to lines of code, here we can save time and costs!” trigger my facepalm reflex.

But nevertheless, I always tried to look at my project and its circumstances individually and to not blindly follow every recommendation mentioned in books and on the internet. Of course, you can estimate with planning poker – but is this useful in your project and with your specific team constellation? In my opinion, this is always a key project management success factor: individual examination of circumstances and resources.

In the past few years I gained experience in Scrum in a wide variety of companies, and I wanted to share some banana peels that managers regularly throw themselves in their way with the result that they slip on them:

Banana peel no 1: using Scrum in unsuitable environments

In my opinion the most dangerous banana peel. Not every environment is equally suitable for Scrum. Above all, Scrum is so successful because it leads to a high level of team motivation, which in turn is the result of experienced responsibility and meaningfulness as well as recognition of the work performance. In order to lead a team well, one should become aware of these factors - and consider in advance whether these factors can be achieved in the respective environment. For example, when a product has to be developed, the meaningfulness is clearly visible, and that is in every sprint in which a part of the product is being developed.

Banana peel no 2: leaving out Scrum essentials

It is fatal to leave out elements like the retrospective due to potential (time =) cost savings. Especially the basic elements of scrum all have their right to exist and will lead you to the scrum promises. You can only use Scrum successfully if you understand the effects of the respective elements and apply the methodology as a unified system.

Banana peel no 3: not sticking to important rules

A perfect example, done by almost all Scrum newcomers: The given structure of the daily Scrums is not respected ("What have I done since the last one, what do I plan to do until the next one, what are my obstacles?"). For example, if the obstacles are already discussed within the daily Scrum (and not just shown and discussed later), it can go beyond the time frame and prevent other, unaffected team members from working on. Not sticking to the (important) rules has consequences. Please do not wonder why Scrum is not successful in your team then.

Banana peel no 4: not training your people

If the team does not know the rules, it is not able to play by the rules! It is as simple as that. It applies to board games as well as to Scrum. As a project manager you should make sure that everyone knows Scrum. If there is no budget for elaborate training, then you should at least hold a short presentation, at best with a brief handout. And do not forget new members joining the already ongoing project. Be empathetic! Try to understand other people’s position and level of experience. Just make sure everyone knows how to play.

Banana peel no 5: giving up too early

The first, perhaps even the second and third, sprint generally does not run smoothly. Do not give up! Experience shows that it gets better over time, e.g. the sprint plannings become more fluent, the role allocation more natural and the collaboration better. Practice makes perfect.

Scrum worked great in my project. Of all the positive qualities that I have noticed, I especially noticed increased quality, continuous team and product improvement and a high level of motivation. But I am convinced that Scrum is not the best process model for every project, let alone a miracle cure.

It is not easy to choose a suitable process model (and yes, besides Scrum, there are others!). It is not easy to establish new methods in companies either. But you can lean on best practices and maybe avoid some banana peels. And above all: understand Scrum and its elements before you plan to use it.

*****

All views expressed are my own and do not represent the opinions of any entity with which I have been, am now, or will be affiliated. And any action you take upon the information provided is strictly at your own risk.

*****