Dealing with the Office Saboteur

How to Deal with the Office Saboteur

I have never understood why some co-workers feel compelled to gain the upper-hand by acting like a saboteur. Is it insecurity? Possibly jealousy? Or maybe they’ve been facing challenges at home and need to take it out on someone at work.

I’m not talking about The Arrogant Bore who tries to take over your meeting or The Know-It-All who is all too happy to tell you what to do because they of course know best. I’m talking about the person who creates real havoc in your work life. I’ve come across many types of saboteurs, and I’ve grouped them into the following titles:

  • The Sniper
  • The Passive-Aggressive Disrupter
  • The Smiling Assassin

Before I talk about our 3 featured villains, I want to stress 2 very important concepts:

  1. Most people do not come to work each day with a mission to sabotage your project. So, before you act, make sure that you’re reading the situation correctly.
  2. Most important, do not take things personally. I repeat, do not take things personally. Bad behavior at work is the result of many different factors.

Always address the behavior in a professional and objective manner, citing facts to back up your observations.

Now, on to our bad guys.

The Sniper

This saboteur throws you a curve ball or directly opposes you (out of the blue) at a meeting. The Sniper seems to like striking in public, where they can do the most damage.

In my experience, The Sniper is often motivated by the need to have some control over what is going on or what is being discussed. This saboteur is best diffused by including him in pre-meeting discussions. I ran into one of these guys during a consulting job for the government, where I was a project manager.

At a major status briefing, when I came to a statement concerning his area, he sabotaged my briefing by saying the facts I reported were wrong. I didn’t say anything negative about his area, but he found it necessary to degrade me in the meeting anyway.

The next week, before the status meeting, I met with him and explained what I was going to report. I asked him if my report on his area met with his approval. I also made a point of asking him if I could count on his support at the meeting. He agreed, and I never had further trouble with him.

All he wanted was to be recognized and offered some deference. After I started looping him in prior to meetings, he turned into one of my most effective supporters.

The Passive-Aggressive Disrupter

This saboteur can create quite a bit of havoc when she has a beef with you. The Passive-Aggressive Disrupter comes to you in confidence and tells you something negative that another person said about you.

I’ve found the most effective way of dealing with this behavior is not to act on the information you receive. I worked with a woman several years ago, when I was managing a team of 125 analysts. One day, my co-worker approached me and told me that someone complained to her about one of my team members.

I decided I wasn’t going to play this game. I told my co-worker that if someone has an issue with a member of my team, then that person must come to me and discuss it themselves. I do not engage in watercooler talk and react to hearsay.

After this incident, I never had this sort of problem again, and people started coming directly to me with issues.

The Smiling Assassin

This saboteur can be one of the toughest to deal with, because on the surface, this person is nice to you and in agreement with you. Then, when you least expect it, The Smiling Assassin undermines you with your co–workers when you’re not around.

I have found a couple of ways to deal with this threat without resorting to an HR intervention:

  • Direct confrontation
  • Enlist co-worker help
  • Cultivate your network

Confronting The Smiling Assassin requires cool professionalism on your part. Approach him and tell him that what you heard he said. Give him a chance to explain or discuss the problem directly. Stay calm. Don’t get emotional. Listen objectively. If there some truth to the criticism, own it and work to correct it. If there is no truth, you have effectively shut this back-corner talk down by bringing it out in the open.

Enlisting co-worker help is a less confrontational strategy. Hopefully, you have co-workers that you are comfortable approaching for help. Ask them to shut down the conversation or come to your defense any time The Smiling Assassin speaks ill of you. This shows that negativity falls on deaf ears, and that soon stops the behavior.

Cultivating your network undermines The Smiling Assassin. I faced a situation many years ago where I was in line for a promotion. I found out after the selection meeting that a particular VP who didn’t like me vetoed the promotion. I confronted my Smiling Assassin and asked what I could do to improve his opinion before the next promotional cycle. He hemmed and hawed, and I figured out that there was little chance that he would change his mind.

I made a special effort to engage the Senior VP of that group and to worked to impress him. After the next promotion meeting, my network told me that the Smiling Assassin again tried to derail my promotion. But now, I had the Senior VP on my side and his vote overruled the other. I got the promotion. Afterwards, I avoided The Smiling Assassin as much as I could for the rest of my career at that company.

Closing Thoughts

Many times, workplace challenges are self-inflicted. Learn to honestly assess your own behavior before you blame others’ bad behavior on your negative outcomes. But, if you’ve done your soul-searching and you still think the problem is not yours, don’t become a victim and have faith in your power.

Always remember to stay professional, don’t waste energy taking things personally and try not to go over to the dark side yourself.

If you’ve run into a different type of Saboteur that you’d like to discuss, leave a comment and let’s see if we can add some more coping mechanisms to this post.


Gerri Slama Grove


Gerri Slama Grove

read more

Help Your Product Owner Prioritize Stories

Two Winning Techniques that Help Product Owners Set Priorities

We’ve all seen it.  The business provides a list of enhancements to a Product Owner. You, as Scrum Master, call a meeting to walk through the enhancements and try to facilitate prioritization.  What happens?  The Product Owner ranks all of the enhancements as high priority or must-haves.  And of course, if every priority is Number 1, there’s actually no priority at all.

I’ve tried a lot of techniques on the various teams I’ve worked on and have found these two work the best: Quadrant Chart and Story Mapping.

Quadrant Chart

My favorite quick-and-dirty prioritization method is the Quadrant Chart.  

It looks like this:

Notice how the Priority on the vertical axis is ranked Low to High, but the Complexity/Size on the horizontal axis is ranked High to Low.

This method is most useful when you have a long list of items you want to sort quickly and efficiently. You begin by stepping through your list of whatever it is you want to prioritize. In our case, Epics, Components, or Stories.  Start with the first item and work to the last.  Assign each two ranks.  For Priority, assign 1, 2, 3, 4 with 1 representing the least important and 4 having the highest priority. After you assign the priority repeat the ranking for the item on the basis of Complexity or Size. Again, use a scale of 1-2-3-4 with 1 representing the smallest/least complex and 4 representing the largest/most complex.

Now you have a list of Stories with two rankings each that you can plot on the quadrant.

It’s very easy to see that any Story that falls in the upper-right quadrant, High Priority and Low Complexity, is your best place to start.  This enables you to bring the highest value with the least amount of effort.  Who doesn’t like that?

Story Mapping

If you to try using a technique that requires more analysis, I suggest Story Mapping. This is similar to the old waterfall method of sequencing tasks, but with the added dimension of priority.  This method was introduced by Jeff Patton in 2005 and I highly recommend that you read his discussion on his Jeff Patton and Associates website.

Write your Epics on sticky notes and place them on the top of a decision box.

Now break the Epics into Components and write the Components on sticky notes. Place them in your decision box from left to right in order of use case sequence.

Finally, break the Components into Stories and place them in your decision box from left to right in order of use case sequence.  Here comes the cool part. At the same time, arrange the Stories from top to bottom based on importance. You can use the Quadrant Chart method to rank importance if you like.

When you finish, you’ll have a map of features that you can use to plan your Sprints. You move from left to right over time for your Sprints. Because the map also provides a top to bottom order of importance, you also have a lovely map of releases that provide increasing sophistication with each delivery. This is Alistair Cockburn’s concept of the Walking Skeleton.

So there you have it. Prioritizing is really pretty simple. All you need are a couple of tools and you can organize anything. If you want to investigate some other prioritizing methods there’s a great blog written by Daniel Zacarias who’s based in Lisbon. He describes 20 Product Prioritization Techniques. It’s a great resource.

Combine this with the GSD method for project planning and you can’t lose. See Chapter 2: GSD Gold Project Planning.

Gerri Slama Grove


Gerri Slama Grove

read more

Retrospective Lays Groundwork for Continuous Improvement

Do Not Postpone Retrospective

I am surprised by how many teams tell me they forgo Retrospective. To me, Retrospective is one of the most important meetings in Scrum.

Why? Because the Retrospective is the heart of continuous improvement. It’s where the team evaluates how well they’ve been working together and proposes better ways to get more stuff done.

According to the Scrum Alliance, the purpose of the Sprint Retrospective is to:

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

Inspect the Last Sprint

Scrum gives the team a forum for discussing how they feel about their progress in the prior Sprint. Broken processes are openly discussed, while there is still time to implement changes. Unlike with traditional post-mortems, which take place after the project is completed, Retrospectives are conducted on a regular basis throughout the project lifecycle. This affords the team multiple opportunities to review their progress and to discuss potential changes before small impediments become huge obstacles and the delivery schedule is negatively impacted.

Identify What Went Well and Areas for Improvement

My favorite part of the Retrospective is that the meeting starts with a celebration of Wins. In the world today, we tend to focus negative aspects. We want to fix what we think is broken. We forget that much of what we do works just fine, and that we should continue to do more of it. In fact, sometimes doing more of what works and stopping doing what doesn’t work is the way to go.   

Plus, taking the time to list everything that went well during the last sprint just feels great! Make sure everyone on the team lists at least one positive aspect. We want everyone on the team in the right mental state to constructively discuss the next topic: Areas for Improvement.

Remember that identifying Areas for Improvement is merely problem identification. At this point of the discussion, focus on symptoms, not solutions. Give everyone an opportunity to list their grievances.

Is there a pattern? Do the same issues return sprint after sprint? These types of issues signal an underlying root cause that has not yet been identified and addressed by the team.

After everyone has had the opportunity to state their grievances, the team should vote on what areas are high priority issues for the team to address. Why vote? Because the team can only effectively absorb 2-3 process improvements each sprint, and we want to ensure the team implements changes that have the most meaning to the team. There are numerous voting methods. The most popular approach is to give team members 5 votes each, to distribute any way they see fit.

Plan for Improvement

Once the team has narrowed down the list of topics, it’s time to brainstorm ways to resolve outstanding issues and work better together. Start with the highest priority issue first. After a short discussion, verbally agree to the option the team plans to adopt next sprint. Then discuss issues 2 and 3.

If the discussion gets heated or the team can’t agree on a decision, remember that we’re agile and we can revisit the topic next Retrospective. The beauty of Retrospective is that nothing is permanent, unless the team wants it to be.

The scrum master should document the Retrospective discussion on the team SharePoint or wiki pages: Wins, Areas for Improvement, Adopted Changes. Retrospective notes should be periodically reviewed to ensure that adopted changes have indeed been implemented and that the same problems haven’t resurfaced with different symptoms. Again, look for patterns. Do not let small issues become big problems that affect velocity and the team’s ability to deliver.

Here’s a nice Retrospective agenda:

  • Celebrate wins (15 minutes)
  • Identify areas for improvement (15 minutes)
  • Vote on areas to brainstorm (5 minutes)
  • Brainstorm and vote on improvements (30 minutes)
  • Round robin and closure (5 minutes)

If everyone is co-located, extend the meeting another 20 minutes and start with snacks and socializing. Make it a party!

Cynthia Kahn

Cynthia Kahn  503.799.5500

read more

Reduce Risk on Scrum Team

How to Reduce Risk on Any Agile Scrum Project

One of our readers asked me how to reduce project risk in a blog comment. The moment I read the comment, I started thinking about what to recommend. Yes, we all know the benefits of agile: get your product into the hands of the customer more quickly, early feedback, ability to pivot and increased customer satisfaction.

But what can we do to further reduce risk and increase our chance for success and profit?

My top 3 suggestions include:

  1. Train, train, train
  2. Plan and baseline your project
  3. Consistent velocity

Reducing risk through better scrum practices is more than just the scrum master’s responsibility; it’s the entire team’s responsibility. I’ve already written posts about techniques to improve performance, reduce risk and help teams better meet release commitments. So, I’ll provide links to those posts as additional reference material at the end of each suggestion.

1. Train, Train, Train

Scrum is very different from traditional development methods. Everyone on the team must receive adequate training and even coaching. You cannot just ask someone to read a book or attend scrum certification training and expect that person to lead the transition of an entire organization or even a single team.

The practice of scrum requires transitioning to an agile mindset. That requires training by an experienced professional. If budget allows, we suggest hiring a part-time agile coach to help the team remain focused on practicing scrum the right way, so they do not fall back into their comfortable, traditional practices.

If management does not invest in training, the team has little or no chance for a successful transition to scrum. You’ll probably end up practicing some inefficient hybrid form of scrum, what we call scrummerfall, which can result in more overhead and projects may even take longer than if your team remained traditional and never attempted scrum.

If you want a successful transition, train everyone on your team how to practice scrum and think with agility. Then, hire someone to help the team improve their practices. This is the Number 1 way to reduce risk.

For more information about how to successfully transition to agile, check out our post 5 Steps to Implement Agile.

2. Plan and Baseline Your Project

Those who don’t want to follow formal methodology often tell management that you cannot be agile if you have to plan beyond the current sprint. Nothing could be further from the truth! We affectionately call the practice of only planning sprint by sprint cowboy coding.  That’s not agile at all, it’s just chaos.

So to reduce risk, you must have a target product, priorities and planned public release dates. Recognize that the agile approach is different from the traditional way of planning. With traditional projects, you create work breakdown structures, which are task focused. With agile projects, you work with the customer to determine the most important product features, create a feature breakdown structure and plan for feature releases.

Organize the highest priority features for your first release, the next highest for your second release and so on. Write stories for the first release, start sprinting, start demoing and immediately start delivering value. With scrum, you don’t need to have all the answers to begin developing your product, but you do need to have a plan. Beginning with the end in mind is the Number 2 way to reduce risk.

For more information about how to successfully plan with agility, we suggest you read Chapter 2 of the GSD Scrum Handbook – GSD Gold Project Planning.

3. Consistent Velocity

Because scrum is so different from traditional methods, we recognize that at first the team may have trouble meeting its sprint commitment. If the team cannot meet their commitment sprint after sprint, then they have little or no chance of delivering on time. That’s why the Number 3 way to reduce risk is to help the team become more efficient.

If the team is not meeting its sprint commitment, a change of focus may be in order. A common mistake is to continue to focus on individual tasks rather than to holistically focus on completing the entire story. If your team’s primary focus is not on completing the story, then this change of focus can work wonders. Look at the burndown chart every day at the beginning of standup.

Reviewing the burndown is a daily reminder that the entire team must focus on closing stories.

Ensure everyone understands the story requirement and acceptance criteria when the story is picked up by the team. Because scrum accommodates changing priorities, stories written and groomed months ago can get pulled into a much later sprint than originally intended. Before the team starts designing and coding, make sure everyone involved with the story truly understands its requirement. While the developers design and code, the quality assurance testers should immediately start writing test cases to validate the story. This ensures the team is ready to test as soon as the story is coded and unit tested, reducing the gap between development and test.

Conduct a Retrospective at the end of every sprint. This is the best time to focus on what went right, where the team needs to improve and to implement much needed changes that improve performance and reduce risk. I cringe when teams tell me they don’t have time for Retrospectives. In reality, nothing could be farther from the truth.

Common opportunities for improvement include: Everyone needs to write better stories, lack of commitment from the Product Owner and stories are carrying over sprint after sprint. If you have issues in these areas, check out these posts: Write Better Stories,  Bad Behavior on a Scrum Team and Maximize Velocity in a Two Week Sprint.

When the entire team understands scrum, commits to a realistic product development timeline and completes work with consistent velocity, risk is greatly reduced.

Cynthia Kahn

Cynthia Kahn  503.799.5500

read more