The Scrum Myths videos have been popular and I’m very happy with people’s comments about the videos. I’m going to be making an even more extensive new series for publication in just a few weeks.
Unbeknownst to me, the videographer, my brother Alexei Berteig, created a bloopers video from some of the many, many, many, MANY mistakes I made while making the videos. I hope you will watch it…. but I strongly recommend taking a look at one or two of the “good” videos first. Try these:
After a recent large organizational change that resulted in a number of new teams formed, a product owner (PO) approached me looking for some help. He said, “I don’t think my new Scrum Master is doing their job and I’m now carrying the entire team, do we have a job description we can look at?”
I can already imagine how a version of me from a previous life would have responded, “yes of course let’s look at the job description and see where the SM is falling short of their roles and responsibilities”. But as I considered my response, my first thought was that focusing our attention on roles and job descriptions was a doomed route to failure. Pouring our energy there would likely just extend the pain the PO, and likely SM, were going through.
Sure we have an SM job description in our organization, and it clearly documents how the SM provides service to the organization, team and PO. But reviewing this with the seasoned SM didn’t really make sense to me; they were very well aware of the content of the job description and what was expected of them.
At the same time that this was happening, another newly paired Scrum Master asked for my help regarding their PO. From their perspective the PO was “suffocating” the team. The PO was directing the team in many aspects of the sprint that they felt was stepping beyond their role. “I don’t think the PO knows their role, maybe you can help me get them some training?” was the SMs concluding comment.
Over the course of the next few weeks this scenario played out again through more POs and SMs sharing similar challenges. Surely this was not a sudden epidemic of previously performing individuals who now needed to be reminded of what their job was?
Recognizing the impact of change
A common pattern was emerging from all of this, change was occurring and each individual was relying on, and to some degree expecting, old patterns to continue to work with their new situation. Their old way of working in Scrum seemed to work very well; so it was everyone else around them that was not meeting expectations.
The core issue however was that change was not being fully confronted: the product was different, the team competencies were different, the stakeholders were different, the expectations were different and finally the team dynamic was different all the way down to the relationship between the SM and PO.
Scrum as a form of Change Management
I looked for the solution from Scrum itself, at its heart a method for teams to use to adapt to and thrive with change. Was there enough transparency, inspection and adaptation going on between the SMs and POs in these situations? I would argue, not enough.
A pattern was becoming clear: nobody was fully disclosing their challenges to the other, they hadn’t fully confronted and understood their new situation and hadn’t come up with new approaches that would improve things. Said another way, they hadn’t inspected their new circumstances sufficiently and transparently enough so that they could adapt their role to fit the new need.
One thing that many successful SMs and POs recognize is that they are both leaders dependent on each other, and for their teams to be successful they need to figure out how they will work together in partnership. It doesn’t matter whether the terms of that partnership gets hashed out over a few chats over coffee or through a facilitated chartering workshop. What matters is clarity around how you agree to work together as partners meeting some shared goal.
As an SM or PO, here are some sample questions whose answers you may wish to understand and align on:
Do we both understand and support the team’s mission and goals?
What are the product goals?
How can we best help the team achieve those goals?
Are there any conflicts between the team and product goals?
When our goals or methods are in conflict, how will we resolve them?
In what ways will I be supporting your success as an SM/PO?
How will we keep each other informed and engaged?
Should we have a peer/subordinate/other relationship?
So if you are an SM or PO, and it’s unclear to you on the answers to some of these questions, you may just want to tap your leadership partner on the shoulder and say “let’s talk”.
[EDITOR’S NOTE: Martin Aziz is a first-time contributor to Agile Advice – please welcome him in the comments. And let us know if you are interested in contributing.]
When my Scrum team first proposed trying mobbing I wasn’t sure what to expect. No one on the team (including myself) was an expert. I reserved judgment and watched a few sprints. I stayed silent when the same team decided to skip the tasking out portion of planning and simply pulled in enough stories to fulfill their Sprint goal.
After a couple of sprints it became obvious that there were a number of pros; the team was engaged and aligned. They responded as a consistent, unified voice at Sprint Review and Retro. Planning went a lot faster as the team no longer wrote out all their tasks and didn’t have to copy all of them into Jira.
In particular, the Daily Standup’s usual agenda of “what did you do yesterday? what are you doing today? what are you doing tomorrow?” became redundant. And this had me thinking; ‘maybe the team didn’t need a stand up anymore? What’s the point?”
Then, one of the team members introduced me to the concept of the daily goal and I watched as he walked the team thru it. I thought this made a lot of sense and so did the team. We kept up the practice. Some days the team would forget about it or be too tired to bother. I noticed on those days the team wouldn’t be as clear on what they were working on or how to align on a particular challenge. I also noticed that the Stand Up the next day would be more fragmented and meander a bit. They would forget to communicate to one another and look at me as their Scrum Master expectedly, wanting me to drive it.
I started to coach the team back to their daily goal practice and reminded them this Stand Up was for them to align on the work ahead for the day. This became more important as the team divided up into mini mobs or pairs and were no longer one big mob.
I find the Daily Goal useful for a number of reasons. Instead of tasking out the work a week in advance, they decide how to approach the work on a daily basis that takes into account any day to day changes that have happened. Planning goes a lot faster now that we’re not tasking out all the work in advance. The team stays focused on a daily basis as opposed to at just Planning. They write their daily goal on their Scrum Board making it visible to anyone on the floor what their focus is for the day. Even better, the daily stand up as renewed purpose and the dialogue is more interactive.
Here are some examples of our Daily Goals:
Refactor Story 1
Coordinate with outside team members to align on test strategy
Complete happy path for Story 3
And sometimes it is as simple as “Complete story 4”
I hope to continue the practice and frankly, it’s fun! Achieving short time goals is motivating and brings a sense of accomplishment. I highly recommend it. Let me know your thoughts and if you’re trying this technique let me know how it’s working out for your team.
[EDITOR’S NOTE: Alexandra Dragon is a first-time contributor to Agile Advice – please welcome her in the comments. And let us know if you are interested in contributing.]
On many occasions, I have observed “Scrum Masters” and even “Product Owners” attempting to drive what they understand to be the Daily Scrum. Just this morning, I witnessed a “Daily Scrum” in which a “Product Owner” gave the team a bunch of program updates and made sure that each team member had tasks to work on for the day. Then, the PO “wrapped up” the meeting and left the team to get to the work. I then stayed and observed what the team did next. They actually stayed together to discuss the work and figure out how they were going to organize themselves for the day. I then went over to the Product Owner and whispered in her ear that the team was now doing the real Daily Scrum. She said “Oh,” and promptly walked over to find out what was going on. I then observed her from a distance nodding her head several times while appearing to understand what the team was talking about. I’m not sure if she understood or not, but that’s irrelevant. The point is that the Daily Scrum is for the Development Team to inspect and adapt its progress towards the Sprint Goal and decide how it will self-organize for the coming day. If the Development Team decides as a result of the Daily Scrum that it needs to re-negotiate any previously forcasted functionality with the Product Owner, then that conversation can certainly happen at that time.
Agile methods such as Scrum, Kanban and OpenAgile do not require long-term up-front plans. However, many teams desire a long-term plan. This can be thought of as a roadmap or schedule or a release plan. Agile planning helps us build and maintain long-term plans.
Agile Planning Process
The steps to do this are actually very simple:
Write down all the work to be done. In Scrum these are called “Product Backlog Items”, in Kanban “Tasks” and in OpenAgile “Value Drivers”.
Do some estimation of the work items. Many Agile estimation techniques exist including Planning Poker, The Bucket System, Dot Voting, T-Shirt Sizes. These tools can be applied to many types of estimation. There are three kinds of estimation that are important for Agile Planning:
Estimating relative business value. Usually done with the business people including customers and users.
Estimating relative effort. Usually done by the Agile team that will deliver the work.
Estimating team capacity. Also done by the Agile team (this is sometimes called “velocity”).
Create the long-term plan. Use the team capacity estimate and the sum of all the effort estimates to come up with an estimate of the overall time required to do the work. (In Kanban, which doesn’t have an iterative approach, this is a bit more complicated.) Use the business value and effort estimates to determine relative return on investment as a way to put work items in a logical sequence.
Agile planning allows a team to update estimates at any time. Therefore, the techniques used above should not be thought of as a strict sequence. Instead, as the team and the business people learn, the estimates and long-term plan can be easily updated. Scrum refers to this ongoing process at “Product Backlog Refinement”.
Principles of Agile Planning
In order to use Agile planning effectively, people must be aware of and support the principles of Agile planning:
Speed over accuracy. We don’t want to waste time on planning! Planning in and of itself does not deliver value. Instead, get planning done fast and use the actual delivery of your Agile team to adjust plans as you go.
Collaborative techniques. We don’t want to be able to blame individuals if something goes wrong. Instead, we create safe estimation and planning techniques. Inevitably, when an estimate turns out to be wrong, it is impossible to blame a single individual for a “mistake”.
Relative units. We don’t try to estimate and plan based on “real” units such as dollars or hours. Instead, we use ordering, relative estimation and other relative techniques to compare between options. Humans are bad at estimating in absolute units. We are much better at relative estimation and planning.
The team decides on how much work it will do in a Sprint. No one should bring pressure on the team to over-commit. This simply builds resentment, distrust and encourages low-quality work. That said, of course teams can be inspired by challenging overall project or product goals. A stretch goal for a Sprint is just a way to 100% guarantee failure. Even the team should not set its own stretch goals.
There are a few interesting principles that apply here. For example, the Agile Manifesto mentions sustainability:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
The Agile Manifesto also points out the importance of trust:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Stretch goals are incompatible with both of these principles from the Agile Manifesto.
There are two types of stretch goals. The first type are those assigned by outsiders to the team. The second type are those which a team sets for itself. Both types are bad.
Stretch Goals Assigned by Outsiders
The worst extreme of this type of stretch goal is also the most common! This is the fixed-scope-fixed-date project deadline. In this type of stretch goal, the project team, doing Scrum or not, is forced to work backwards from the deadline to figure out how to get the work done. If the team can’t figure this out, managers often say things like “re-estimate” or “just get it done.” (Note: another thing that managers do in this situation is even worse: adding people to the project! Check out “The Mythical Man-Month” by F. Brooks for a great analysis of this problem.)
My anecdotal experience with this sort of thing is simple: quality suffers or sustainability suffers. I once worked with three other people on a mission critical project to help two banks with their merger. There was a regulatory deadline for completing the integration of the two existing systems for things like trading, etc. Fixed-scope-fixed-date. Coffee and sleepless nights were our solution since we tried not to sacrifice quality. We actually ended up working in my home for the last few 24-hour stretches so that we would have access to a shower. Suffice it to say, there’s no way we could have sustained that pace. It’s anti-Agile.
A quick search for ideas and opinions about stretch goals makes it very clear that there is no commonly agreed “correct” answer. However, from an Agile perspective stretch goals assigned by outsiders are clearly against the principles of the Agile Manifesto.
The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.
For emphasis: what it can accomplish – not what it (the Development Team) wants to accomplish, or what it should accomplish, or what it could accomplish if everything goes perfectly. A Development Team should be accomplishing their Sprint plan successfully (all Product Backlog Items done) on a regular basis. Of course, exceptional circumstances may intervene from time to time, but the team should be building trust with stakeholders. Here’s another story:
I had a good friend. We would always go out for coffee together. We just hung out – chatted about life, projects, relationships. Of course, from time-to-time one or the other of us would cancel our plans. That’s just life too. But there came a time when my friend started cancelling more often than not. There was always a good excuse: I’m sick, unexpected visitors, work emergency, whatever. After a little while of this I started to think that cancelling would be the default. I even got to the point where I was making alternative plans even if my friend and I had plans. I got to the point where I no longer trusted my friend. It didn’t matter that the excuses were always good. Trust was broken.
It doesn’t matter why a team fails to meet a goal. It reduces trust. It doesn’t matter why a team succeeds in meeting a goal. It builds trust. Even among team members. A team setting stretch goals is setting itself up for regular failure. Even if the team doesn’t share those stretch goals with outsiders.
Stretch goals destroy trust within the team.
Think about that. When a team fails to meet its own stretch goal, team members will start to look for someone to blame. People look for explanations, for stories. The team will create its own narrative about why a stretch goal was missed. If it happens over and over, that narrative will start to become doubt about the team’s own capacity either by pin-pointing an individual or in a gestalt team sense.
Trust and Agility
The importance of trust cannot be over-stated. In order for individuals to work effectively together, they must trust each other. How much trust? Well, the Agile Manifesto directly addresses trust:
Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
Here is my recent YouTube video about stretch goals… check it out and subscribe to our channel!
The Product Owner is a full member of the Scrum Team and should be present at all Scrum meetings (Sprint Planning, Daily Scrums, Sprint Review and Sprint Retrospective). As well, the Product Owner should also be available during work time. Of course, the PO also needs to work with stakeholders and might be away during that time, but these discussions should be scheduled outside of the team’s meeting times.
In one case with a team I was coaching at Capital One, the Product Owner didn’t show up for the Sprint Review and then didn’t show up for the Sprint Planning meeting. The rest of the team decided to delay the start of the Sprint until the Product Owner did show up. The director-level manager of the team, a deeply insightful individual, insisted that all team members take paid days off until the Product Owner was ready to attend the Sprint Review… kind of like a mini-strike. It only took two days for the Product Owner to clear his schedule to attend the Sprint Planning meeting.
Product Owner as Scrum Team Member
The Scrum Guide defines the membership of the Scrum Team as follows:
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team…. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
As a member of the Scrum Team, the product owner should have the same level of commitment, courage, focus, openness, and respect (the five Scrum values) as any other Scrum Team member. The Product Owner needs to collaborate actively with the Scrum Team. One way to gauge the involvement of the Product Owner is in the Sprint Review. If the Product Owner is giving feedback to the rest of the Team in the Sprint Review, it’s too late! The Product Owner should never be surprised by the product increment shown in the Sprint Review. Instead, the Product Owner should be leading the discussion to get feedback from customers, users and other stakeholders during the Sprint Review.
Being Away from the Team
There are some interesting exceptions to the Product Owner being present. Here are some of the most common:
The Product Owner needs to be away from the team to work directly with customers, users, sales teams, marketing, customer service people, etc. This work is essential for making sure that the Product Backlog contains the most up-to-date information every Sprint. This time away should normally be scheduled outside of the Scrum meeting times.
The Product Owner may need to travel to meet with customers and be away from the Scrum Team for an extended period of time.
Of course, like any other team member, the Product Owner can and should take vacation and may be ill from time-to-time. This may seem trivially obvious. What is not obvious is that it often helps the team to leave another team member with temporary responsibility to fill in for the Product Owner. This temporary fill-in should not be someone from outside the team.
Special Case: The Daily Scrum Meeting
The latest version of the Scrum Guide also puts the Daily Scrum meeting in a special category. The meeting is for the Development Team (the subset of the Scrum Team that excludes the ScrumMaster and the Product Owner). Former versions of the Scrum Guide and other official Scrum documentation have changed this rule in various ways. As a personal comment, I believe this is a serious internal contradiction in the definition of Scrum. If the Scrum Team is self-organizing, then the Daily Scrum should include the ScrumMaster and Product Owner. I have seen this work successfully. The Scrum Guide says nothing about other people observing the Daily Scrum. I strongly recommend that the ScrumMaster and Product Owner observe the meeting even if you wish to follow Scrum strictly and restrict their participation.
If you decide to allow the Product Owner to participate in the meeting, then the Product Owner should restrict their comments to changes in the Product Backlog that require the team’s help for refinement. For example, the Product Owner could report in the Daily Scrum as follows:
“Yesterday I met with Sanjay at Deal Maker Industries and he suggested that we add a feature to allow car manufacturers to ping various stakeholders about risks and options. I think that will mean adding several new user stories to the Product Backlog. I need help from the team to write and estimate the new PBIs. Today I also have a re-prioritization meeting with three key internal stakeholders. My only obstacle is that I still can’t get a meeting with Karen about the marketing of the features from our last few Sprints and I’m worried that will delay our next release.”
In this example, the team and the ScrumMaster are kept apprised of key developments at the product level and know that there will be some extra work during the day to work on Product Backlog Refinement. The Scrum Guide says:
Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised. The Scrum Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Development Team. However, Product Backlog items can be updated at any time by the Product Owner or at the Product Owner’s discretion.
Balance in the Product Owner Role
Ideally, the Product Owner would spend an equal amount of time with their Scrum Team and with outside customers and users. The Product Owner is the key conduit of information from the market to the Development Team. Not being present with the Scrum Team can hinder this flow of information and cause quality problems and unnecessary rework. Again, the Product Owner should never be surprised in the Sprint Review.
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:
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:
Dependencies on other people or parts of the organization outside the Scrum Team.
Skill gaps within the team.
Burdensome bureaucracy imposed by the organization.
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.
Although a cancelled Sprint is rare, it can be tempting to try and wait until everything is “perfect” or “ready” before re-starting. Teams should immediately re-start after cancelling a Sprint. One team I heard of was doing two week Sprints, cancelled due to a major tool problem, and then waited three months for the vendor to fix the problem before going back to Sprinting. Instead, they should have used their creative problem-solving skills to find a way to continue delivering value and restarted their Sprints immediately.
The Scrum Guide puts Sprint cancellation under the authority of the Product Owner:
A Sprint can be cancelled before the Sprint time-box is over. Only the Product Owner has the authority to cancel the Sprint, although he or she may do so under influence from the stakeholders, the Development Team, or the Scrum Master.
It is important to note that older descriptions of Scrum will sometimes mention that the ScrumMaster or the Development Team can also cancel a Sprint. This is no longer part of the core definition of Scrum.
Cancelled Sprint Emotions
A cancelled Sprint can sometimes be emotionally challenging for a Scrum Team. There are three reasons for this difficulty:
Cancelling a Sprint, particularly later on in the timebox means there’s a lot of work already in progress (and possibly done). The psychology of sunk costs comes into play: we’ve invested some much in the Sprint so far, let’s just keep going to see if we can “fix” it. Going against that impulse can be very difficult.
A cancelled Sprint is an acknowledgement that the fundamental direction of the current Sprint is no longer the right thing to be doing. This can seem to be an insult to the team: why didn’t “you” get it right earlier? If there are certain people on the team who advocated strongly for the current set of work, they could take Sprint cancellation particularly hard.
Cancelling a Sprint may require undoing technical work and may be complex. If team members have made changes that they are particularly proud of, they may resist undoing that work more than would be called for simply due to the time involved in undoing it.
Once people experience these emotional effects from a cancelled Sprint, they will want to be cautious to avoid them re-occuring. That sense of caution will lead people to make arguments to the effect of “let’s make sure when we start our next Sprint that we have everything right” or simply, “I don’t want to go through that again… we better get it right this time around.” In order for the ScrumMaster to avoid falling for these arguments, it is important for the ScrumMaster not to be a hands-on contributor to the work. In other words, to be emotionally detached from the work. Those arguments can be persuasive unless the ScrumMaster can remind the team about empiricism. The ScrumMaster must always support the Product Owner if the product owner believes that a cancelled Sprint will lead to the best business outcomes.
Scrum is an empirical process that allows for “failure”. Of course, it probably helps to not call it that. Instead, a Scrum Team and the organization around it need to think of every Sprint as an experiment. There’s a good analogy here with the various stages of drug trials. When a company wants to research a new drug, the drug will go through various stages of experiments. The early stages of research are based on chemical reactions in the proverbial test tubes – laboratory experiments. Subsequent stages of research are often based on animal experiments. After that come human trials. At any stage if the drug in question is showing adverse effects outweighing the therapeutic effects, then the current stage is cancelled. Of course, the research done to that point is not a waste, but nor does it immediately result in a useful drug with net therapeutic effects. In Scrum, each Sprint is like a stage in the drug trials. If the work of the Sprint will not result in a net benefit, it only makes sense to cancel the work as soon as that information becomes obvious.
Waiting for Perfection
The pitfall, then, is that after a cancelled Sprint a team will feel pressure to wait until conditions are perfect before continuing on the next Sprint. Scrum does allow for the team to do a bit of a review of the reasons that the Sprint was cancelled, perhaps even to do a retrospective, and then start another Sprint planning meeting. The Sprint Planning meeting might be a bit longer than usual. The ScrumMaster does need to be sensitive to the needs of the team.
Cancelled Sprints and Synchronized Teams
One other factor may be a consideration: if the team is working with other teams on a larger-scale effort, there may be pressure to have all the teams with synchronized Sprints. For example, the Scaled Agile Framework emphasizes cadence and synchronization among multiple Scrum teams. In this case, a cancelled Sprint may mean that a team sits idle for a short time while they wait for the next synchronization point, as illustrated:
Even though the concept of self-organizing teams has been around for a long time, still some people think that a project manager or team lead should be assigning tasks to team members. Don’t do this!!! It is better to wait for someone to step up than to “take over” and start assigning tasks.
Assigning tasks can be overt or subtle. Therefore, avoid even suggestions that could be taken as assigning tasks. For example, no one should ever tell a Scrum Team member “hey! You’re not doing any work – go take a task!” (overt) or “This task really needs to get done – why don’t you do it?” (semi-overt) or “Would you consider working on this with me?” (subtle). Instead, any reference to tasks should be to the team at large. For example it would be okay for a team member to say “I’m working on this and I would like some help – would anyone help me?”
In the Scrum Guide, a partial definition of self-organizing is given:
Scrum Teams are self-organizing….. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
A more formal definition of the concept of “self-organizing” can be found here:
Self-organisation is a process where some form of global order or coordination arises out of the local interactions between the components of an initially disordered system. This process is spontaneous: it is not directed or controlled by any agent or subsystem inside or outside of the system; however, the laws followed by the process and its initial conditions may have been chosen or caused by an agent.
The key here is that there is no single point of authority, even temporarily, in a self-organizing team. Every individual member of the team volunteers for tasks within the framework of “the laws followed by the process” – namely Scrum. Scrum does define some constraints on individual behaviour, particularly for the Product Owner and the ScrumMaster. People in those two roles have specific duties which usually prevent them from being able to volunteer for any task. But all the other team members (the Development Team) have complete freedom to individually and collectively figure out how they will do the work at hand.
What If One Person Isn’t Working?
People who are managers are often worried about this. What if there is one person on the team who just doesn’t seem to be doing any work? Isn’t assigning tasks to this person a good thing? Scrum will usually make this bad behaviour really obvious. Let’s say that Alice hasn’t completed any tasks in the last four days (but she does have a task that she volunteered for at the start of the Sprint). Raj notices that Alice hasn’t finished that initial task. An acceptable solution to this problem is for Raj to volunteer to help Alice. Alice can’t refuse the help since Raj is self-organizing too. They might sit together to work on it.
Of course, that might not solve the problem. So another technique to use that respects self-organization is to bring it up in the Sprint Retrospective. The ScrumMaster of the team, Sylvie, chooses a retrospective technique that is designed to help the team address the problem. In a retrospective, it is perfectly acceptable for people on the team to be direct with each other. Retrospectives need to be safe so that this kind of discussion doesn’t lead to animosity between team members.
Remember: everyone goes through ups and downs in productivity. Sometimes a person is overwhelmed by other aspects of life. Sometimes a person is de-motivated temporarily. On the other hand, sometimes people become extremely engaged and deliver exceptional results. Make sure that in your team, you give people a little bit of space for these ups and downs. Assigning tasks doesn’t make a person more productive.
What If There is One Task No One Wants to Do?
Dig deep and find out why no one wants to do it. This problem is usually because the task itself is worthless, frustrating, repetitive, or imposed from outside without a clear reason. If no one wants to do a task, the first question should always be: what happens if it doesn’t get done? And if the answer is “nothing bad”… then don’t do it!!!
There are, unfortunately, tasks that are important that still are not exciting or pleasant to do. In this situation, it is perfectly acceptable to ask the team “how can we solve this problem creatively?” Often these kinds of tasks can be addressed in new ways that make them more interesting. Maybe your team can automate something. Maybe a team member can learn new skills to address the task. Maybe there is a way to do the task so it never has to be done again. A self-organizing Scrum Team can use innovation, problem-solving and creativity skills to try to over come this type of problem.
And, of course, there’s always the Sprint Retrospective!
Why Self-Organize – Why Is Assigning Tasks Bad?
Autonomy is one of the greatest motivators there is for people doing creative and problem-solving types of work. The ability to choose your own direction instead of being treated like a mushy, weak, unreliable robot. Motivation, in turn, is one of the keys to creating a high-performance state in individuals and teams. The greatest outcome of good self-organization is a high-performance team that delivers great work results and where everyone loves the work environment.
Assigning tasks to people is an implicit claim that you (the assigner) know better than them (the assignees). Even if this is true, it is still easy for a person to take offence. However, most of the time it is not true. People know themselves best. People are best at assigning tasks to themselves. And therefore, having one person assigning tasks to other people almost always leads to sub-optimal work distribution among the members of a team.
The ScrumMaster and Assigning Tasks
The ScrumMaster plays an important role in Scrum. Part of this role is to encourage self-organization on a team. The ScrumMaster should never be assigning tasks to team members under any circumstances. And, the ScrumMaster should be protecting the team from anyone else who is assigning tasks. If someone within the team is assigning tasks to another team member, the ScrumMaster should be intervening. The ScrumMaster needs to be constantly aware of the activity on his or her team.
I have added a video to YouTube that you might consider sharing with ScrumMasters you know about this topic:
Although subtle, having a public retrospective can do terrible damage to a Scrum team. In this video I explain what I mean by “public”, why it is so bad, and what you should do instead. This is part of a video series on the Myths of Scrum that is meant to respond to some of the most common mis-information (myths) about Scrum and Scrum practices. I will follow-up this video in several weeks with a written article complimentary to this video. Feel free to let me know in the comments if you have any topics that you would like me to cover in my video series!