Tag Archives: rules of scrum

A Group of Geographically Distributed Staff is NOT a Scrum Team

Learn more about transforming people, process and culture with the Real Agility Program

It’s my opinion, and I think the opinion of the authors of Scrum, that a Scrum team must be collocated. A collection of geographically distributed staff is NOT a Scrum team.

If you work in a “distributed team”, please consider the following question.

Do the members of this group have authority to decide (if they wanted to) to relocate and work in the same physical space?

  • If you answer “Yes” with regard to your coworkers: then I’d encourage you to advise your colleagues toward collocating, even if only as an experiment for a few Sprints, so they can decide for themselves whether to remain remote.
  • If you answer “No”, the members do not have authority to decide to relocate:
    • then clearly it is not a self-organizing team;
    • clearly there are others in the organization telling those members how to perform their work;
    • and clearly they have dependencies upon others who hold authority (probably budgets as well) which have imposed constraints upon communication between team members.
    • CLEARLY, THEREFORE, IT IS NOT A SCRUM TEAM.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Mishkin Berteig’s 13 Myths of Scrum

Learn more about transforming people, process and culture with the Real Agility Program

Mishkin Berteig dispels myths in some of the most challenging aspects of Scrum.

Have you been in a team where the ScrumMaster was also a Project Manager? Did you know that’s not really the role of a Scrum Master?

Or have you been participating in retrospectives which were public? Did you know they are not supposed to be?

The thirteen concepts addressed here bringing clarity and insight to Scrum Masters, Product Owners and team members.

These key principles of Scrum, when practiced regularly, improve the effectiveness of any team.

Learning a new way takes time but when the principles are clear it is easier to adopt them and implement them with focus and success.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Breaks Between Sprints Indicate a Problem

Learn more about transforming people, process and culture with the Real Agility Program

This post is a follow-up to an earlier article: There Are No Breaks Between Sprints.

Breaks between Sprints indicate a problem. Usually such breaks are filled with planning activities including research, requirements gathering, design & preparation, negotiations & approvals and the problem is threefold:

  1. Such plans are based on conjecture (risky and not compatible with Scrum) rather than empiricism (less risky and compatible with Scrum). Those activities are most beneficial when diligently performed by skilled inspectors at the point of the work. The four formal events within each Sprint provide the team and stakeholders adequate opportunity for inspection and ensure that decisions are being made in light of the up-to-date product increment and with respect to current user needs and market conditions.
  2. Breaks between Sprints often include activities which do not add value to the product or are entirely unrelated.
  3. Breaks between Sprints defer the delivery of value because the work performed does not result in potentially-releasable increment of “Done” product.

To correct this problem it is important to identify whether any of the effort spent between Sprints is adding value to the product — that is, which activities effect the form, fit, or function of the actual product. If determined to not be value adding, stop the activity entirely — it is waste. If determined to be value adding then the work ought to be part of their Sprints and the Scrum Team may decide that either the activity should be represented and ordered in the Product Backlog, or should be represented in the team’s Definition of Done.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Pitfall of Scrum: ScrumMaster as Contributor

Learn more about transforming people, process and culture with the Real Agility Program

The ScrumMaster is like a fire-fighter: it’s okay for them to be idle – just watching the team – waiting for an emergency obstacle. Taking on tasks tends to distract the ScrumMaster from the job of helping the team follow the rules of Scrum, from the job of vigorously removing obstacles, and from the job of protecting the team from interruptions. Let’s look at each of these aspects of the ScrumMaster role in turn:

The ScrumMaster Helps the Team Follow the Rules of Scrum

The ScrumMaster is a process facilitator. The Scrum process, while simple to describe, is not easy to do. As the Scrum Guide says:

Scrum is:

Lightweight

Simple to understand

Difficult to master

The ScrumMaster helps the Scrum Team and the organization to master the Scrum framework. Helping everyone understand Scrum and respect its rules is a first step. Some of the rules are particularly challenging. In some companies, being on time for meetings and ending them on time is hard. Scrum requires this. The ScrumMaster helps the team do this. In some companies, meeting deadlines, even short ones, is difficult. Scrum requires this every Sprint. The ScrumMaster helps the team do this. In some companies, giving time to improving things is hard. Scrum Teams do retrospectives. The ScrumMaster ensures that the team takes the time for this.

Of course, following the rules is hard for people. Even just the concept of “rules” is hard for some people. Everyone has the right to do whatever they want. Well, if you aren’t following the rules of Scrum you aren’t doing Scrum. So for some teams, just getting to the point of being willing to follow the rules of Scrum is a big step. The ScrumMaster needs to help with motivation.

The ScrumMaster is Vigorously Removing Obstacles

The Scrum Team is going to be working hard to meet a goal for the Sprint. As they work, they are going to work through many challenges and problems on their own. However, the team will start to encounter obstacles as well. These obstacles or impediments come from a few sources:

  1. Dependencies on other people or parts of the organization outside the Scrum Team.
  2. Skill gaps within the team.
  3. Burdensome bureaucracy imposed by the organization.
  4. Lack of resources such as tools, equipment, licenses, or even access to funds.

The ScrumMaster needs to work through these.

On a panel talk on Saturday one person said “the scrum master is an administrator, moving cards, updating the burn down. It is an easy job, I think my son could do it.” I then rebutted his remarks….

The ScrumMaster will tackle enterprise operations for their slow error prone deployment process, tackle Sarbox [Sarbanes-Oxley] compliance policy that has been way over-engineered to the point of slowing dev to a crawl, telling the PMO that 3 sets of reports is waste, exhorting the team to try to do unit tests in ABAP (SAP cobol), etc.

Robin Dymond, CST – (Scrum Training and Coaching Community Google Group, Sep. 23, 2009)

The ScrumMaster is Protecting the Team from Interruptions

Every organization seems to have more work than their staff have the capacity to deliver. Staff are often asked to task switch repeatedly over the course of a day or even in a single hour. Sometimes people are “allocated” to multiple projects simultaneously. This breaks the Scrum value of focus. The ScrumMaster needs to protect the team from interruptions or anything else that would break their focus.

But what should the Scrum Team members be focused on? Simply: the goal of a single Sprint. And a single Scrum Team is focused on a single product. The Product Owner should be the point of contact for any and all requests for the time and effort of a Scrum Team. The ScrumMaster needs to re-direct any interruptions to the Product Owner. The Product Owner decides if:

  • the interruption results in a new Product Backlog Item, OR
  • the interruption is irrelevant to the product and simply discarded, OR
  • the interruption is important enough to cancel the current Sprint.

There are no other options in Scrum for handling requests for work from the Scrum Team (or any member of the Scrum Team).

Contribution as Distraction for the ScrumMaster

Any time the ScrumMaster starts to contribute to the product development effort directly, the ScrumMaster is distracted from the other three duties. Although simple, following the rules of Scrum is not easy. Getting distracted from the duty of helping the team follow the rules of Scrum means that the team is likely to develop bad habits or regress to non-Scrum behaviour. Vigorously removing obstacles is usually a huge job all on its own. Most Scrum Teams have huge organizational obstacle that must be worked on. Some of these obstacles will take years of persistent effort to deal with. The ScrumMaster cannot become distracted by tactical details of product development. Protecting the team from interruptions means the ScrumMaster must have broad awareness, at all times, of what is happening with the team. If a team member is interrupted by a phone call, an email, or someone walking into the Scrum team room, the ScrumMaster needs to notice it immediately.

Whenever a ScrumMaster takes on a product development task, focus on the role is lost and a condition of a simple conflict-of-interest is created. If the team has “committed” to deliver certain Product Backlog Items at the end of a Sprint, then that feeling of commitment may lead a ScrumMaster to focusing on the wrong things.

The time of a ScrumMaster is an investment in continuous improvement. Letting a ScrumMaster contribute to the work of the team dilutes that investment.

This article is a follow-up article to the 24 Common Scrum Pitfalls written back in 2011.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Scrum Study Guide updated with tools for new ScrumMasters

Learn more about transforming people, process and culture with the Real Agility Program

We’ve updated the Scrum Study Guide and lowered the price!  The Scrum Study Guide is an editable tool for helping ScrumMasters do their jobs.  It is like a personal assistant that helps you:

  • Keep track of the rules of Scrum
  • Find tons of concise how-to guides for common steps and activities in doing Scrum
  • Keep structured notes or a journal on your job as the ScrumMaster
  • Maintain a list of online reference material
  • Assess the progress of your team
  • Organize the obstacles you are working on
  • Modify and update the Scrum reference material based on how you are actually doing Scrum
  • Look up answers to the problems you’re having with your organization
  • Plus, every time we update content, pictures, tools, and best practices, you get the updates for free for the rest of your life!

    www.scrumstudyguide.com

    Are you one of the many satisfied Scrum Study Guide customers?  Tell us how it is working for you.


    Please share!
    Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail