What is Scrum and how should I use it at work?

Category: Professional Advice




Hi, everyone. Today, I bring you a brand new post from the Oktara Software blog to help you get inspired and even learn a thing or two about this Agile revolution you’ve probably come across at work. In this post, I will demystify the concept of Scrum and show you how you can apply it to your software development endeavours.

The definition and origins of the word “Scrum”.

The Scrum we’re talking about here is an adaptation of the word “scrummage” taken from the game rugby. In rugby, a scrummage was the method used to restart play in a match after a foul. Visually, it’s 8 players from each team packed together with heads down all trying to take possession of the ball. If you think about it, with a little imagination, it makes sense. On a project team, the goal is to get the project done. Historically, using traditional methods, this meant planning and designing the whole project at the beginning and sticking to that plan with no variation. In real life, project work is completely unpredictable. It’s impossible to know at the beginning exactly how a project will unfold and how to best meet its unique challenges.

The Scrum approach breaks the deliverables and milestones into smaller pieces and gets the whole team together to focus on just that one goal until it’s done. Like in rugby, if the small, individual scores happen on a regular cycle, winning the game (or delivering the project) will take care of itself. So, in that regard, Scrum means to run your projects more like a rugby match pursuing the small goals and deliverables that will get your project done.

The “Fail fast” slogan.

Scrum is known for the slogan “Fail fast” for a very good reason. Traditionally, project managers and developers would work for months or years before seeing the results. Most of the time (around 80%, in fact), the software and projects failed. So, why are they signing up for more failure under that slogan? The trick is in focusing on the second word (“fast”). Failure is ok as long as you’re learning from it but, if you have to wait too long, you’re not going to learn nearly as much from it. Scrum takes the key principles of Agile and boils them down to a very simple framework that encourages small-scale focus and rapid learning cycles. That’s why “Fail fast” really means “Learn fast”.

With that in mind, the basics of the framework are designed to encourage that fast feedback loop. The Scrum framework is not prescriptive. We generally refer to it as “guardrails” (like the ones you see on the highway). Those guardrails don’t tell you exactly where to drive in the lane but they keep you within the boundaries that will result in a successful roadtrip. Scrum is much the same. With the Agile principles as the guide pose and a loose framework of activities executed on a regular short schedule, your project will be set up for success.

The Scrum framework in action.

In summary, the Scrum framework in its simplest form looks like this: To start, the Product Owner has a prioritized backlog of work for the team to do. Every 2 weeks or so, the team looks at the backlog and decides what they can accomplish in the next 2 weeks. The team develops and tests their solution to the backlog items until they’re done and ready for use. At the end of the 2 weeks, the team demonstrates their accomplishments to the product owner and stakeholders. Finally, they reflect on how things went during the 2 weeks and they decide what they can do to improve their work practices. The short timeframe and the focus on a completed product at the end forces the team to “fail fast” (or, more appropriately, “learn fast”).

The difference between Waterfall and Scrum.

Being a traditional Waterfall project manager made it really unlikely that your project would be successfully completed (let alone according to the plan you laid out at the beginning). It was more like being a weatherman doing a forecast for a specific day next year (except for random luck, you’d be wrong). Waterfall as a methodology is not inherently a bad thing. In some cases, it makes good sense (like in building construction). You can absolutely plan and schedule a construction project upfront. It happens every time a home or an office building is built. The problem comes when applying the technique to highly empirical work (such as software development). Empirical work is more like a science experiment (you try something, check out the results and, if it didn’t work, you try something else). You certainly can’t do that when building a house but, with software or some other products, you do it every day. That’s the main reason why Waterfall didn’t work well for software development. You literally cannot upfront plan the process of discovery. The frustration of highly skilled software developers working on Waterfall projects was the tipping point that led to the Agile revolution.

The creation of the Agile Manifesto.

The result of these developers wanting to solve this problem is known as “The Agile Manifesto”. You can take a look at the Manifesto here: http://agilemanifesto.org/principles.html

This group of innovators supported this manifesto with 12 key principles. One of the key changes is that we’re asking our business partners to work with us throughout the whole project (not just show up at the beginning to describe what they want then, show up at the end and tell us how we missed the mark). We need direct, ongoing interaction to deliver what they really need. Another key aspect is that we no longer want to measure success using milestones and project phases. We want working software to tell everyone how we’re doing and we want to hear feedback the whole time. Your team will do a much better job doing the design and tests from the ground level than any upfront plan could do. Upfront planning is theoretical. Evolving design is both practical and tactical. It’ll get you to your goals faster with higher quality.

Key roles that partake in Scrum.

There are 2 key roles that exist on every Scrum team: The Product Owner and the Scrum Master. Let’s start with the Product Owner (or “PO”). The PO is the business representative on the team. They’re not part time team members. They show up every day because they’re contributing to the final product every day. They review all the work the team completes and either accepts it or asks the team to make changes to ensure the highest value is being delivered. Formerly, the business person was represented through requirements documents that were rarely (if ever) updated. On a Scrum team, the PO is always ordering the work and ensuring the team members clearly understand the details of the request but that’s only part of their job. They’re also interacting on a daily basis with the stakeholders. It’s not enough for the PO to interact with the team. They must also be in tune with all the changes that are occurring in the business context. As a result, the PO is the keeper of the product vision. He or she defines and manages the backlog of work to be done and the prioritization of those work items. Since time and cost are locked, the PO is painfully aware that the work must be continuously sorted to highest value first. They’ll also be pushing the team to complete as much work as possible in each short delivery period.

The founders of Scrum recognized the need to counter-balance the PO role. So, they created the role of the Scrum Master. The Scrum Master protects the team and protects the process. The Scrum Master is the facilitator who keeps the team within the guardrails of Scrum. They balance the demands of the PO against the needs of the team. This role is the first safety valve to ensure teams are performing at a sustainable pace. We don’t want them to get burned out before they reach the finish line. That’s a big statement if you think about it. Scrum values sustainability and open dialogue on what can and cannot be reasonably accomplished. The Scrum Master is the most visible spokesperson for the team. Scrum Masters value transparency. They’ll devise charts and boards to share the team’s progress with anyone who’s curious or interested in how they’re doing. They’re also the first escalation point when something gets in the way for the team. The Scrum Master will work to remove any blockers until they’re out of the way and the team can continue on.

If you’re lacking one of these roles, Scrum will be far less effective than if you have them both.

What are User Stories?

Each interaction our client has with our product is a use case that tells the team a story about how they’re going to use our product. We call these “User Stories” and this is the level of detail we need to know what to deliver. The User Story then is the tactical level of work that can be delivered quickly. At the same time, they’re not so small that they deliver no value. Anyone on the team can write User Stories but it’s usually the PO. As the stakeholder and representative for the customer, it’s their duty to ensure everything in the backlog adds value for the customer.

While this seems like a lot to accomplish with a User Story, we have a format that helps us write good ones. Here it is:

<user role>, I want
<user requirement> so that
<desired benefit>

By understanding which customer we’re talking about, we get a better understanding of the need and it helps you focus on an activity within our product. Clearly defining the need and, most importantly, the benefit expected from that requirement helps trigger the conversations the team must have in order to be clear on what is valuable. An example of a good User Story could be:

“As a mobile customer, I want
to create a profile so that
future orders are faster to place”.

It’s not good enough to have good User Stories. Each one must also have “Acceptance Criteria” (or “AC”). In the case of our Functional Story about creating a profile, the AC could be: “That customer name is captured and saved. Next, customer email address is captured and saved. Also, customer phone number is captured and saved and customer password is captured and saved”.

Your AC should be as explicit as possible so all parties on the team know what “done” for the Story really is.

User Stories are the tactical tools Scrum teams use to deliver the work for their product. Writing good User Stories can be challenging but, with practice, it gets easier every time.

That is all for my introduction to Scrum. I suggest you refer to this blog post to your project managers or team in general for them to illustrate exactly what it means to work on a Scrum-based environment. Take decisions as a team and apply these concepts and you will be well on your way to succeed with your first Agile project.

Until the next post. See you.

Leave a Reply

Your email address will not be published. Required fields are marked *