Scrum

Understanding Scrum in Project Management

Scrum was first introduced as a term by Hirotaka Takeuchi and Ikujiro Nonaka in 1986 in their article the “New New Product Development Game” in the Harvard Business Review.  In the early 90's it was further developed into a framework by Ken Schwaber with Jeff Sutherland to help organizations struggling with complex complex development projects.

Like many agile methodologies, Scrum was designed in response to the need to have more rapid delivery and provide more flexibility than traditional, sequential (waterfall) project methodologies allowed.  Like its namesake, the ‘scrum’ in the game Rugby, the framework focuses on tight collaboration between cross-functional team members in short, incremental bursts of activity and builds teamwork by encouraging (among other things) co-location and self-organising teams.  

What is Scrum?

The 2020 Scrum Guide states that “Scrum is simple" and, importantly, that the “Scrum framework is deliberately incomplete”.  Scrum is based on an empirical approach to project management where not everything is known upfront.  Instead, the project team will learn and adapt through collective observation and experience to deliver value over time.  

In large, complex projects where changes to requirements or other variables are likely, Scrum significantly reduces risk of failure through an iterative planning approach as part of a holistic product strategy.  This is certainly most relevant to software projects (see the CHAOS Report 2015 by the Standish Group to illustrate this point - page 7) however due to its flexibility, Scrum has been widely adopted and used for all kinds of initiatives.  There is a risk in adopting Scrum too readily however and it is important to recognise the key roles within Scrum that are necessary.  Scrum may be a deliberately lightweight and flexible framework however that does not mean it does just anyone can pick it up and run with it.  A Scrum Master is key to ensuring project team members can be supported and coached to achieve value and adhere to the core processes within the framework.

In Jexo's Project Management Glossary video series, you can find detailed explanations of the most common Project Management terms, along with tips on how to use them and clear examples 👇

The Scrum Master

The facilitator of  Scrum in the team is the Scrum Master who ensures that all agile practices are being followed by team members however also allows flexibility for the project team to adapt and utilises coaching to improve the way the team works.  The Scrum Guide refers to this kind of approach as ‘servant leadership’ where the Scrum Master does not rely on hierarchical authority to drive outcomes but instead promotes collaboration and innovation from the team itself.  

On page 3 of the 2020 Scrum Guide, the simplicity of the environment a Scrum Master should foster is defined in 4 steps:

1. A Product Owner orders the work for a complex problem into a Product Backlog.
2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat

Of course the Scum Guide has a lot more detail than that on the key processes that need to be managed.  It is important to understand all the key Scrum ceremonies that knit the work and the team together but be careful to not over engineer these.  Remember the term lightweight and ensure time is spent on tasks not in group sessions talking about them.  

One of the most important roles of the Scrum Master is to facilitate ceremonies to ensure only those involved are called upon to contribute.

Question: In a bacon-and-egg breakfast, what’s the difference between the Chicken and the Pig?

Answer: The Chicken is involved, but the Pig is committed!

The Chicken and the Pig riddle is one way a Scrum Master can manage an efficient Scrum ceremony.  Only those committed to the project cause can have a say.

Scrum pillars, Scrum values and how to avoid the most common pitfalls

As mentioned, Scrum is based on empiricism as a philosophy.  It also uses Lean concepts to reduce waste in processes and focus only on the essentials.  This is far easier said than done and it takes time to truly make this not only work but continually evolve across an entire organisation.  Benefits of Scrum come through understanding of the three Scrum pillars of transparency, inspection and adaptation.  

Transparency

Transparency fundamentally relies on the ability of a team to access and understand information as well as be aligned on a common goal or vision.  Scrum relies on clear communication flows between team members and teams to solve problems and foster collaboration.  However Scrum does not, in its own right, ensure an organisation is set up this way.  A common risk with Scrum is that legacy ways of working or non-Agile functions such as legal and compliance are not able to align to the processes and will need to work in their own way.  This can obscure dependant tasks and reduce the transparency needed for Scrum to be fully effective.

Inspection

Inspection will only be possible if transparency is well established and the right values exist in the team.  

The 5 Scrum values are:

• Commitment,
• Focus,
• Openness,
• Respect,
• Courage.

These values are critical to the inspection process and act as a constant mantra a team can use to direct work and behaviour.  The risk of any inspection process is that it is critical without being constructive and all it serves to do is put recipients offside.  Most importantly the project team has to respect failure as an outcome of an inspection process.  Should something not be working or resulting in poor outcomes, the project team has the ability to rapidly assess it as a failure.  Failing fast and minimising the impacts of a failure so that resources can be immediately diverted into the new approach is as critical as any experience the project team can learn from.

Adaptation

Adaptation means, just like with inspection, that the team needs to be open to the need to change.  With every review process such as daily stand-ups or sprint retrospectives, the project team needs to inspect, learn and adapt to the changes identified whether they be internal to the team or external (such as new features in a competing product).  In many organisations the Scrum Master and Scrum Team will attempt to adapt and change however it is important to look out for incentives that that reward individual instead of team achievement.  For example an individual team member may be highly productive to meet performance KPIs however their selfish pursuit of individual goals can end up working against team productivity.

Final words

Scrum promises a lot but is not meant to work in every scenario.  It is important to check your organisation can adopt the enterprise ways of working that best support Scrum otherwise many of its benefits will not be fully realised.  The very nature of Scrum is to be as lightweight as possible to begin with and constantly iterate the approach to become more successful over time.  So don’t take the fully evolved Scrum playbook and implement it or you will lose the benefit of experience your teams will need to not only get outcomes from Scrum but to enjoy it.

Scrum FAQs