Sprinting to success with Scrum: how to make sure it is done effectively

In its essence, agile product development is a mindset for dealing with an uncertain environment. The best way to do that is to find the path forward one step at a time. This means delivering frequently, observing how users react and interact with the product, and adjusting the approach for the next iteration according to the feedback and observations. Scrum is the manifestation of exactly this approach within a project management method.

Scrum was first used in the early 1990s. Inspired by lean production and influenced by others in the field of product development, Ken Schwaber and Jeff Sutherland refined the framework in practice and co-presented Scrum at the OOPSLA Conference in 1995.

They seem to be the agreed fathers of the framework and have published extensively about the method. Schwaber and Sutherland are also the ones that write and update the official Scrum Guide, a brief document that outlines how Scrum works. 

It feels like Scrum has recently come under Scrutiny. I have certainly seen my share of articles criticizing the method. I strongly believe Scrum has a place. However, I do believe Scrum is often applied too narrow mindedly. 

Thus, I want to briefly outline this agile development method here. I will also provide three extremely important things to keep in mind when using Scrum. In my view these three are paramount to ensuring the effectiveness of the framework. 

Let’s start with the basics, though.

Email address:

Leave this field empty if you're human:

The Scrum team

Scrum is a framework for modern product development (many only use it for product delivery – more on that later) with a small Scrum team at its core. It is an autonomous team that is responsible for consistently creating value. The team consists of three roles.

• Developers
• Scrum Master (SM)
• Product Owner (PO)

Developers

The Developers are the ones to actually build the product we need. Since the Scrum Team works independently, the Developers need to have a broad skill set in order to cover whatever needs to be achieved in a given business domain. 

Product Owner

The PO enables efficient and effective product development by defining the product, by defining what it is that the developers will build. This is a challenging role that requires specific skills, for me chiefly communication skills and empathy (technical skills don’t hurt either) and a deep understanding of the business.

Scrum Master

The skills of the SM are comparable to those of the PO. As the servant leader of the team, communication and empathy are also among the most important qualities of a Scrum Master. Additionally, the SM is the expert in agile development and the Scrum method. He or she helps the team in applying the agile principles and the framework. 

The Scrum events

Scrum includes a set of events, sometimes called ceremonies. 

The heartbeat of the framework is called the Sprint. This is a fixed period of time (generally less than a month) during which the team works on achieving a specified goal. 

At the start of the sprint, the team choses a set of user stories from a maintained, refined, and prioritized product backlog that it can realistically achieve during one sprint. Those are then implemented during the fixed period of time. The aim is for the team to create value for the users with each and every iteration, within each and every sprint.

During each sprint, the same four (or five) ceremonies take place regularly. I have expanded extensively on them and shared my best practices in separate articles. So, I won’t go into detail here.

• Sprint Planning for setting the goal of the sprint
• Daily Stand-Up for aligning, reviewing and adapting the approach
• Sprint Review for showing and getting feedback on what was built
• Sprint Retrospective for reflecting on approaches and collaboration
• (Refinement for getting the user stories ready for implementation – this is not part of the official Scrum Guide but I find it incredibly helpful) 

Things to keep in mind to ensure Scrum is effective

Now that we have covered the basics of the Scrum framework, I want to share three things to keep in mind. I strongly believe that many of the failed implementations of Scrum can be avoided with these best practices. They ensure that the method remains an effective implementation of agile product development. 

• Remain flexible
• Remember product discovery 
• Team set-up is as important as the Scrum method

Let’s go one by one.

Remain flexible

By itself, Scrum is a fairly rigid framework with clear rules. I believe that this is generally a good thing, as it gives particularly inexperienced teams very clear guidelines on how to effectively develop products. In my view though, it is imperative that we remain flexible – dare I say, agile – in adapting the framework to the team and the environment. 

Anecdotally, it seems anytime I hear about a bad experience in Scrum it is related to poor implementation, often too strict implementation. This is particularly true for mature, experienced teams. There is no need to apply the method to a t if the team is already constantly creating value with a Scrum light or Scrumban approach. 

Take an example of an experienced team that communicates very well amongst the members. Maybe they do it in such a way that the team is able to continuously address interpersonal issues and problems with processes or methods during the sprint whenever the issues arise. In this case, the need for a retrospective may decrease. It could then make sense to change the frequency of the retro to e.g. once every few sprints. You could also think about a longer retro once per quarter.

There are a million ways to go here. It depends heavily on the circumstances. As always, I find it better to be pragmatic, instead of dogmatic. And yes, Scrum can also work without a dedicated SM.

Remember product discovery

The Scrum Guide doesn’t mention anything about what type of work the team should be doing. It simply says that the team is responsible for creating value. In practice, this seems to often lead to teams focusing on product delivery and forgetting about product discovery (probably because delivery is less abstract than discovery). 

The PO then takes the needs and wants from sales, leadership, or other stakeholders and creates user stories based on those. The developers are then only there for implementing them. The team is a delivery team within a feature factory, instead of an empowered product team.

It’s imperative that the team conducts continuous product discovery. The responsibility for ensuring this happens falls onto the shoulders of the PO, who needs to put on his or her product manager hat. The team – including the engineers! – needs to regularly interact with users and customers and conduct experiments for improving the product. Only then is the team truly agile.  

Team set-up is as important as the Scrum method

I want to stress that Scrum is not the silver bullet. I enjoy employing the framework and have had great success with it. However, there are other factors that have a significant impact on success. One of them is equally (or more?) important as the method used, the set-up of the team. 

If you want to frequently deploy and rapidly iterate on a product, the team must have minimal dependencies to other teams. You can have the best implementation of the Scrum method, the best PO and SM, and star engineers. If you always need to wait for three other teams to do something before you can deploy an iteration you will have a difficult time building something great.

The team also needs to have or be willing to learn the cross-functional skills needed to build the desired product. In this context I want to mention the product designer. Besides PO and SM, the Scrum guide only mentions developers as part of the team, it doesn’t mention a product designer. Nevertheless, any team will benefit from having one to ensure that the user experience is such that it maximizes value for the users.

Happy Sprinting!

So, there you have it – Scrum in a nutshell. By embracing its principles with flexibility, applying it to both product discovery and delivery, and minimizing dependencies, you’ll be well on your way to a more efficient, self-managed team. 

As they say in the world of agile development: build, inspect, adapt, and continuously improve. Happy sprinting!

Coverimage by storyset on Freepik