Is Scrum the Right Tool for You?

Scrum is a popular agile methodology that is used in project management. It emphasizes teamwork, accountability, and iterative progress toward well-defined goals. Scrum is widely used in software development, but it can also be applied to any project that requires a flexible and collaborative approach to problem-solving.

My Experience.

I have used Scrum only one time where I can definitely state it was used correctly. The project used rigid ceremonies such as stand-up, planning sessions, and retrospectives. Most of the other times, I have worked in agile and half-scrum settings, where the daily standups were weekly and sometimes every other day. Both ways have worked, and both have had weaknesses.

Using Scrum and Other Ways of Being Agile

One of the important aspects of the actual scrum project I worked on was that it was an interdisciplinary project where the team cooperated with a customer. The customer, who had little experience with agile work methods, hired a dedicated scrum master who used a lot of time to ensure that all adhered to the disciplines of the scrum. It was not always game-changing acts of leadership and agile breakthroughs, but small things, such as:

• This is something not everyone at stand-up is required to hear, but rather, you two engineers should stay behind and discuss.
• Make sure that the board is actually updated.
• Make sure the descriptions on the card are aligned.
• Teach the junior engineers how scrum and agile are supposed to work.
• And all the boring stuff, measuring progress, keeping the board clean and updated, removing trash user stories, or making them somewhat understandable for engineers. This was important but required a full-time scrum master to do.

In the other projects where we used some agile methodology, we had other ways of fulfilling the requirements of the projects. We used a kanban board but mainly to ensure we had a scope of work displayed so all could see. Planning sessions were the most important way of communicating the work to be done, and it was split into user stories that more resembled major tasks or epics if an epic was a two-week job. Quick discussions around the open landscape replaced the stand-up and clarifications. An hour with a subject matter expert led to a new user story and two days of data analysis to dive deeper into questions raised in the discussion. Feedback from the end-user was retrospective, as were the after-work beer and climbing sessions with the core team, which were an opportunity to discuss instead of formal cards on retrospectives.

Both methods worked for their purpose, even though they usually were designed from the leadership point of view to deliver them.
One of the defining differences I learned between the real scrum and independent agile team was the scrum master, a dedicated process wizard who focused on making sure the team moved in the same direction at all times.

When is Scrum an advantage?

Scrum provides discipline; it helps all team members stay on track and focus on delivering the value they are supposed to do. In short, scrum provides a set of rules that helps the team to stay on track and deliver. Scrum is also a good way of reducing information entropy, aka the dissolution of quality information into a sludge of hearsay and outdated documentation. Keeping everyone aligned and making sure the correct information reaches the right people is a momentous task, and the discipline from the scrum, as well as the demand of the team members to participate in information-sharing activities (Which basically all the ceremonies of scrum aim to do), helps with information entropy management.

When is Scrum the wrong tool?

Scrum is a demanding form of work. It is freedom through discipline. And it requires discipline. As all projects go, it is increasingly difficult to keep that discipline. To do scrum right, a lot of resources (time, effort, and willpower) is required to maintain the ceremonies, keep the focus up, and ensure everyone is on board. This resource is not something that everyone has available, and inexperience and lack of ownership might make a half effort at scrum counterproductive. This means that for small teams (less than seven people or less than two pizzas), this is too small of a team size. In my experience, not having a scrum master means you are not doing scrum but halfway going through the motions, methodology masquerading as scrum. It also leads to another point: buy-in from all team members. If someone thinks that scrum aint a good solution, then it is surprisingly often that the ceremonies gradually decline into bad practices, sloppy execution, and eventual dissolution of scrum into some bastardized sort of agile, which, as all bastards know, still is quite capable of getting the job done.

In conclusion, Scrum is a robust methodology that can help teams work more effectively and efficiently, provided it is implemented correctly. Understanding when to use it and to what purpose it is meant to play is crucial for a product owner and team leader. It should not be implemented just because everyone else is doing it or because we work with tech. It requires a lot of effort and resources to pull off, as well as a clear vision and mandate. If the resources are constrained, the purpose of the project and the mandate of the team are unclear, or the team is sufficiently small, adding a way of working that is highly rigid is quite dangerous. Think twice before suggesting at your next stand-up.