WTF is SCRUM

There is a never-ending debate in Software/Product Development circles on which agile methodology is better. Some defend SCRUM to their last breath. Others vouch that Kanban is the way to go. Some claim that a mixture of both, ScrumBan, is a perfect middle ground. While a bunch of people think that all these are just fads, and in practice are just extra fluff to traditional Waterfall.

During my career, I was in charge of implementing both SCRUM and Kanban into my development teams’ workflows, for two distinct organizations. Both initiatives were a success (though very challenging at first). In my opinion, there is no right answer to the above question. It all depends on the team you are working with. The type of project. Deadlines. And honestly, as long as you have short release cycles so that you can learn fast and improve your processes, then you are on the right track.

That said, here is a short overview of SCRUM alongside some of its pros and cons that I learned from my hands-on experience:

WTF is SCRUM

Without going into the history of SCRUM, basically, the product development process is divided into a set of small releases, usually every 1, 2 or 3 weeks. The idea is that every release the team should deliver a shippable version of their product. I.E. a polished and usable version that you can (but do not have to) go live with, or show to stakeholders/clients/users.
This is important because the core idea of SCRUM is to get real and fast feedback about your product (eg: does it solve a real need?) and internal processes (eg: is the team’s velocity high enough to meet the deadlines), throughout your development cycle.

It sounds simple, but in practice it requires a lot of discipline from all teams involved in the process. And it works best when the organization is laid out around SCRUM teams; a matrix team made of all the necessary personnel needed to release a version end-to-end. Usually, the SCRUM team is made of a Product Owner (PO). A SCRUM Master (SM). A development team lead (DevTL). A designer (UI/UX). 2-4 developers (devs). And a software tester (QA).

There are a lot of resources online and books that teach you the nitty-gritty about SCRUM. And also check out the below video from Spotify about its Agile engineering culture.

Now that we did a short overview of SCRUM and got that out of the way. Below is what I usually do with my teams at the start of each sprint (our ”Sprint Ceremonies”):

1. The SCRUM Master (or the PO or DevTL if there is none) initiates a Storytelling meeting with his SCRUM team
2. In this meeting, the SM goes over the Stories (features) that are scheduled for the sprint one by one. And basically, aligns the team about the goal of the sprint. Eg: Release feature X, or reduce the number of crashes.
3. The team takes a few hours to read the PRDs/GDDs. Add their comments. Estimate the stories (in SCRUM we use Story Points. A metric of complexity, and not actual hours. And the estimation process is called Poker Planning). And then reconvene for a follow-up meeting.
4. In the follow up meeting the SM and PO:
   1. Answer the team’s questions and go over their feedback
   2. Resolve any inconsistencies or risks raised by the SCRUM team (for example missing UI assets. Inconsistencies in the PRD. Etc…)
   3. Sets a scope for the sprint (usually by dragging stories from the backlog to an empty sprint board), until the SCRUM team reach their full capacity.
      Note that the team’s capacity is determined after a few of sprints based on how many stories they can usually deliver.
   4. Gets the final approval from all the stakeholders (management and clients)
   5. And officially kick-off the sprint
5. The team then do a retrospective on the previous sprint (can also be scheduled before the Storytelling meeting) to understand:
   1. What went right, and what should the team keep doing?
   2. What went wrong, and what should the team not repeat in future sprints?
   3. What should the team start doing in future sprints?
6. The SM then sends a summary report on the retrospective. Assigns action-items to the relevant parties. And makes sure that future sprints go smoother.
7. And with that, the sprint ceremonies are done (it usually takes a whole day). And the SCRUM Team can work uninterrupted and focused during the sprint. Their objective is to finish 100% of the stories (and by extension complete the sprint’s goal) before a code-freeze.
   Stories that are not done in the sprint will be pushed back to the backlog. However, there should not be many of them (if at all). Otherwise the estimates are inaccurate, or there’s a major issue with the process that should be identified in the retrospective .

As you can see, SCRUM can be a bit intimidating. And some teams sometimes choose to simplify it a bit, for example by skipping the Story Points and using hours to estimate their tasks. That said, it still requires a bit of a learning curve. Which brings us to its Pros and Cons.

Pros:

1. The whole team have one goal “Finish the sprint and complete the sprint’s goals”
2. Highly focused on improving the team’s velocity. Improving the development processes. And improving the overall product.
3. Gives a feeling of accomplishment and builds comradery. I usually go out for drinks with my team every time we close a sprint, and also let the team vote on sprint names to instill ownership.
4. If the sprint is not closed on time, then it’s the whole team’s fault (not R&D, Product, QA, etc…). The whole team both share the successes and the failures, which enforces accountability.

Cons:

1. Breaks down if tasks keep getting added to a sprint midway through development. It’s the job of the SM, PO and DevTL to be the bodyguards of the team. And shoot down requests to do any changes during a sprint unless absolutely critical (eg: hotfixes to critical bugs).
2. The first few sprints are a pain, and SCRUM requires a disciplined team that is committed to making the process work.
3. Less flexible and hard to add/remove resources to a team. That means the team’s composition (size, people, etc…) should remain consistent, otherwise it will be difficult to estimate their true velocity.

And that’s it for this post. It turned out a lot longer than expected…

As mentioned in the intro, whatever methodology you end up using is meant to improve your development processes and help you ship better products faster. If you find yourself having to work harder to use SCRUM for an extended period of time, then you might need to rethink things. That said, when SCRUM works it’s very accurate and highly efficient.

Next post we will do a similar breakdown on Kanban.

Cheers 😀