The pitfalls when forcing all things in a Scrum box

Photo by Eden Constantino on Unsplash

Scrum 101

To understand the rest of this article, first stop, we need to understand what Scrum is. In a nutshell, Scrum is now one of the most popular frameworks that are used in software development. The framework helps people address large, complex, adaptive projects into small deliverable phases. There are some key artifacts in Scrum.

• Sprint: a fixed time-bound for each deliverable phase, normally one sprint would be 2 working weeks.
• User story: an informal, general explanation of a software feature written format from the perspective of the end-user. Its purpose is to articulate how a software feature will provide value to the customer.
• Story point: an estimation method that helps developers to estimate their work faster and still in an acceptable range of accuracy by comparing the amount of similar work between the past (already associated with a story point) and upcoming work. For example, if work A takes 2 story points in the past and work B is very similar to work A, then it is likely that work B also takes 2 story points.
• Velocity: the total story points that the entire Scrum team has burned within a sprint.
• Scrum rituals: multiple meetings rituals including daily standup, backlog refinement, sprint planning, feature showcase, retrospective.
• Product Owner: a person who prioritizes what items should be worked on first that can help maximize business value.
• Scrum Master: a person who is responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use.
• Team of Expert (aka Scrum team): made up of individuals who directly contribute to designing, building, and testing features.

The one key element

With the basic understanding of how Scrum works in mind, now it is time for us to discuss why the Scrum framework shouldn’t be the bible for all projects and cases. I have seen many companies that worship the Scrum framework to the point that they force all things in the Scrum box and ignore the fact that sometimes Scrum doesn’t work in that case, but putting stress and pressure on the team.

The one prerequisite for Scrum to work well is people. When I mention people, I am not just talking about people in the Scrum team, I am also talking about investors, executives, customers, prospects, and partners, etc…

Situation 1:

There are many cases, investors and executives want us to double revenue which means we would need to acquire more big customers. Most of the time, it also means that we would need to build integration, customize features for those prospects to increase the conversion rate. If that is the case, the Scrum process won’t work. People would require to have a clear understanding of requirements, do a lot of investigation work beforehand for more accurate estimation since it has a deadline most time. The estimation must be calculated in days or even hours depending on how urgent we need to ship a feature.

Situation 2:

Scrum requires people to be self-managed and proactive. In reality, we would be lucky if we have two people who can self-manage, given a scrum team of seven people. Developing and growing human capital would take time, it is a long-term process if a company is willing to invest in us. So when people can’t self-manage well, who would be the one to ensure work progress is going well so that the company could make money to operate? Well, that is when we would need to have someone playing a role as in Project Manager or Delivery Manager. This role doesn’t exist in Scrum and so that is another drawback in applying Scrum for all.

Situation 3:

We are building whole heaps of foundations in a short period, things that we know 100% how important it is for customers. Unfortunately, the original technical design foundation couldn’t adapt to a large user base, also multiple complex use cases. In this situation, spending a lot of time, effort on new product ideas contribution isn’t that valuable as compared to spending more time on thinking and planning what the technical design should be for long-term growth. In this case, the majority of the time will be for the tech lead or architect and tech team to brainstorm and plan, there would be no tangible values for executives to look at or experience during that time. And like I mentioned, if the planning is not allowed as actual work during a sprint, then we need a different approach right ? for example, one of the ways we could do is put one team member aside to own the tech design beforehand, while everyone else in scrum team would continue delivering other tangible features or functionalities. Then once the design is ready, the team can do the planning, breaking down work following the Scrum.

The 3 key principles

I can list out many other situations regardless of this, but these are the 3 most common ones I have seen. With that being said, there is a solution for all problems, but for sure, it won’t be in a pure, and primitive Scrum framework. For this case, it would require people to have an open mindset to create hybrid frameworks that would work well in each situation.

That would require 3 following principles:

1. Set up a dynamic Jira board that can adapt to many situations and frameworks
2. Be completely transparent to Scrum team about the hybrid frameworks and how it works. Also, most importantly, we provide them why and timeframe to apply the framework. We don’t want to have people thinking that the framework would last forever.
3. Have a clear communication plan to make sure all stakeholders are on the same page as each situation comes up.

These 3 principles seem simple, but very hard to master as it requires an open and adaptive mindset from all sides of the business. And I believe that once we do, our work progress will go so much smoother with no confusion or assumptions, or frustration from any side.