Scrum or No

PM findings #8: Thoughts about good and bad in Scrum; do you want your job posting to be for Scrum Master?

There are plenty of job openings currently for Scrum Masters and I keep on wondering how strange is that.

Scrum is just one of many Agile frameworks and processes which you apply to achieve product goals efficiently. If you hire Scrum Master, you limit your team choice and make them stuck to Scrum. Do you want that?

If the person you hire is Scrum Master, how likely he/she will raise that Scrum is not working for the team, I think SM will push on adopting Scrum even if it is no good. Why you would risk your team’s efficiency with that job posting? I would prefer to keep options open and look for Agile enthusiast, whatever broader term you would apply to it, who will keep on thinking of maintaining Agile environment which works best for the team, open to making adjustments wherever needed.

Why Scrum and why No

Scrum is a really good approach and before exploring Shape up, I would say is the best especially for the new teams working together. Scrum has some really “strict” rules and ceremonies, which help the team to have a more defined process. Following these rules also help to form habits for the team and build a solid ground to make switches.

However, as I see around, Scrum is now being interpreted with the most “non Agile” ways. It is getting more common to hear that “you know for our team Scrum is heavy”. I assume the reason is that Scrum is the most popular approach (or used to be) and a very well documented one. Scrum Masters in the market, started applying these rules strictly to the processes, without digging deep into the purpose and meaning of each, making it more and more not Agile.

Oh and another creepy thing is that there are teams who criticize Scrum Master, who also wants to take part in product thinking. This is so mind-blowing, I believe everyone in the team not only SM should be part of the Product team, think and work towards product goals.

So like I have mentioned above, I think Scrum is a good methodology for new teams, since:

1. It is well documented with clear events, which helps the team to be guided and develop habits, a culture of collaboration, deliverables mindset.
2. I think it also helps Businesses to have a clear expectation since the team commits to the exact scope which is to be delivered end of the sprint.
3. Scrum also puts pressure on Product Owners, to make requirements ready and always think of prioritization, not asking all at once.
4. Also, Scrum is the most popular methodology, it is always easy to start with well-known things.

However, you should ensure that you have a Process person with the team, who will help to adjust the processes, so that processes support the team needs best. Make sure your “Scrum master” is not dogmatic and open enough to lead that.

I googled Scrum and saw so many articles on why Scrum is bad, why it is killing your product etc, I believe this perception is mostly due to lack of quality implementation or deep understanding of the processes.

However, there is one big issue, which again I realized lately: every Sprint in Scrum is still waterfall. A team commits to EXACT scope based on initial estimations, and as we all know, estimations are always wrong.

When we start any kind of Agile project we have 1 key question on strategy, what is variable: time or scope? If time and scope are fixed, then that requires proper review and planning phase as in waterfall. So in Scrum, we have that issue again. Teams do grooming meetings, put estimations with story points, and then during sprint planning, they commit that they will deliver this exact scope with detailed Acceptance criteria and pixel-perfect design within a set time box, without having the planning phase upfront to define scope precisely.

This is so far my biggest issue with Scrum and the brilliant solution is introduced as Shape up, which we eventually switched to for one of our teams. Even if you don’t fully switch to Shape up, defining freedom for the team to play with the scope of each item of the sprint, can be a deal maker. If that can not be the case, then it means that for your case Scope is to be fixed, which in its turn makes the time variable and for that cases, I think Kanban is to be the option.

Share with me your thoughts about this, Scrum or no? Post your replies here or we can keep in touch via email aavetissyan@gmail.com or Twitter @meniem.