How it is to work in a “Scrum by the book” environment

If you work in tech, you’ve certainly heard about the usage of Scrum to improve the way projects are managed and software gets created and delivered.

From my casual conversations with colleagues and friends over the years, I’ve come to understand that most people have serious doubts on the way Scrum is being used in their working environment, some are certain it is being misused and some simply lost faith on whatever their company says its using/doing and think it is just another PR stunt.

Photo by Marvin Meyer on Unsplash

In the last two and a half years I’ve worked in what can be described as a very “by the book” usage of Scrum — I mean, using the framework properly was actually something important for teams and leadership.

Now that I left that company, I am sure that I am mentally free to reflect on what that experience was like and provide everyone who reads this article a glimpse on what it is like to work in Scrum, in a place where its application is taken seriously.

Short Introduction to SCRUM

To talk about Scrum usage it is first needed to talk a little bit on what it is and how it works. That being said, if you really want to get into Scrum you’ll need to read the scrum guide.

Alright, let’s get to it:

Scrum is a lightweight framework to help generate value. That’s it, that is what scrum is. Scrum is not Software/Tech/IT specific. If you have a product to create, or a complex problem to resolve, any activity that includes value to be delivered, you can use Scrum.

What does it mean to be “lightweight”?

Scrum is pretty simple, the Scrum guide itself has less than 20 pages and contains all you need to know about it. Scrum does not provide detailed instructions, it just provides rules of guidance. It does not require the tool “X” or “Y” to be applied — even though there are indeed tools — like Jira — that are helpful.

Scrum wraps around existing practices or simply renders them useless, it also make visible the efficacy of management.

Scrum requires a Scrum Master, who fosters an environment in which :

1- A Product Owner orders the work to be done into a Product Backlog.

2- The Scrum Team turns a selection of the work into a value increment during a Sprint.

3- The Scrum Team and Stakeholders inspect the results of the Sprint and make adjustments for the next Sprint.

4- Repeat.

So, basically, Scrum works in a constant loop of production of value, delivery of said value and discussion on how to maximize upcoming value deliveries.

Value can be anything, we are the ones defining value. Value depends on what the project is. If the project is providing drinking water to places in need, maybe value is “ number of delivered gallons of water”, if we are working on software development, maybe value is “new features”.

Scrum is founded on Empiricism and lean thinking, which gets reflected on the Scrum pillars: Transparency, Inspection and Adaptation.

Transparency is required to make sure that everyone knows what we are doing, how we are doing it, where the pain-points are, why decisions are being taken, where are we heading, what do we consider value, etc.

Inspection has to be done to make sure we are on track to achieve the value we set out to, and, if not, where can we improve. Nothing and no one is beyond inspection, because we want to do things right and are not afraid to inspect in order to find improvement areas.

Adaptation as we act on what we identified as needing change, facilitated by the transparency of the whole process, and to the inspection of our work and its results.

There is more to say about Scrum, but to do so it would be an article just regarding Scrum theory. Since that is not the scope of this article, I’ll just burst a few keywords and short descriptions to make sure whoever reads this article can understand what I am talking about:

1- Product Backlog is the tangible translation of the current vision for the product. It can contain items that are ready to be worked on and items that are yet requiring some refinement to get closer to being “workable”

2- Sprint Backlog is the selection of product backlog items that get selected to be done in a given sprint.

3- Refinement of product backlog items means making clearer what is required by that item, and how can it be done. Making that item as atomic as possible and, if not possible, slicing it up into more atomic items so that work gets very clear, very granular and very transparent.

4- A Scrum Master is responsible for making sure Scrum is being followed as defined in the Scrum Guide. The Scrum Master is accountable for helping others understand and apply the framework, he is the contact person when the subject is “how to apply Scrum”.

5- A Product Owner is responsible for the route the product takes, he owns the vision for the product and with that vision, the work that needs to get done and when to do it. He is responsible for managing that, and making sure it is clear to everyone involved.

6- The Dev Team is responsible for turning selected items of product backlog into deliverable value, as well as providing estimations on the effort required to do so, when refining backlog items.

7- A Sprint, is a short timeframe in which “Backlog Items” are transformed into deliverable value by the dev team.

8- The Scrum Team is the name given to the group comprised by Scrum Master, Dev Team and Product Owner.

9- The Sprint Review is when the Scrum Team and its stakeholders inspect the work that was done and the value deliverd as a result of the Sprint.

10- The Sprint Retrospective is when the Scrum Team discusses what could be improved upon the practices and interactions from the last sprint. It is when actionable points come up so that improvements can be made.

11- The Daily is the most frequent Scrum Event as it is done every day at the same time and place and serves the purpose of being a moment of “quick sync” between the Dev Team members so that what is being done, what is being a pain and what we are doing about it is transparent.

12- The Definition of Done is how we define that a Sprint Backlog item is ready for delivery and can be considered “value”. It represent pretty much a “black or white” situation. It should be specific enought so that an item either complies with it or not, and if not, it is not ready to be delivered.

Reflecting on my experience with Scrum

Now that we’ve done a quick overview on what Scrum is, it’s time to reflect on the outcomes of its usages that I’ve witnessed first hand.

Your mileage with Scrum may vary but, as I already said, I think that the experience and environment I worked in was as close to it being properly applied as you can get (especially in anything that depends on relationships between human beings with different desires, backgrounds and mindsets).

To make this relection easier to consume, I’ll separate it into two listings:

• The “Pros” of using Scrum;
• The “Challenges” of using Scrum.

The Pros of using Scrum

• You are always focused on short-term attainable goals — the sprint goal
• You don’t need to make a big effort to know what is going on with the product/project — thanks to the daily, scrum events and transparency of the backlog)
• You are not tied to long-term vision of something that was defined ages ago. — Your tie is the current Sprint and its goal.
• You have frequent and well defined moments to analyze, discuss and plan improvements to the way work is getting done. — Procrastination is easier to avoid.
• Transparency is a great driver of problem solving and happiness at work, and Scrum strives for high levels of transparency.
• The sense of being part of a team is heightened by the fact that the Sprint Backlog is owned by the entire team and not the individual developers who are doing each and every task — If the team succeed everyone succeeds, if the team fails, everyone fails.
• The fact that Scrum teams are cross-functional means that you’ll gain knowledge and become confortable with an array of tasks that your work demands: Front-end development, Back-end development, CI/CD, Operations and whatever else aplies.

The Challenges of using Scrum

• It is challenging to get everyone on board with Scrum. People have opinions and like to do things their way. — An example of this would be to want to skip the daily because “there is nothing to be said”.
• Product Owners can try to tamper with the dev team’s estimations to “fit more value into a Sprint”. — “If I convince the guys to give a lower estimation to a story, more work can be done in this sprint because more stories will fit”, this is the weird kind of logic that seems to pop-up in people’s minds.
• Refinings User Stories is not something that you can easily do out of the blue. Often you will need to look closely into what is desired from any given story in order to have meaninful insights and questions about it. Most often than not, I’ve found myself needing to do this analysis after hours because I would not have time during the day.
• During the process of trying to improve on the aspects that needs change, more heated discussions can happen, as well as confrontation to a degree. To most of us those are not pleasant moments, but absolutely necessary. If done with respect, both the working environment and relationships become stronger. Otherwise, ressentment builds up.
• A proper Scrum Master is totally required. Everyone is responsible for making Scrum work, but if all else fails, it is the Scrum Master’s responsability to make sure everyone understands the framework and their roles within it.
• Scrum is not something that is second nature to people and you can’t trust their word on how they “are used to work with Scrum”, especially since it is not properly used in most places. You must always provide Scrum training to new people on your organization before they join their respective teams.

Conclusion

I hope that this article helped to at least shed some light on what Scrum is, what it has to give us and which are some of the real world challenges of its application.

From my experience, working with Scrum is highly beneficial for both companies and individuals due to the ease to pivot directions and constant focus on tangible and attainable goals.

It is highly important to get people trained on the framework before they are placed in their respective teams when joining the organization.

Scrum is not “set it and forget it”, it is High Maintenance. The settings in which Scrum is used are living, complex, multi-person environments that demand constant attention and effort to keep on the. right track. Otherwise, it will tend to chaos like everything else in this world.