Tag Archives: scrummaster

Pitfall of Scrum: Assigning Tasks

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:

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

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Video: Sprint Zero is Not Part of Scrum

Find out why Sprint Zero is a bad idea, and what you can do instead!

More Scrum and Agile videos to come!  Please subscribe to our WorldMindware channel.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

New Video: Myths of Scrum – A Public Retrospective

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!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Pitfall of Scrum: Problem-Solving in the Daily Scrum

The Daily Scrum should not be used to find solutions to problems (obstacles, impediments) raised. Instead, keep the meeting very short and have those problem-solving conversations afterwards with only those who are interested. The ScrumMaster facilitates this meeting to keep it on track. The Daily Scrum is timeboxed to a maximum of 15 minutes, but often should be even less. With a good physical task board, a Daily Scrum can often be done in less than a minute simply by each team member pointing at the pieces of work they are working on.

From the Scrum Guide:

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

In other words, don’t have those discussions during the Daily Scrum! The Daily Scrum is essential to creating transparency and implementing the Scrum value of Openness. The three questions of the Daily Scrum are effectively:

  1. What did I do since the last time we checked in as a team?
  2. What am I planning to do before the next check in time?
  3. What impediments, if any, are preventing us from getting our work done?

Each member of the team takes a turn and answers those three questions. This doesn’t have to be completely stilted, but it should be Focused (another value of Scrum) and efficient so that the need for other meetings is minimized. Accomplishing this takes some practice. The ScrumMaster helps the team to keep the timebox, but at first, a team might have challenges with this.

Struggling with the Daily Scrum

There are a some common reasons that a team might struggle with wanting to problem solve in the Daily Scrum:

  • One team member doesn’t know what to do next and it devolves into re-planning right there and then. A quick suggestion or two is probably fine, but it is a very steep slippery slope. A team can easily get into the habit of always doing this! The ScrumMaster needs to be vigilant about recommending that the discussion be taken up after the Daily Scrum is concluded in order to avoid this pitfall. This suggestion will be common when a team is first starting out.
  • One person mentions an impediment that someone else knows how to solve… and a third person has a different idea of solving it. In this situation it is much better for interested team members to just simply indicate “I have an idea for that,” and let the Daily Scrum continue. Then after the Daily Scrum those people have a quick discussion. This avoids wasting the time of everyone on the team with something that is only interesting to a few.
  • An individual doesn’t seem to have anything to report and other team members try to elicit more information. This should really be something that the ScrumMaster or the team’s coach should take up with the individual. It may be that there is an impediment that the person is uncomfortable sharing openly with the whole team. There is a subtle pitfall that may be revealed here: that the team does not have the safety to self-organize.
  • Disagreement about what to do next. This type of problem is the hardest to deal with because many people will feel that disagreements need to be resolved before any action can be taken. A good ScrumMaster will actually encourage competing ideas to be attempted. Learn by doing instead of by argument and analysis. This is the fundamental shift in culture that Scrum is attempting to put in place: an empirical approach to work rather than a defined approach.

Just beware: yet another pitfall (although not common) is to decide that the Daily Scrum shouldn’t be daily because it is taking so long. Unfortunately, making this change will often just make the meetings even longer until they devolve back into weekly status meetings reporting to the team lead!!! Remember that it’s not Scrum anymore if your team doesn’t meet together daily.

Ultimately, if a team is struggling with the Daily Scrum in any way, this is a valid topic for discussion in the Sprint Retrospective.

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

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

New Video: Myths of Scrum – ScrumMaster Assigns Tasks

In a few weeks, I will be posting a more detailed written follow-up to this video.  This is one of the most damaging and most common myths (or pitfalls) that ScrumMasters fall into….

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

All Team Quality Standards Should Be Part of the Definition of “Done”

The other day a technology leader was asking questions as if he didn’t agree that things like pair programming and code review should be part of the Definition of “Done” because they are activities that don’t show up in a tangible way in the end product. But if these things are part of your quality standards, they should be included in the definition of “Done” because they inform the “right way” of getting things done. In other words, the Definition of “Done” is not merely a description of the “Done” state but also the way(s) of getting to “Done” – the “how” in terms of quality standards. In fact, if you look at most of any team’s definition of “Done”, a lot of it is QA activity, carried out either as a practice or as an operation that is automated. Every agile engineering practice is essentially a quality standard and as they become part of a team’s practice, should be included as part of the definition of “Done”. The leader’s question was “if we’re done and we didn’t do pair programming and pair programming is part of our definition of “Done”, then does that mean we’re not done?” Which is sort of a backwards question because if you are saying you’re done and you haven’t done pair programming, then by definition pair programming isn’t part of your definition of done. But there are teams out there who would never imagine themselves to be done without pair programming because pair programming is a standard that they see as being essential to delivering quality product.

Everything that a Scrum Development Team does to ensure quality should be part of their definition of “Done”. The definition of “Done” isn’t just a description of the final “Done” state of an increment of product. In fact, If that were true, then we should be asking why anything is part of the definition of “Done”. This is the whole problem that this artifact solves. If this were the case, the team could just say that they are done whenever they say they are done and never actually identify better ways of getting to done and establishing better standards. We could just say (and we did and still do), “there’s the software, it’s done,” the software itself being its own definition of “Done”.

On the contrary the definition of “Done” is what it means for something to be done properly. In other words, it is the artifact that captures the “better ways of developing software” that the team has uncovered and established as practice because their practices reflect their belief that “Continuous attention to technical excellence and good design enhances agility” (Manifesto for Agile Software Development). The definition of “Done” is essentially about integrity—what is done every Sprint in order to be Agile and get things done better. When we say that testing is part of our definition of “Done”, that is our way of saying that as a team we have a shared understanding that it is better to test something before we say that it is done than to say that it’s done without testing it because without testing it we are not confident that it is done to our standards of quality. Otherwise, we would be content in just writing a bunch of code, seeing that it “works” on a workstation or in the development environment and pushing it into production as a “Done” feature with a high chance that there are a bunch of bugs or that it may even break the build.

This is similar to saying a building is “Done” without an inspection (activity/practice) that it meets certain safety standards or for a surgeon to say that he or she has done a good enough job of performing a surgical operation without monitoring the vital signs of the patient (partly automated, partly a human activity). Of course, this is false. The same logic holds true when we add other activities (automated or otherwise) that reflect more stringent quality standards around our products. The definition of “Done”,therefore, is partly made up of a set of activities that make up the standard quality practices of a team.

Professions have standards. For example, it is a standard practice for a surgeon to wash his or her hands between performing surgical operations. At one time it wasn’t. Much like TDD or pair programming, it was discovered as a better way to get a job done. In this day and age, we would not say that a surgeon had done a good job if he or she failed to carry out this standard practice. It would be considered preposterous for someone to say that they don’t care whether or not surgeons wash their hands between operations as long as the results are good. If a dying patient said to a surgeon, “don’t waste time washing your hands just cut me open and get right to it,” of course this would be dismissed as an untenable request. Regardless of whether or not the results of the surgery were satisfactory to the patient, we would consider it preposterous that a surgeon would not wash his or her hands because we know that this is statistically extremely risky, even criminal behaviour. We just know better. Hand washing was discovered, recognized as a better way of working, formalized as a standard and is now understood by even the least knowledgable members of society as an obvious part of the definition of “Done” of surgery. Similarly, there are some teams that would not push anything to production without TDD and automated tests. This is a quality standard and is therefore part of their definition of “Done”, because they understand that manual testing alone is extremely risky. And then there are some teams with standards that would make it unthinkable for them to push a feature that has not been developed with pair programming. For these teams, pair programming is a quality standard practice and therefore part of their definition of “Done”.

“As Scrum Teams mature,” reads the Scrum Guide, “it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.” What else is pair programming, or any other agile engineering practice, if it is not a part of a team’s criteria for higher quality? Is pair programming not a more stringent criteria than, say, traditional code review? Therefore, any standard, be it a practice or an automated operation, that exists as part of the criteria for higher quality should be included as part of the definition of “Done”. If it’s not part of what it means for an increment of product to be “Done”—that is “done right”—then why are you doing it?

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

An Evolution of the Scrum of Scrums

This is the story of how the Scrum of Scrums has evolved for a large program I’m helping out with at one of our clients.

Scrum of Scrum photo Continue reading An Evolution of the Scrum of Scrums

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Retrospective Technique: What Did You Learn?

Retrospectives are a key part of continuous improvement in Agile teams.  The retrospective techniques that a team uses should be adjusted to the needs of the team.  In a Scrum team, for example, the ScrumMaster will often decide on the techniques to use based on the current issues facing the team and then facilitate the retrospective for the team.  There are some great resources which give you collections of tried-and-true retrospective techniques including Esther Derby’s book “Agile Retrospectives” and the amazing online tool “Retr-o-mat“.  As an active consultant and trainer, I am always looking for new techniques to share with my clients.  Sometimes, I even create a new one (or at least new to me).  The “What Did You Learn” technique is new: I’ve been using it and testing it for a few years now to refine it.

What Did You Learn?

By itself, this is a powerful question.  As part of my work with OpenAgile, I’ve been helping teams and organization to focus on learning as an even broader category than continuous improvement.  The Learning Circle and the processes in OpenAgile help with focusing on learning.  The question “what did you learn?” is very open ended, and can certainly work as an extremely simple type of retrospective in OpenAgile or in Scrum or other Agile methods.  Often people like to have a little more structure and guidance so the “What Did You Learn?” retrospective technique provides four categories of learning for people to think about, share, and discuss within a team.

Setup

Setup for this retrospective is very simple: a flip chart or whiteboard divided into four sections or columns works fine, along with a piece of paper for each person in the retrospective, divided up the same way, and sufficient markers and pens for everyone.  Here is a downloadable PDF version of the handout for the “What Did You Learn” retrospective.

The facilitator will also participate at various points if they are a member of the team (e.g. a ScrumMaster).  It is easiest to do this with a group in-person, but can also be done reasonably well with video or teleconferencing.

Process

The facilitator introduces the retrospective with a welcome and, if necessary, a recitation of the Retrospective Prime Directive.  Then, the process is described to the group.  Each of the categories of learning is also explained as follows:

  • Questions.  When you can formulate a question about something, it means that you have learned about a gap in your knowledge.  In other words, you have discovered something that you would like to learn.
  • Information / Data / Facts.  These are specific details that relate to some area of knowledge or skill.  This category of learning is the simplest and is often what people focus on when asked “what did you learn?”  Information tends to be dry and unemotional.
  • Insights / Concepts / “Aha!” Moments.  Often when we have a collection of facts or an experience, we see a pattern or make interesting connections between things.  This leads us to the great feeling of an insight.  Insights tend to be exciting or scary and have an emotional component.
  • Action Items.  These are decisions about what we would like to do in the future, but they could be extremely short-term or very long-term or anything in between.

There are three main stages in the retrospective as follows:

  1. Individual Reflection.  For 10 to 15 minutes, each individual works silently to write down the things that they have learned in the appropriate category on the handout.  Everyone should try to get at least a couple things into each of the four categories, but more is welcome.
  2. Sharing with the Group.  Systematically going around the group and getting people to read from what they have written.  This is another 10 to 15 minutes.  This stage should not get bogged down in discussion, but brief clarifying questions should be welcome.
  3. Identifying Important Learning.  The group now has open discussion to decide on a small number of things it considers the most important that it has learned.  This could be based on popularity, but impact, depth, or uniqueness might also be factors in considering importance.  These are the items that get written down on the flip-chart.  This is usually the longest part of the retrospective and can take up to 30 minutes.

Applicability

This is an excellent retrospective for a team that is going through a significant transition such as starting a new project, a major change in business direction for a product, or as a wrap up technique for sharing lessons learned with other parts of an organization.  It is not a good technique for a brand new team that hasn’t worked together before as there will be little common ground for deciding on the importance of peoples’ various shared learning.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Comparison of the ScrumMaster, Product Owner, Project Manager and Team Lead Roles

Often in my classes, I’m asked for a clear comparison between the various traditional roles and the new roles in Scrum.  Here is a high level summary of some of the key responsibilities and activities that help highlight some important differences between these four roles:

ScrumMaster Product Owner Project Manager Team Lead
NEVER NEVER Assign Tasks YES
NO PARTICIPATES Create Schedule NO
NO YES Manage Budget NO
Remove Obstacles PARTICIPATES YES YES
NO Define Business Requirements PARTICIPATES NO
NO YES (Deliveries) Define Milestones NO
Facilitate Meetings NO YES YES
YES (process and people) YES (business) Risk Management PARTICIPATES
Organizational Change Agent NO NO NO
NO Accountable for Business Results RARELY (just costs) NO

Of course, there are many other ways we could compare these four roles.  What would you like me to add to this list?  Add a comment with a question or a suggestion and I will update the table appropriately!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Evolution of a Scrum Diagram

Over the many years that I have been teaching Scrum (since 2005!), I have had a diagram of Scrum as part of my slides and/or handouts.  The diagram has gone through several major and minor changes throughout that time.  Here is the progression from oldest to newest:

First Attempt

This diagram was used in some of my earliest slides when I first started delivering Scrum training.  It is bad.  It is woefully incomplete.  But, here it is:

01 Scrum Process Diagram

Second Diagram

I knew the first one was bad so after not too long, I created this next diagram as a supplement that was meant to show the whole Scrum process all in one page. Similar to other Scrum “cheat sheet” style diagrams. I used this diagram until about 2008 when I got some very good feedback from a great trainer, Jim Heidema.

02 All of Scrum Diagram

Third Try

The changes I made were small, but to me, significant.  Changing from a “mathematical” language of “Sprint N”, “Sprint N+1″ to a more general language of “Current”, “Future” was a big deal.  I really struggled with that.  Probably because I was still relatively new to being non-technical.

03 All of Scrum Diagram

Diagram Four

This fourth diagram made some minor formatting changes, but most importantly added “Backlog Grooming”.  It’s funny how long I talked about grooming in my classes before realizing that it was missing from the diagram.  I used the previous diagram and this diagram for a couple years each before making a rather major change to create the next one.

04 All of Scrum Diagram

Fifth Go

A couple years ago I realized that I wasn’t really talking about the Scrum values in my classes.  I started to introduce them in some of my other handouts and discussions, but it still took a while for me to reflect those values in my diagram.  I had also received a lot of feedback that having two Product Backlogs in the diagram was confusing.  Finally, I realized that I was missing an opportunity to use colour more systematically.  So, a major reformatting, systematic colour coding and the addition of the Scrum values was my next change.

05 All of Scrum Diagram

Branded Diagram (ug.)

In a rush, I added some logos to the diagram. Just made it gross, but it’s badness, combined with feedback about said badness, actually inspired a major change for the next version.

05 All of Scrum Diagram - Branded

Newest Diagram

Literally just a week ago, I was showing my brand-new branded diagram to a bunch of people who really care about design and UX.  The very first comment when I handed out the diagram was: “wow, you can really tell this wasn’t done by a designer!”  Well, that got me thinking deeply about the diagram (again).  So, here is my newest, latest and greatest (still not done by a designer) version of my Scrum diagram!

06 The Scrum Process

The Future

I would absolutely love constructive feedback about this latest diagram. Of course, if you like it, please let me know that too! The thing I like about this is that it is a way of looking back at almost 9 years of my teaching history. Continuous improvement is so important, so I welcome your comments! If you have your own diagrams, please link to them in the comments – I would love to see those too! In fact, it would be really cool if a bunch of people could make little “Evolution of a Scrum Diagram” posts – let me know if you do!!!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

The ScrumMaster is Responsible for What Artifacts?

Organizations like to have clear role definitions, clear processes outlined and clear documentation templates.  It’s just in the nature of bureaucracy to want to know every detail, to capture every dotted “i” and crossed “t”, and to use all that information to control, monitor, predict and protect.  ScrumMasters should be anti-bureaucracy.  Not anti-process, not anti-documentation, but constantly on the lookout for process and documentation creep.

To help aspiring ScrumMasters, particularly those who come from a formal Project Management background, I have here a short list of exactly which artifacts the ScrumMaster is responsible for.

REQUIRED:
– None – the ScrumMaster is a facilitator and change agent and is not directly responsible for any of the Scrum artifacts (e.g. Product Backlog) or traditional artifacts (e.g. Gantt Chart).

OPTIONAL/COMMON:
Obstacles or impediments “backlog” – a list of all the problems, obstacles, impediments and challenges that the Scrum Team is facing.  These obstacles can be identified by Team Members at any time, but particularly during the Daily Scrum or the Retrospective.
Definition of “Done” gap report, every Sprint – a comparison of how “done” the Team’s work is during Sprint Review vs. the corporate standards required to actually ship an increment of the Team’s work (e.g. unit testing done every Sprint, but not system testing).
– Sharable retrospective outcomes report, every Sprint – an optional report from the Scrum Team to outside stakeholders including other Scrum Teams.  Current best practice is that the retrospective is a private meeting for the members of the Scrum Team and that in order to create a safe environment, the Scrum Team only shares items from the retrospective if they are unanimously agreed.  Outsiders are not welcome to the retrospective.
– Sprint burndown chart every Sprint – a chart that tracks the amount of work remaining at the end of every day of the Sprint, usually measured in number of tasks.  This chart simply helps a team to see if their progress so far during a Sprint is reasonable for them to complete their work.
– State of Scrum report, every Sprint – possibly using a checklist or tool such as the “Scrum Team Assessment” (shameless plug alert!).

NOT RECOMMENDED (BUT SOMETIMES NEEDED):
– minutes of Scrum meetings
– process compliance audit reports
– project administrative documents (e.g. status reports, time sheets)

NEVER RECOMMENDED:
– project charter (often recommended for the Product Owner, however)
– project plans (this is done by the Product Owner and the Scrum Team with the Product Backlog)
– any sort of up-front technical or design documents

The ScrumMaster is not a project manager, not a technical lead, not a functional manager, and not even a team coach.  There are aspects of all of those roles in the ScrumMaster role, but it is best to think of the role as completely new and focused on two things:
– improving how the team uses Scrum
– helping the team to remove obstacles and impediments to getting their work done.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Ranking: the Best and Worst Roles to Transition to ScrumMasters

So you’re trying to do Scrum well because you heard it gave you great results.  You know that the ScrumMaster role is critical.  How do you find the right people to fill that role?  Here is a list of several roles that people commonly leave to become ScrumMasters, and a few not-so-common roles as well, all ranked by how well those people typically do once they become ScrumMasters.  From Worst to Best:

  • Worst: PMI-trained Project Managers (PMPs).  Too focused on control and cost and schedule.  Not easily able to give teams the space to self-organize.  Not able to detach themselves from results and focus on the process, values and teamwork needed to make Scrum successful.
  • Bad, but not awful: Functional Managers.  The power dynamic can be a serious hindrance to allowing teams to self-organize.  But, good functional managers already are good at building teams, and empowering individuals to solve problems.
  • Bad, but not awful: Technical Leads.  Here, the biggest problem is the desire to solve all the team’s technical problems instead of letting them do it.  Now, instead of detachment from results (project managers), it’s detachment from solutions.
  • So-so: Quality Assurance people.  Good at rooting out root-cause for problems… just need to shift from technical mindset or business mindset to cultural and process mindset.  Another problem is that QA is not nearly as respected as it should be and QA people typically don’t have a lot of organizational influence.
  • So-so: Junior techies: Enthusiasm can make up for a lot of gaps and naiveté can help solve problems in creative ways, but there will be a huge uphill battle in terms of respect and influence in an organization.
  • Good: non-PMI-trained Project Managers: rely on teamwork and influence rather than tools, processes and control (of course there are exceptions).
  • Awesome: Executive Assistants.  Respected and respectful, use influence for everything, know everyone, know all the processes, know all the ways to “just get it done”. Of course, they don’t usually know much about technology, but that often turns out to be good: they don’t make assumptions, and are humble about helping the technical team!

The ScrumMaster creates high performance teams using the Scrum process and values.  The ScrumMaster is not accountable for business results, nor project success, nor technical solutions, nor even audit process compliance.  The ScrumMaster is responsible for removing obstacles to a team’s performance of their work.  The ScrumMaster is an organizational change agent.

Other things you might want to consider when looking for a ScrumMaster:

  • Does the person have experience managing volunteer groups?
  • Does the person have good people skills in general?
  • Does the person want to create high-performance teams?
  • Can the person learn anything – business, process, technical, people, etc.?

Bottom line: try and avoid having PMI-trained project managers become ScrumMasters.  Even with good training, even with time to adjust, I often find that Scrum teams with PMI-trained project managers are always struggling and almost never become true teams.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Super-Hard ScrumMaster Quiz – Test Yourself!

For a little while last year I was using a quiz in my Certified ScrumMaster courses that was deliberately designed to be super hard.  Why?  Because if anyone could answer it correctly before the end of the class, I would give them their certification early and allow them to leave.  Not a single person out of several hundred was able to do it.

So… want to give it a try?  I’ve got two files here.  One is the quiz without answers.  The other is the answer key.  Let me know if you have any questions!!!

CSM Class Test – Super Hard! (PDF, 1 page)

(Please, give it a try before you even download this next piece!!!)

CSM Class Test – Answer Key (PDF, 1 page)

This test was first created by me and one of my close colleagues, Julien Mazloum from Outsofting.  We were trying to make the CSM class something that the Chinese audience would really appreciate culturally.  It worked well, up to a point.  The main problem was that some of the questions were too subtle for people for whom English was their second language.  That said, when I used it in my North American courses, still no one passed it!  In fact, the best score I ever saw was 25 correct out of 30.

Have fun!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcing Summer of Scrum Toronto 2014 Pre-Registration

One of our big plans this summer is to have a selection of advanced Scrum and Agile – related training courses.  We are delivering some of them ourselves, but we are also bring in outside experts for others.

Here is the course list at a high level:

– a 1-day “Advanced ScrumMaster” course
– a 1-day “Advanced Product Owner” course
– a 1-day “Managing for Success” course
– a 1-day “Enterprise Agile” course
– a 2-day “Agile Engineering Practices” course
– a 2-day “Agile Coach Training” course

Our schedule for these events will be finalized in the next few weeks.  If you are interested in any of these courses, please pre-register here.  Pre-registration will give you a guaranteed spot and a discount of 10% above and beyond the early-bird registration price.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

“Meet: Scrum”, the Diagram

Recently, in my work helping teams to learn and implement Scrum, I have deliberately not been using diagrams.  Having participants create their own ways of describing Scrum based on their own understanding is often a much more powerful approach to learning than showing them a diagram.  If you give someone a map, they tend to assume that all of the exploring has already been done.  If you give them a space to explore, they tend to create their own maps and provide new knowledge about the space being explored.  Maps and diagrams do serve a purpose.  They are useful.  What’s important to always keep in mind is that they should not be regarded as definitive but rather as one  contribution to a body of knowledge that can and should grow.

Anyhow, this isn’t intended to be a blog post about diagrams but rather as a post sharing a diagram that I have created.  One of the participants of a Scrum training that I recently facilitated asked me for a diagram and I said I would find one for him.  All of the other diagrams out there that I could find didn’t exactly convey my own understanding of Scrum.  So, I decided to create my own.

This is the first increment.  I am open to feedback and I look forward to finding out how this interacts with others’ understanding of Scrum.

ScrumDiagramTravisBirch

You can download it at this link: Meet: Scrum.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail