Scrum is the most popular framework used within an agile environment to convert complex problems into valuable products and services. In this blog, we will examine all things Scrum to shed light on this wonderful organizational tool that is sweeping the globe. There will be engaging articles, interviews with experts and Q&A's. Are you ready to take the red pill? Then please join me on a fascinating journey down the rabbit hole, and into the world of Scrum.

About this Blog


Recent Posts

3 Signs that your Scrum Team needs a Tune-Up

Great Job. Now you're fired!

3 Signs that your Scrum Team needs a Tune-Up

At the heart of every great Agile project that uses Scrum, is the Scrum Team. These are small but competent groups of individuals packed with all the skills and experience necessary to produce valuable products and services.

The Development Team is the nucleus of the Scrum Team; anywhere from 3 to 9 people who are collectively responsible for each feature and increment they produce. Unlike almost any other kind of team we are familiar with, the individuals that make up the Development Team have no title, no rank, and no specialization exclusivity.

Revolving around the Development Team is the Product Owner and Scrum Master. These three entities form the Scrum Team as a whole. It is the expectation of most projects that the Scrum Team will work productively, consistently and harmoniously. However, this is not always the case.

Let's take a look at 3 warning signs that the Scrum Team needs a tune-up, and some questions that may be asked to help identify the cause.

  1. Reduced Velocity / Increased Lead Time
    Velocity is the amount of work capacity the team can produce every iteration or Sprint. Lead time is the amount of time it takes for an entire process between two defined points, say from Backlog entry to acceptance by the Product Owner. Both velocity and lead time are separate measurements, but closely related. For example, a reduced velocity is likely to accompany increased lead time. When measuring the team's past performance, a sudden reduction in velocity or increase in lead time should be a cause for concern.

    Are there any blockers preventing the team from working at their previous work rate? Does the team have all the tools and knowledge to convert user stories into features? Is the Product Owner giving clear information regarding the items in the Backlog, and prioritizing them in such a way as to optimize the Development Team's work? Is the Scrum Master ensuring that the team is not distracted by external factors, including stakeholder requests?
  2. Bad Apple
    Sometimes a member of the team doesn't fall into line with Scrum's 5 values, especially regarding commitment, focus and respect. In order for any team to function effectively, all members need to commit to their shared goals, focus on the work at hand, and respect each other throughout the project. When one team member becomes the black sheep of the family, it's time to start examining some possible reasons for the behavior.

    Does the team member fully support Scrum? Can the Scrum Master provide any assistance to the team member if the latter does not fully support or understand the Scrum framework with its rules, roles, values, principles, artifacts and events? Did the team member have more authority in their previous role and now finding it difficult to be an equal team member? Is there some kind of conflict between the team member and others within the team? Do they feel appreciated and included at the same level as other team members? Are there any private issues that require attention? Remember stress, fear and depression can be serious conditions that should not be taken lightly. These and many other possible causes need to be investigated before the bad apple infects the rest of the apple tree.
  3. No Show
    The no show Product Owner or Scrum Master is someone who doesn't show up either physically in person, or via other communication methods such as email or phone call. Sometimes the Development Team need input such as Backlog item clarification from the Product Owner, or obstacles removed by the Scrum Master. These issues can manifest themselves several times a day, and a no-show member of the Scrum Team can delay incremental delivery.

    Is the Product Owner and Scrum Master spread too thinly between teams or other responsibilities? Are they committed to the Scrum Team? Did they sign off on the Sprint Goal? Does the Product Owner have true authority over the Product Backlog and is he/she in sync with what the stakeholders need? Is the Scrum Master following Scrum strictly or haphazardly? Is the organization truly adopting Agile/Scrum?

I have only listed 3 signs that a Scrum Team needs close attention, but there are many others. Can you think of any? I would love to hear about your experiences with a Scrum or any Agile team that started to go astray, and was in dire need of a Scrum Mechanic to step in and give the engine a tune up.

Schwaber, K. and Sutherland, J. (2017) The Scrum Guide. Available from:
Griffiths, M. (2015) PMI-ACP Exam Prep. RMC Publications, Inc.

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can also be Scrumptious!
Sante Vergini Signature


Posted on: February 10, 2018 05:18 AM | Permalink | Comments (17)

Great Job. Now you're fired!

It is always great to see successful Agile projects come to fruition. When the project is done, team members disband and move on to the next project. Sometimes, before a project has even ended, we lose some members of the team for various reasons such as quitting their job, going on holiday, or being fired for poor performance. So how do we wrap our heads around the fact that some project team members will be pushed out of their roles, even before the project is done, simply because they are doing a fantastic job?

Welcome to the world of the Scrum Master. As an essential member of the Scrum Team, the Scrum Master acts as a servant-leader to the whole team, and coaches the organization in its Scrum adoption. According to the Scrum Guide, they are specifically tasked with:

  • coaching the Dev Team to self-organize and be cross-functional
  • assisting the Dev Team to create high-value products
  • removing the blockers that prevent the Dev Team's progress
  • facilitating Scrum events as needed
  • influencing organizational change to increase Dev Team's productivity

This doesn't include the myriad of other tasks associated with assisting the Product Owner, and the wider organization. In general, The Scrum Master is there to ensure that the roles, events, artifacts and rules that make Scrum what it is, are followed as strictly as possible. This results in the optimal implementation of Scrum, and raises the likelihood of success.

So when the sprint is running smoothly, or more specifically, when the Development Team follow the rules, understand their role, produce transparent and clear artifacts, and actively participate in all events (within the prescribed time boxes), what is there left for the Scrum Master to do?

Well, not terribly much...within the Team. The very essence of Scrum is a small, high performing, self-organizing, cross functional team that consistently produces valuable products. When the team approaches this pinnacle, the Scrum Master is effectively redundant.

Regardless of whether or not an organization is new to the Agile way of doing things, or has some experience behind them, teams will vary from project to project, department to department, and company to company. One team may be the jewel in the Agile crown for an organization, consistently performing at a high level while adhering to the fundamental values and principles of Scrum. On the other hand, other teams may be lagging behind, slower to adopt Scrum, or not have the optimal dynamics in place between the Development Team, Product Owner, Scrum Master, stakeholders and the wider organization. These teams will need further coaching and facilitation. Also, new Agile projects will come along, with new teams, or new members of existing teams, and the cycle of the Scrum Master will begin all over again.

Outside the team, it is a different ball game. This is where I believe a Scrum Master or Coach is needed no matter how successful or pervasive Agile and Scrum is within the organization. Employees, middle and senior managers, and executives that are not dealing with Agile on a daily basis, sometimes forget that it is still around and they can often fall back into their old ways. The Scrum Master can refresh their memory and assist the organization to keep on track with their Agile initiatives.

In fact, metrics should be put in place to ensure that the organization's Agile maturity extends beyond the Scrum Team to the rest of the organization. Whether this is performed by a Scrum Master or Scrum Coach (sometimes they are the same person depending on the size of the project and organization), one thing is for sure: letting go of the Scrum experts could be a case of cutting one's nose off to spite one's face.

So hopefully we might hear a different response to the Scrum Master's fantastic work: "Great job. Now you're re-hired!"

Schwaber, K. and Sutherland, J. (2017) The Scrum Guide. Available from:

Thank you for your interest in the Scrumptious blog. If you have any ideas for Scrum topics, please message me here. Until next time, remember, projects can be Scrumptious!
Sante Vergini Signature




Posted on: January 31, 2018 06:06 AM | Permalink | Comments (9)