How Scrum is abused
Anmol Tuteja
Product Leader | User Engagement and Growth | (Martech, Customer experience, Digital News, Digital Entertainment, Retail Marketing, e-Commerce, e-Learning)
Being Agile is a buzz word in the software industry. As more and more companies are adopting it, it is becoming important to get it right so that the wrong practices don’t become an industry norm as it usually happens. A common framework in Agile is Scrum and most of the companies start using it with right spirit; however they end up getting entangled between incumbent processes, rigid culture and the changes caused by Scrum. This article aims to bring to light some common and serious problems which is causing Scrum Framework to not work at its full potential. If any of them apply to your company, it’s better to do something about it.
1. Waterfall mindset – The software industry has been traditionally using Waterfall methodology and has mastered the art of implementing it. With complexity of projects increasing and the companies being new to scrum means that extra work needs to be done to master the art of Scrum. Going into a Scrum project with a waterfall approach is a recipe for disaster. Scrum and Waterfall are like apples and oranges and it is important for people concerned to realize this as well. We need to brainwash individuals who enter scrum and have years of waterfall experience.
2. Scrum Masters become Project Managers – Scrum Master role is a very crucial role in scrum team and should not be mistaken for a traditional Project Manger or a mere facilitator. While the former is too powerful, later is powerless.
A scrum master with a project manger mindset often does the following mistakes:
a) He Makes the Daily Scrum meeting turn into a daily status meeting –The daily scrum meeting is by and for the development team. The development team should feel that they are in control of the meeting and not the Scrum Master. The role of a Scrum Master here is to facilitate and help the team with their impediments.
b) He often disrespects the time box of Daily scrum – In an endeavour to dominate, Scrum Masters stretch the time box. The whole idea of agile is to move faster. While one person needs to discuss something more, he might be wasting time of others.
c) The team who’s Scrum Master behaves like a PM with a stick, might delay in reporting impediments and mistakes as they might think it will be taken negatively by the Scrum Master. This defeat the whole purpose of Scrum as the whole idea is to get rid of the hurdles quickly so that we can inspect and adapt ASAP and move ahead. We are dealing with a complex project in Scrum and such things make the project even more complex.
An appropriate term to describe a Scrum master is a servant leader and that’s how he should be.
3. Product Owners become mere Requirement gatherers – A lot of companies do not empower their product owners to take decisions which are best for the product. The top management has a clear signal for Product owners to only make the customers happy by simply agreeing to do exactly what they want as the financial model usually in Scrum is Time and Material. In this case the product owner generally ends up being a requirement gatherer.
A good product owner on the other hand is one who should have the power of taking decisions which are best for the product but only after taking the customers in confidence. He is the product leader. He should also respect the decisions of the development team and not pressurize them unnecessarily and expect something which customer wants but in the opinion of the development team is not possible. Often the need to satisfy the customer takes away from the product owner the need to respect the decision of the development team which is also working equally hard to deliver the best product possible.
4. Inequality in Development Team – The development team often feels they are under Scrum Master and even within the Development team there might be seniors and juniors just like they used to be in their past projects. Scrum says that everyone is equal and there isn’t any hierarchy.
There is no individual responsible for failure. All the User Stories are a collective responsibility of the team. Things start to get ugly when individuals within the team start pointing fingers at each other for whatever goes wrong. Now the Scrum Master has to ensure that the team realizes its collective responsibility and always wins.
Closing Thoughts: If you really want to take benefits of Scrum then use Scrum and not an organization suited twisted version of it. Because then it is not Scrum, it is something else.
All views expressed are personal and not necessarily apply to any company. It has been a general observation working in different projects over a period of time.