Should You Do Scrum?

“It is not the strongest of the species teams that survives, nor the most intelligent. It is the one that is most adaptable to change.”

That should be a good enough reason for all teams out there to adopt Scrum, from wedding planners to construction companies. But that isn’t always the case and if you stick around, you’re going to find out why.

Developed by  Hirotaka Takeuchi and Ikujiro Nonaka in the late ’80s, Scrum is a framework that challenges the traditional, sequential approach to product development, an approach which cannot quite address unpredicted events. By doing Scrum, teams become able to self-organize, adapt to customer-inflicted changes and communicate efficiently.

So Scrum is basically comprised of a self-organizing team that is given a task, and to meet that task, works in short, time-boxed iterations during which they meet daily to quickly synchronize their efforts.

At the beginning of each iteration, usually called a Sprint, the team members meet to plan what they will accomplish. At the end, they do a quick but very effective series of meetings through which they inform the customer (or product owner) about what was accomplished during the last Sprint and reflect on how they worked together to achieve it.

The first thing I learned while doing Scrum is that the team size is not that relevant. While it is recommended not to do Scrum in Teams bigger than 10 members, you can easily use Scrum by yourself in your personal life.

Thus, one of the key principles of Scrum is that it is best applied to volatile projects, those in which things can change pretty fast and in which failure to adapt equals failure to deliver or to accomplish the task. That’s the main reason why Scrum fits perfectly with software development projects, where features that seem solid today fall into irrelevancy the next day.

So, if you’re faced with a complex and possible chaotic project, whether it be your daughter’s wedding or the military invasion of Mordor, you simply have to:

1. Decide on the Sprint (iteration) length: it should be long enough to allow your team to actually complete valuable features (also called User Stories), but short enough so that the product owner is engaged in the progress of the project. The recommended size is between 1 and 2 weeks.
2. Plan the upcoming Sprint: start by setting specific goals that need to be reached by the end of that Sprint and keep in mind that those goals will be shown off to the product owner. Then decide how much work your team can take on during that iteration and have the entire team commit on those goals.
3. Hold daily status update meetings: this is usually called the Daily Scrum, it should not last longer than 15 minutes, and all you have to do is to inform the rest of the team what you worked on yesterday, what you’ll be working on today and what issues or blocks you hit down the road.
4. Demo the Sprint: Time to shine! This is where you get the chance to show off the awesome stuff you built during the last iteration.
5. Review what did and did not go well: This is one of the most important aspects of Scrum since a Sprint Retro is the place where the gloves come off. The team needs to objectively assess their ups and downs and should end the meeting with a clear set of commitments.
6. If the project is still ongoing, go back to Step 2 🙂

And that’s about it. Following these simple steps should drastically optimize the way you or your team works. But please keep in mind that it will not be easy! Self-organizing teams rely on responsible, accountable and passionate team members so a drastic change in each individual’s philosophy needs to take place before embracing the power of Scrum.