Helping cross functional teams navigate conflict

High performing teams don’t avoid conflict; they manage it effectively. There are four main types of conflict that can occur on a team in your business.

  • task conflict – differing opinions on how to approach a problem or complete a project goal
  • relationship conflict – personal disagreements or hurt feelings between team members
  • process conflict – the team’s decision-making procedures, including how decisions are made and who has the final say
  • value conflict – differences in beliefs or goals.

As team leader, it’s important to identify the types of conflict that are occurring within your team so you can initiate intervention strategies, facilitate open communication, or at the very least, not get caught in the mud flinging in your business.

High performing teams succeed because they have psychological safety in a group of highly motivated individuals. High performing teams focus on success and sustainable practices.

Psychological safety is a shared belief that it’s safe to take risks and be vulnerable with each other. This doesn’t mean that there’s no conflict; rather, it means that team members feel comfortable enough to speak up when there’s a problem and trust that their suggestions will be heard and respected. Progress is an endless pursuit and creating psychological safety is essential for managing conflict constructively so that it doesn’t escalate into team dysfunction and distract from project goals.

As a team leader, you know that conflict is inevitable. But did you know that there are different stages of conflict? And that each stage can hurt your team in different ways? In this blog post, we’ll explore the 5 stages of conflict and how they can impact your cross-functional team. By understanding the stages, you can take steps to mitigate the hurt and keep your team succeeding.


Usually characterized as constructive disagreement, stage 1 conflict is a hallmark of a team focused on fixing the problem at hand. Information flows openly and honestly. Team members use language that is direct, specific, and based on facts — clarifying questions are used to discern what was said.

One of the key characteristics of a high level team is their high degree of trust and mutual respect. This level of conflict is healthy and indicative of a team that values technical excellence and a commitment to continuous improvement. They typically adopt agile processes and sustainable development practices. They value early and continuous delivery and help prioritize the customer’s competitive advantage.

Team’s naturally resolve conflict at this stage because well formed cross-functional teams are aware of the team’s performance goals and high level objectives. Their leaders prioritize continuous learning and celebrate wins.

One of the frameworks I promote is scrum (which is an agile process and lightweight framework). It helps create self organizing teams and promotes early and continuous delivery. Following agile processes will help ensure that conflicts are resolved in a timely and efficient manner with improvements scheduled on a regular basis. Agile processes harness change, efficient development processes, and face to face conversation. In my years as a team leader and facilitator, I have yet to find a more effective method for building high performing teams with motivated individuals.

“If we don’t trust one another, then we aren’t going to engage in open, constructive, ideological conflict. And we’ll just preserve a sense of artificial harmony.”

Patrick Lencioni

–The Five Dysfunctions of a Team


Team members start to own their perspectives about the problems. This is usually a good thing. However, it’s really easy for team members to personalize opposing perspectives and may engage in separate conversations outside the group as a whole. This is common among self organizing teams. However, when healthy joking around starts to look like personal jabs and shots, there might be a problem and team goals are at risk.

Technical excellence suffers when team members start building walls and are wary to extend their bridges to members with opposing perspectives.

Clarifying questions are used to discern why something was said vs what was said. This is an interesting among a high performing team culture if open communication is present and deeper problems can be uncovered and resolved quickly. If team members perceive that they can openly communicate with one another, then a positive team culture will develop and thrive.

If team members do not feel that open lines of conversation is present, then a negative team culture may develop. It’s important to schedule time with the team at regular intervals to support a positive team culture and ensure that ideas can be expressed safely with organizational and team goals in mind. When the team reflects on their interactions, positive cultures strengthen. Conflict is natural and can be managed by anyone on the team.

The key here is to always ask clarifying questions. They help to keep expectations open and prevent misunderstandings from occurring. When high performing team members feel that they can openly communicate with one another, they are more likely to trust one another and work together more effectively. Trust is essential for high performing teams, and clarifying questions help to build trust by ensuring that everyone is on the same page. By fostering support and trust, clarifying questions help high performing teams to thrive.

When the team reflects on their interactions, the organization wins.


Team members need to feel like they own their perspectives and that an opposing point of view is not a threat to them as a person. When members start attacking and challenging each others instead of an idea, business goals are at risk and your team is now navigating in a hostile environment.

If you’re a team leader, stopping conflict from escalating further should be your highest priority. Otherwise, employees quit because your business and its leaders fail to build a healthy culture.

Managers should get involved and lead discussions focused on fixing the problem, and not on winning. Past mistakes should not be brought up and used against others; this will only lead to power struggles and factions forming within the organization. If this happens, you’ll no longer have a sustainable development and you’ll struggle to use any agile processes harness change.

Effective communication is essential in team environments, especially when requirements are constantly changing. All team members need to be aware of the progress being made, and what needs to be done in order to achieve success. Focus on the complementary skills and conveying information that support understanding and common ground.


When team members are committed to their point of view, it can be difficult to come to a consensus. It’s important to support each team member’s ability to share their opinion and expectations for respectful debate, but when face to face conversation becomes hostile, the team’s ability to resolve conflict on their own is gone. Other teams in the organization should be made aware of the issue and instructed to steer clear or you’ll risk other organizational goals.

The most effective method for leaders in this situation is to reflect on the various points of view and focus on finding common ground among the employees. When factions within the team start to form, it is important to nip it in the bud and lead by example by initiating one on one conversations and conveying information about how the interactions being reported are impacting other people’s ability to do their job.

Factions can often be divisive and create office conflict. Ideologies, pressure from faction leaders, and recruitment of others from outside the team can all be signs that factions are forming. If left unchecked, this can lead to tension and polarization within the team or among teams. It is important to address these issues early on so that the team can reset some of their practices and revisit their working agreements. Leaders should revisit working agreements with these teams at regular intervals.


The tension in the room is palpable when employees are forced to work together in close quarters. Members find themselves physically distancing themselves from one another and raising their voices at inappropriate times. The pressure to perform is high, and dissension among employees is not tolerated. This can lead to a hostile work environment where employees are afraid to voice their opinions or offer constructive criticism.

In some cases, violence may even be imminent. In these situations, it is important to remember that employees are still people with feelings and needs. Businesses should do everything they can to avoid putting folks in this type of situation. By promoting a healthy workplace environment, businesses can ensure that employees are able to work together efficiently and productively without fear of reprisal.


Fostering healthy communication and trust between employees is essential for creating a successful work environment. It is important to establish clear expectations and guidelines for how teams should communicate. When issues arise, managers need to be prepared to step in and mediate any conflict that may arise. By doing so, teams can maintain their productivity while avoiding the risk of an all out war.

As a leader, the goal is to avoid conflict between teams by encouraging teamwork and collaboration. To do this, managers should focus on promoting a culture of respect and openness. Team members should be encouraged to openly share their ideas and solutions without fear of reprisal or being judged. Managers should also strive to create a work environment that encourages collaboration, creativity, and innovation.

When teams are equipped with the information they need and given the resources they require, they can work together effectively and efficiently towards common goals. This is a leader’s highest priority in order to promote high performing teams and avoid costly conflicts.

With proper guidance, teams can work together towards common goals without resorting to destructive tactics.

Photo Credit: Flickr

Side Stepping Landmines: Managing Risk With Sprint Futurespectives

Risks Are Landmines

Risk and project issues are one of the roots of poor project performance. There are three areas that we measure regarding the success or failure of a project; these three areas are what we call in project management, the triple constraint. The triple constraint consists of scope, budget, and time.

The interactions of these three areas are a lot like Newton’s third law of motion. For every action, there is an equal and opposite reaction. Was there a decision to increase the scope? You’ll likely need more time and money. Has there been a cut to the project’s budget? There most likely needs to be a cut to the scope. Has the schedule been crashed and we need to get to market in two months instead of the planned six? Better give me more money and be prepared to cut some of that scope down to a “minimal viable product.” I think you get the idea.

The triple constraint consists of scope, budget, and time. The interaction of these three areas are a lot like Newton’s third law of motion. For every action, there is an equal and opposite reaction.

This is why scrum is so effective. It allows for business agility via quick decision making from the Product Owner and iterative delivery of working software from the team. Scrum deals with actions effecting the triple constraint rather well. Project issues concerning the budget or schedule can quickly be addressed by everyone and the Product Owner can assess the business impact to make a decision that usually concerns scope.

However, when a team starts off on a new project that has a medium to high amount of risk and uncertainty, I recommend allowing teams the time to mull over possible risks and to perform some pre-planning. Otherwise, the project can blow up in their face or decisions will be made for them by the changed environment. We address this with risk planning — we don’t send our soldiers into a battlefield knowing land mines exist. So how can scrum teams plan for risk?

Risks are landmines. Some we know about. Some we don’t. Creating a plan to navigate and manage the consequences of a triggered mine is the only way to help us navigate a minefield responsibly.

Conduct A Futurespective

Thinking ahead and talking can help, but writing down potential risks and plans to address them is even better. This is the point of the “Futurespective;” To conduct risk planning at the start of a project or product enhancement and to give the team some time to do some planning before stepping on a potential minefield. It’s an activity outside of the typical scrum events and because of that, it should not be done before each iteration. Instead, it should be done provided select circumstances:

  • Just before beginning a new effort (i.e. Sprint Zero);
  • Just before a critical milestone (i.e. a new feature release to Production);
  • A significant change to a project constraint is anticipated (i.e. change to schedule, scope, budget, or quality). 

Just Before A New Effort – The Sprint Zero As A Futurespective

The Sprint Zero is an activity I’ve seen successful teams use when they conclude one effort and move to another. There is no such thing as multi-tasking and that is why we should frown upon teams who work on multiple projects at once. What they’re really doing is engaging in “task-switching” or inefficient “serial-tasking.” Instead, we encourage the team to wrap up a product feature and release it to production for general use before moving onto another product.

The Sprint Zero is the time between efforts that allows teams to assess what the new project or product enhancement is. If they’re cracking open the code for an existing product to add a new feature set, they should be allowed up to two weeks depending on the complexity of the code. For older, more monolithic applications, carrying large amounts of technical debt, I’d recommend no time-box on this activity. Let the team take their time getting familiar with the product, the code, and documentation (if it exists or is up to date). If there is no documentation, stress the importance to managers that they should not be rushed into starting the project until they are ready. Let the team decide when they’re ready to begin and use common sense.

If the team is about to spin up a new project and create a new product from the ground up, there should already be a product backlog and roadmap ready for them to review. The Sprint Zero is a great opportunity for the team to familiarize themselves with the backlog, Product Owner, Subject Matter Experts (SMEs), and stakeholders of the new product. The team should be conducting working sessions to create better acceptance criteria for user stories, sketching wireframes, and getting a better understanding of what they are going to build. Encourage them to seek continual feedback on their wireframes and designs. Make it an iterative activity. Teams may also take some time to engage in training if they will be developing in a newer development framework. Again, exercise common sense and decide on a reasonable time-box before kicking off the project.

Just Before A Critical Milestone – Release Planning As A Futurespective

Usually a sprint or two before releasing a larger feature, the team should have a handle on the stability of their product. Testers have been giving Developers feedback on the quality of their code via Integration & Performance Testing and of course, Bugs. The Product Owner is busy preparing, coordinating, or wrapping up User Acceptance Testing (UAT).  The Scrum Master is busy assisting everyone with Impediments and UAT. It can be chaotic or running smoothly… sometimes too smoothly…but, maybe I’m just naturally pessimistic?

I find this is a great opportunity to use the time normally allocated for a Retrospective as a way to plan for risk and get everyone together for the release plan. Of course, the need for this will eventually disappear as practices become better and code is pushed into production more rapidly via continual integration and continual deployment, however, I recognize that it can take a while to get to this point.

The need for this will eventually disappear as practices become better and code is pushed into production more rapidly via continual integration and continual deployment.

There are multiple ways to conduct a Futurespective and each one could use their own article. However, it’s a good idea to invite the Product Owner and SMEs to this event. To be concise, I’ll give you the meat and potatoes of what makes a good Futurespective.

  1. Identification of plausible risks regarding the release
  2. Statement of assumptions about the release
  3. Statement of the issues currently occurring (problems & challenges the team is experiencing).
  4. Identification of dependencies effecting the release (technical or cross-team dependencies the team or organization has). 
  5. Written mitigation plans that is developed by the team and Product Owner.
  6. Assignments/Owners for each plan (“if risk 2 is realized, who is the person responsible for leading the plan?”). 

A Significant Change To A Project Constraint

When a business priority changes and the project’s budget, schedule, or scope, is effected, the Product Owner may decide to stop the iteration and cancel the sprint. The Product Owner should call the team together and appraise them of the situation and call on the team for advice. Ultimately, the Product Owner will likely make some tough decision about cuts to the product scope. The Product Owner should use her Subject Matter Experts, stakeholders, and Delivery Team to make the most informed decision possible. It’s a great opportunity for everyone to brainstorm with the Product Owner about the best way to continue moving forward and exercise business agility.

Prioritizing the Product Backlog and refining user stories that were in the “freezer” takes a lot of effort and planning. Schedule as many backlog grooming sessions as needed and run a Futurespective before proceeding.

Thanks for taking the time to read and I hope you found it useful. I’d love to hear your thoughts on risk management or any experience you’ve had with Futurespectives. If you’d like to have a discussion, leave a comment below or contact me. I’d love to connect on social media as well!

Photo Credit: Pixabay

Related Posts

The Scrum Product Owner Chooses Business Value

The Product Owner Steers The Ship

Urban Legends In Our Organization. Listening To Our Naysayers, Seers, And Jaded Sage

Ditch “The Three Questions” And Adopt The Agile Mindset Already

Ditch “The Three Questions” And Adopt The Agile Mindset Already

Scrum teams that have been using Scrum for a while are most likely settling into the new framework. The chaos and dust from the change has settled and things are normalizing a bit. However, each team has their own unique way of doing things and, from the outside, managers may be holding onto their “command and control” mindset. Shouldn’t a process, like the daily scrum, be repeatable and look the same for all teams? Perhaps their mentality is that Scrum is a “methodology” and it should be strictly adhered to vs. a light weight framework in the “Agile toolbox?” Maybe they’re too focused on accountability of individuals vs. team autonomy? Whatever the cause, the Agile mindset just hasn’t quite set in yet. With a little bit of coaching, they’ll get there. Exercise patience.

One thing I’ve observed from leaders who haven’t quite fully adopted the Agile mindset yet is their insistence on strict adherence to “The Three Questions” during the daily scrum. There exists a feeling that “Vanilla Scrum” is the best way to do Scrum (There’s no such things as ‘Vanilla Scrum’ by the way). There’s a perception that the best way to do Scrum is to make everyone answer the three questions:

  1. “What did you do yesterday?”
  2. “What will you do today?”
  3. “Do you have any impediments?”

While I agree that the scrum guide can be prescriptive at times, the three questions listed above are not, in fact, mandatory. Seriously, read the section on the Daily Scrum and then come back.

Welcome back. So now that everyone’s educated, let’s talk about creativity. There’s a lot of room for creativity from each team and every individual. The Scrum Guide tells us “What we should do,” however, each team is left to figure out “How best to do it.” The format of the daily scrum is no different and there’s a lot of room for creative and constructive discussion questions. Strict adherence to the three questions can become an impediment to communication.

When speaking to your leaders, it’s usually not a good idea to open the scrum guide and show them where they’re wrong. It’s not very tactful and you miss a great opportunity to make the conversation a teachable moment.

When discussing this with leaders, start by asking some simple questions. I usually start with, “what does ‘vanilla scrum’ look like to you?” Their answer will likely reveal one of two things.

  1. Focus on the process; or
  2. Focus on individual accountability.

It makes sense, doesn’t it? As a manager, their ability to reliably deliver products, services, or projects is a reflection on their ability to lead their unit. Managers are accountable to stakeholders, customers, and their bosses. Yes, managers have bosses too. It’s pretty simple when we put ourselves in their shoes and I think we can empathize with their position. It can be a great deal of stress. Management isn’t for the weak of heart.

Yes, managers have bosses too.

Creativity Over Strict Processes

Command and control via processes can be effective. Set up a process. Follow the process. Repeat. But at what cost? I’d argue at the cost of creativity. I’d argue at the cost of low employee engagement. I’d argue complete and utter mediocrity. Of course I’m not advocating for zero processes either. That would be irresponsible. The people and process dependency is a balancing act, but let’s not rehash that discussion.

My recommendation would be to challenge the manager’s perspective about creativity and engagement. They may say they value it, but their actions may speak differently. Perhaps they view the daily scrum as a status report? That’s an anti-pattern you don’t want to have. Trust me. Been there. Done that. Got the t-shirt.

Scrum shouldn’t be “standardized across all teams.” If the pain point of the organization is variable quality and unreliable delivery, Scrum won’t fix that for you. But if you allow creativity to happen, then your employees will become engaged. And engaged employees who are empowered can move mountains. They’ll fix things on their own because at the end of the day, everyone wants to go home at five thirty, have a beer and spend quality time with their family. It’s the mindset, not the framework that we should strive for. Intrinsic motivation, not another carrot.

Responsibility Over Individual Accountability

I’m not advocating for zero accountability. Again, that would be irresponsible. But, the need to hold people accountable for their actions is another “command and control-ism” and it makes people fearful for their jobs. As a result, it stifles creativity and people will do just enough to stay of the RADAR and out of trouble. This is a much tougher problem to address because a manager focused on “holding people accountable” likely suffers the same from their own management. We can all empathize with our managers on this. Just like us, they’re subject to the same influences of organizational culture. As a coach, you must be courageous enough to address this with everyone in the organization, especially when another witch hunt is just around the corner. Are we trying to figure out who put crappy code into production? Or are we trying to figure out how crappy code got into production? You see the difference? The first question is about assigning blame. The second question is about addressing a problem. Stop with the witch hunts. People make mistakes. It’s a part of doing business.

My recommendation would be to re-frame the conversation around responsibility. Accountability is for Product Owners who must own the success or failure of a project. They are the single wring-able neck. However, responsibility can be shared and is something reserved for teams who share the responsibility of managing risk, keeping on schedule, staying within scope, and producing quality work. Product Owners are accountable for the overall performance of the project and guiding the team with a product road map. The Product Owner provides the what. The Team provides the how.

Stopping the flow of communication so they neatly fit the mold of the three questions can introduce risks into the project. It jeopardizes the quadruple constraint (Scope, Schedule, Cost, and Quality). So let your team discuss the sprint goal. Let your teams talk about the future beyond the next 24 hours. Let them self-organize in a way that’s most comfortable for them. They’re responsible for delivery — have the courage to step back so they deliver.

I’d love to hear your thoughts on the daily scrum or the anti-patterns you’ve recently spotted. If you’d like to have a discussion, leave a comment below or contact me. Feel free to connect with me on social media as well!

Photo Credit: Pixabay

Related Posts

Scrum Anti-Pattern: Daily Stand-Up As A Status Report

The People and Process Balancing Act

Agile Leaders Understand Customer Service And Culture

The People And Process Balancing Act

The Agile Manifesto Teaches Individuals and Interactions Over Processes and Tools

There’s a common misconception, especially among those new to Agile, that the relationship between people and processes is one of friction — that it’s a dichotomy. The subtlety of the language used, “individuals and interactions over processes and tools” implies that both need to exist. The framers of the Agile Manifesto even state, “while there is value in the items on the right (Processes and Tools), we value the items on the left more (Individuals and Interactions).” I agree with this and would also argue that processes and tools are an input to productive interactions among individuals. We know what is more valuable according to the Agile manifesto but, which one is most important? People or Processes? Maybe we’re thinking about it all wrong?

Chinks In The Armor

Asking, “what’s more important, people or processes?” is a fair question to ask when you’re new to Agile. Especially since most organizations looking to “go Agile” start with Scrum (by the way, practicing Scrum does not mean you are Agile. It’s a great start as long as the leadership team continues to stay open minded and doesn’t limit the organization to just Scrum). Usually, a handful of developers, project managers, business analysts and line of business managers are sent to a two-day class scrum class; they receive a certificate dubbing them newly minted “Certified Scrum Masters/Product Owners/Developers” and are given a small project to show a “proof of concept” with the

storm trooper
Scrum Reveals The Chinks in the Armor

new framework. It’s chaotic and exciting at the same time; however, the organization’s weaknesses begin to show up (Scrum has a way of shedding the spot light on the problems that have existed in the organization for a long time). I call these the “chinks in the armor.”

The biggest chink I’ve seen most teams discuss in their retrospectives are the People vs Process Dependencies. Invariably, team members and managers dig in their heels about which one is better. This is because people default to what they know best. They use what has worked for them in the past. Change is hard, even when there’s clear evidence that what they’ve been doing will not work anymore because of changes in the business environment.

As a coach, it’s important to understand the pros and cons of the people and process dependencies. It should be explained clearly with not only your teams but, with the management team too. The organization will have to move past striking a balance and figuring out which areas need the most improvement. Instead, they should assess the parts of each dependency and figure out what works best for them today. Below are some extreme examples of each dependency to illustrate the pros and cons of both.

People Dependency


  1. It gives workers satisfaction – employees feel satisfied when they know they are valued
  2. Flexible – employees are empowered to perform work in the way they feel is best
  3. Adaptable – the ability to pivot and make changes is the hallmark of business agility
  4. Efficient – unnecessary steps in a process are avoided
  5. Helps to retain high-achieving, confident, people – people stick around because they know they are important and are good at their job


  1. Less repeatability – changing processes are not repeatable and leads to waste
  2. Makes customers nervous – customers feel comfortable when there’s visibility on the process
  3. Can provide a “false sense” of a high degree of control – processes are measurable. What get’s measured gets done. When managers rely solely on the self-reporting, certain messages may get filtered and there is no data to verify.
  4. Turnover impacts are much greater – institutional knowledge can walk out the door or get hit by a bus
  5. Higher risks – for the reasons listed above

Process Dependecy


  1. Repeatability – repeatability helps with predictability
  2. Easier to improve – a documented process is easier to improve with less risk to the organization
  3. Less people dependent – automation of easily repeatable tasks frees up resources for more value added activities
  4. Predictability – it can be measured objectively and relied on as a lever for control in the organization
  5. Brings new personnel up to speed faster and with less risk of poor performance


  1. Paperwork can overshadow the task – processes that are overly complex distract from value added work
  2. Resources must be spent enforcing or ensuring compliance – managerial debt is incurred. Managers spend less time removing impediments and more time micromanaging processes.
  3. Someone must own and manage the process
  4. Less “thinking” is needed – employees and managers can become complacent if there’s no impetus for process improvement. This leads to waste. 

Processes Come First But They Should Not Be Valued

I know I’m going to rub a few people in the Scrum community the wrong way (and probably piss of a few of the business process analysts too) But, processes should come first but they should not be valued in the same way we value our people and interactions. It’s easy for managers to regard processes as instruments for control. Some managers finely craft their business processes. They labor over them and build complex systems for the organization. But only effective processes facilitate people. Not complex ones. If you require a practical rule of me, I recommend you murder your darlings.

“Whenever you feel an impulse to perpetrate a piece of exceptionally fine writing, obey it — whole-heartedly — and delete it before sending your manuscript to press. Murder your darlings”

— Arthur Quiller-Couch,

On the Art of Writing

vintage scale.jpg
People and Processes Are Not Equal

I argue that people and processes should not balance each other. Many representations of this balancing act builds a false dichotomy. It implies that they are of equal value. Like the framers of the Agile Manifesto, I do not value them the same way.

Processes should support our people and facilitate their interactions. Processes are either operational, supporting, or management oriented. If they do not provide value. Murder them. It’s up to the teams to decide which processes they need most and which ones can be forgotten. Each organization is different. Each darling should be judged accordingly — but retain the ones that still add value. Don’t throw the baby out with the bath water. Don’t assume that just because you’re “doing Agile” that processes no longer needed to exist. No, processes are still important. They unlock your people’s ability to work at a higher level. But it’s time to end the love affair with processes and value your people.

Share your thoughts in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

The 5 P Pyramid Model. Assessing Policy, Process, Procedure, People and Personalities In Scrum

Improving Agile Retrospectives With SMART Goals

Six Elements of An Effective Strategy




Talking About Communication: A Fun Game For Your Next PMO Meeting

Telestrations – A Game For Communication

Today I was cleaning out my school bag and came across some old index cards that I had used in my Advanced Project Management class. We used it during our lecture on communication management and the instructor had us play a quick game of Telestrations

Why It’s Important

One of the greatest threats to the success of any project is the failure to communicate. Our goal, as Project Managers and Product Owners is to ensure the timely and appropriate generation, collection, dissemination, and disposition of information. Communication is the oil that keeps a project running smoothly. 

This game is easy, fun, and provides some laughs. Additionally, it’s a great opportunity for everyone in the Project Management Office to be reminded of the basic principles of communication. I can’t tell you how many times I’ve sat in a PMO meeting and was either bored to death by power point (death by power point… ugh…) or the group wasted an hour and a half reviewing project status reports (couldn’t I have just sent an email?!?… double ugh…).

The game I describe below takes about 2 minutes of set-up and about 5-10 minutes to execute depending on how many participants are involved. It’s a great ice-breaker and will keep everyone focused if you’re one of those evil managers with a habit of scheduling the PMO meeting after lunch.

Supplies – What You’ll Need

  1. Pink (or any color) note cards x4
  2. White note cards x16
  3. Sharpies x4
  4. Stop watch x1
  5. 1 person to facilitate and keep time
  6. 4 or more people to participate


Write 4 different project management topics on your pink notecard (in the examples below, my team used: integration, program management, execution, and procurement)

Place 4 of the blank note cards (or more if there are more than 4 people in a group) under a pink card with the project management term written on it.

Write the following instructions on a whiteboard for everyone to read:

  1. Please get into a group of 4 people.
  2. Each person will be given a group of note cards (keep them together at all times).
  3. The 1st note card will have a Project Management term on it (Do not share this word with anyone in your group until we are done with the game).
  4. Every 1 minute, we will rotate through the note cards as follows (The facilitator will keep time and ensure the note cards pass to each person):
    1. First Person, read the term on the pink card, then place that card behind the stack of cards and draw the term on the first blank note card. Pass all of your note cards to the next person with your drawing on top.
    2. Second Person, Based on the drawing the first person made, Write the term on the next blank note card. Pass all of your note cards to the next person with the term you wrote on the top.
    3. Third Person, Read the term the second person wrote and place it behind the stack of cards. Draw the term the second person wrote on a blank note card. Pass all of your note cards to the next person with your drawing on top.
    4. Fourth Person, Based off of the drawing the third person made, Write the term on the next blank note card. Pass all of your note cards to the next person with the term you wrote on top.
    5. Assuming a group of 4, the first person should have the original project management term they started with — the pink card they first read to start the game. Starting with the pink card, each person read the original term and share the pictures and terms in the order they were drawn. 
    6. Facilitator should allow each person to describe their pictures and encourage a few minutes of conversation.
  5. Final Note: Drawings can not have any written words or prompts on them. Pictures only!

Below is an example of the final results our group had:

Topic: Integration

As you can see, the first three people were able to communicate “integration” pretty well. The fourth person wrote “tools & techniques.” When we discussed this as a group, the pot in the third picture reminded the fourth person of tools and cooking techniques used in the kitchen.

Topic: Execution

This one was pretty funny. I started off this iteration and chose to draw a stick figure getting decapitated at a guillotine. I felt this was a an obvious example of “execution.” Unfortunately, the second person didn’t pick up on this and guessed “penalty.” Naturally, the third person figured this was a “penalty” and related that to budget and drew a picture that led the fourth person to assume “over budget.” We were way off the mark with this and shared some laughs.

Topic: Procurement

On my opinion, this was the hardest topic. During our discussion, the first person stated they had a tough time trying to draw a picture for “procurement” in 1 minute or less (heck yes! I still don’t know what I could draw). The closest thing they could draw looked like communication management and that was what we all guessed at. Again, we weren’t even close!

Topic: Program Management

I think the first person did a great job with their picture. A program is a group of similar projects or activities. The use of a the box plot diagram was straight out of the PMBOK. Unfortunately, as we discovered, the artist chose to use 5 circles to represent the projects inside of the program. The second person focused on this fact and guess “the 5 phases of a project.” The third picture, which is mine, has a stick figure using a phaser on a column of 5 (pretty creative if you ask me). The final person guessed “5 knowledge areas.” I guess my picture wasn’t as good as I thought it was.

Take Aways – Common Mistakes With Communication

There’s plenty of material about the basic communication model. I’ll try not to rehash something we all know, so I’ve just highlighted a few of the key takeaways from our lecture and subsequent discussions.

Confirm communication is actually received and understood.

Research says that in a face-to-face interaction:

  1. 58% of communication is through body language
  2. 35% of communication is through how the words are said
  3. 7% of communication is through the content or words that are spoken
  • Pay attention to more than just the actual words someone is saying.
  • A person’s tone of voice and body language say a lot about how they really feel.
  • Ask people what information they need and when.
  • Plan communications to all stakeholders and project team members and a way that fits their needs.
  • Customize communication standards within your organization to the needs of the project. Don’t stick with a template if it’s not effective!
  • Use multiple methods of communication.
  • Realize that communication is two-sided, to and from a stakeholder or project team member.

Share your thoughts on communication or using the Telestrations game in your next meeting in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

The Quick And Dirty On Stakeholders

Scrum Product Owners Part 2

Scrum Product Owners Part 1

The Quick And Dirty On Stakeholders

A Scrum Product Owner’s Quick And Dirty Guide To Stakeholder Management

Identify Stakeholders

One of the core responsibilities of a Product Owner is managing stakeholders. Successfully managing Stakeholder expectations, decisions, and time are all signs of effective stakeholder management. There are many tools and techniques to help you identify your stakeholders, however, below is a list of ideas to help you wrangle in those stakeholders and identify who they are:

  1. Follow the money – find out who’s got some skin in the game
  2. Resources – find out who’s giving your their people to assist with development
  3. Deliverables – find out who you are delivering the product to
  4. Decision-Makers – find out who will make decisions before you can deliver the goods
  5. Related Programs/Products/Projects – find out who acts as a supporting function to your product
  6. Organizational Charts – find the organizational chart and make sure it is up to date
  7. Team members – if you’re new, ask your team members
  8. Find Influencers – Unofficial People of Influence who yield power through influence and not their position

Know What Motivates Your Stakeholders

Understanding what motivates the stakeholders is just as important as knowing the organizational goals. Of course, we like to think that everyone thinks, “yes! go team and go us! let’s move towards our goal.” Unfortunately, politics also play a part in the Product Development game. Some stakeholders have their own interests in mind or put their own department needs first. They lose focus on the over-arching strategy of the organization. Effective Product Owners need to be aware of:

  1. The Organizational Strategy
  2. Budget Positioning
  3. Personal Agendas
  4. Stakeholder “Pet Peeves,” “Pet Projects,” and their “Pet People.”

Problem Children

Some stakeholders bring their “baggage with them.” Sometimes they lose trust in a Project Manager, Scrum Master, organizational leadership, the delivery team, or have no faith in the product itself. Some stakeholders might have been recently burned by a project. They can have some sort of “baggage” they carry with them. No one is perfect, and sometimes, as a Product Owner, you just have to own those past issues to keep development moving forward. Saying, “I’m sorry” is free and owning those issues and sharing how you intend to do it better (sharing the lesson’s learned with the stakeholder) is the first step in gaining the confidence of any “problem children.” Below is a list of reasons why your stakeholders may be “acting out.”

Lack of trust in

  1. Project Manager/Product Owner/Scrum Master
  2. The Project/The Product/Product Delivery Team
  3. Product/Project/Program goals not articulated or defined in accordance with the organizational strategy
  4. “Bad Project Experiences”
  5. Your Own Past Mistakes

Problem Children exhibit the following behaviors:

  1. Meddlers: Always inserting themselves into decisions, processes, or meetings where they are not required
  2. The Forever SME (Subject Matter Experts): Usually a high performer who was promoted but hasn’t let go of the responsibilities of their old position
  3. Indecisiveness: Can never make decisions in a timely manner
  4. Lack of Budget: They ask for everything but don’t want to help pay for it

Golden Unicorns

The ideal stakeholder exhibits the below traits. Our “golden unicorns.” As a Product Owner, we want to make sure we keep the trust of our golden unicorns all the way to the finish line.

  1. Belief in the Product/Program/Project
  2. Don’t revel in the past — even if they had a bad project experience
  3. Communicate their needs well
  4. Availability
  5. Team Player
  6. Excellent Manager and Employee
  7. Positive self-esteem
  8. Helps motivate team members and other stakeholders
  9. Accountable & Responsible
  10. Can make timely decisions

Share your thoughts on stakeholder management in a comment below. If you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

Scrum Product Owners Part 1

Scrum Product Owners Part 2

Urban Legends In Our Organizations. Listening To Our Naysayers, Seers, And Jaded Sage

Reflections On Courage: What Rocky Balboa Taught Me About Failure

Once a year, I have a ritual and binge watch all of the Rocky movies. For those unfamiliar, the series is about an Italian-American boxer portrayed by Sylvester Stallone named Rocky Balboa. The saga begins with Rocky, a small-time boxer, trying to make ends meet as a collector for a loan shark. As the series progresses, Rocky is faced with multiple challenges. He achieves success, failure, loss, even ridicule — not just in the ring, but in life as well.

While many consider each movie an action/sports film, I feel that the series is a set of beautifully crafted dramas that just happen to have boxing in them. The series connects with me in a few ways, however, what keeps me coming back to the series each year is the lessons about picking yourself back up after a failure. Perseverance and the courage to keep moving forward, even when no one believes in you, is how ordinary people achieve extraordinary results.

The Rocky Saga

Below is a brief synopsis of each movie. Don’t worry, there aren’t any spoilers here.

  1. Rocky is about when opportunity meets preparation you can achieve success.
  2. Rocky II is about proving you belong even in the face of criticism and self-doubt.
  3. Rocky III is about failing because of complacency and picking yourself back up and starting over.
  4. Rocky IV is about facing seemingly impossible challenges with the world watching you — even after suffering a traumatic personal loss.
  5. Rocky V is about losing your success because life has a funny way of working that way. Continuing your legacy and keeping what’s most important in life ahead of you (even if we forget about what’s truly important at times) is the greatest success we can have in life.
  6. Rocky Balboa again, is about facing seemingly impossible challenges, even with the world watching, because that’s the way you live. It’s the way you’re made. You don’t know how to live differently.

While I love the newest movie in the series, Creed, I want to stop right here. Because in Rocky Balboa, Sylvester Stallone has one of his most powerful scenes in the entire series. It resonates with me every time I watch it.

That Speech About Life, Taking Punches, And Moving Forward…

Rocky’s son, now a young man in his 20s, is upset with his father for taking an exhibition fight with the reigning champion, Mason Dixon. Rocky’s son explains how difficult it is to live in the shadow of someone like his father. That because he shares the same last name, if his father makes a fool of himself, or worse gets hurt, it’ll somehow hurt him, his career, and reputation.

Rocky is taken aback by this, and his son continues, “doesn’t it bother you that people are making you out to be a joke and that I’ll be included in that?” Rocky is disappointed. He takes a moment to reflect. Then delivers one of the most powerful speeches I’ve ever heard…

“You ain’t gonna believe this, but you used to fit right here.

I’d hold you up to say to your mother, ‘This kid’s gonna be the best kid in the world. This kid’s gonna be somebody better than anybody I ever knew.’ And you grew up good and wonderful. It was great just watching you, every day was like a privilege. Then the time come for you to be your own man and take on the world, and you did. But somewhere along the line, you changed. You stopped being you. You let people stick a finger in your face and tell you you’re no good. And when things got hard, you started looking for something to blame, like a big shadow.

Let me tell you something you already know. The world ain’t all sunshine and rainbows. It’s a very mean and nasty place and I don’t care how tough you are it will beat you to your knees and keep you there permanently if you let it. You, me, or nobody is gonna hit as hard as life. But it ain’t about how hard ya hit. It’s about how hard you can get hit and keep moving forward. How much you can take and keep moving forward. That’s how winning is done! Now if you know what you’re worth then go out and get what you’re worth. But ya gotta be willing to take the hits, and not pointing fingers saying you ain’t where you wanna be because of him, or her, or anybody! Cowards do that and that ain’t you! You’re better than that!”

– Rocky Balboa

It’s a powerful speech and when you get a chance, watch the movie. If you haven’t seen a Rocky Balboa movie, watch this one. It’s a gritty and inspiring film. If you disagree, you can fight me… just kidding… kind of…

Let The Team Take Their Punches

So how does this relate to coaching? Well let me tell you about one of my own failures. When I first started out as a scrum master, I held onto the “failure is not an option” mantra. I brought this mantra with me from my time in the military. I was a ‘helicopter parent’ in a lot of ways and did my best to protect my teams from failure because I didn’t want it to reflect on me or be viewed as an inability to be an effective servant leader.

I would interject when I saw the team laying down railroad tracks aimed at a cliff. I would coerce them to adjust before they realized it was necessary because they weren’t look at the big picture. I didn’t want them to make a mistake — I didn’t want us to fail. As a result, I failed my teams. I took away the their ability to have a shared experience. A shared failure.

I’ve learned from my failure and if you can relate, as am sure some of you do, I encourage you to have the courage to watch your teams fail at new things. Letting your team fail together means they grow together. Failure, just like success, is not final. It’s having the courage to continue, to take those punches and keep moving forward that counts.

Leave your thoughts about failure in a comment below. If you’d like to have a discussion about the Rocky Movies, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

Improving Agile Retrospectives With SMART Goals

Continue reading

Improving Agile Retrospectives With SMART Goals

Soccer goal on an green field

Improving Agile Retrospectives With SMART Goals

Agile retrospectives are one of the best feedback loops built into Scrum. It allows delivery teams to pause from their day-to-day work to inspect and adapt their way of doing things. One of the final deliverables of an effective retrospective is a plan to implement improvements on how they build their products. Some of the things a delivery team may choose to look at are:

  • Tools & Techniques,
  • Processes & Practices,
  • People & Communication,
  • Quality & Risks,
  • Project Scope & Schedule,
  • Technical Debt & System Architecture,
  • Organizational Culture & Priorities.

A Caution For New Scrum Masters

While the above listed topics usually elicit deep, and sometimes passionate discussions, new teams may fail to actually develop and implement an effective plan to address the insights they generated. When I first started running my Agile retrospectives, my delivery teams would generate valuable insights, have deep and meaningful conversation, and then leave feeling a bit exhausted but generally glad that some dirty laundry was aired.

The result was mostly positive. Team members would develop better working relationships with each other and be more open to practicing empathy on a day-to-day basis. However, after a while, I observed that the discussions kept gravitating towards the same things over and over again. I realized some teams weren’t developing and implementing any plans to improve themselves.

As a scrum master, I was letting my teams down. I was facilitating great discussions and watching the teams develop better working relationships. Of course this was an accomplishment, however, that accomplishment was blinding me to the fact that the teams were maturing and ready to tackle process related problems. They moved past their interpersonal differences and were ready to tackle deeper issues. It was easy to recover from that fumble and SMART Goals helped me do it.


A SMART goal is an acronym based goal setting guide. It stands for: Specific, Measurable, Attainable, Relevant, and Time-bound. It’s simple to use and forces teams to think, plan, clarify, and begin measuring their goals. To help your team set a SMART goal in a retrospective setting, I recommend allocating the last 20 minutes of the retrospective and writing the following quote and the word “SMART” on a white board.

“A dream is just a dream. A goal is a dream with a plan and a deadline.”

– Harvey Mackay

S – specific

We want to be as precise as possible with what the team is trying to fix or improve on. One tool I use comes directly from scrum — I have the team write a user story.

As a <delivery team> we want to <address some issue> so that we can <some improvement to be made>.

This should be done in an iterative fashion if the user story is not specific enough. Asking the below questions will help the team zero in on the specifics of their SMART goal.

  • Why do we want this?
  • Who is involved?
  • What resources are constrained?
  • Why is the goal so important to us?
M – measurable

What gets measured gets done. Think of this portion as the acceptance criteria of the user story. The measurements will be unique to the goal, but try to use quantifiable items. Ask questions about the desired end state. If the SMART goal is centered around the project you can use the 10 knowledge areas

  • Project Integration Management
  • Scope Management
  • Cost Management
  • Schedule Management
  • Quality Management
  • Risk Management
  • Resource Management
  • Procurement Management
  • Communication Management
  • Stakeholder Management
A – attainable

This is our first check point — the team should reflect and assess if their SMART goal is realistic. Like effective user stories, we need to check if the SMART goal is independent and free of dependencies. If the SMART goal isn’t free of dependencies, the team may need to return to the Specific portion of their SMART goal and address any dependencies that exist.

R – relevant

This is our second check point — the team should reflect and assess if their SMART goal is germane to the insights discussed during the retrospective. As a Scrum Master, you can ask questions like:

  • Is this a worthwhile effort?
  • Are we the right group of people to take on this effort?
  • Is this the right time to address this effort?

Again, if the team doesn’t define the SMART goal as worthwhile or discovers they are not the right group of people to take on the effort, they should return to the Specific portion of their SMART goal and identify something within their span of control.

Note: if the team discovers that another group is more suitable to address the issue discussed, the Scrum Master should take the generated insights and work with that group after the retrospective adjourns. 

T – time bound

The final step is to establish a target date. Teams tend to work better when there’s a deadline in place. The team, armed with the specifics of their SMART goal, defined metrics, and an ideal end state should be able to set a realistic date. In my experience, the date should be no more than 2-iteration lengths (4-weeks total assuming 2-week iterations).

Leave your thoughts on Agile retrospectives or SMART goals in the comments below or if you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Flickr

Related Posts
For more on:

Urban Legends In Our Organization. Listening To Our Naysayers, Seers, and Jaded Sage

Urban Legends and The Organization

I recently started binge watching a show called Supernatural. For those of you unfamiliar with Supernatural, it’s about two brothers, following in their father’s footsteps, traveling across mid-west America, solving mysteries of the paranormal. They’re a part of a small community of “hunters” who vanquish demons, ghosts, shape-shifters and other urban legends (great show! I highly recommend it!).

While watching S01E05, an episode based on the “bloody mary” urban legend, one of the brothers makes the statement, “all urban legends are based on some version of the truth.” This got me thinking about the urban legends that exist in our organizations and prompted me to reflect on when my own organization first adopted Agile to manage our projects.

“The seed of an urban legend find fertile soil at the corner of tragedy and imagination.”

― Thomm QuackenbushWe Shadows

Bad Advice: Ignore The Nay Sayers…

About a year and a half ago, I was one of the leading change agents in our IT Operations Section. I coached and taught Agile to our Server Group, Network Group, Desktop Support Team, Service Desk Agents, Database Administrators, a GIS team, and a Software Development team. Each team had one or more people labelled by management as the “naysayers.” I was warned to ignore them and push forward. However, I felt this was the wrong approach.

Naysayer or Jaded Sage?

I say embrace the naysayers. They are the organization’s seers. They have been around the block, seen past failures and experienced a variety of initiatives from different management regimes. They’ve lived through the failures of past projects. Over the course of their careers and their tenure, they have accumulated sage like experience. Unfortunately, the naysayers have become a bit jaded and skeptical of “initiatives” they’ve seen fail in the past. One might say they’re not quite ready to start “drinking from the kool-aid.”

Some of these urban legends sound like…

  • “They’ve tried this before…”
  • “Just another management fad…”
  • “Why are they trying to reinvent the wheel…”
  • “They’re asking us to do things outside our work performance standards…”
  • “They can’t throw this in the mix, we’re busy trying to keep the lights on…”
  • “They keep shifting priorities, we can’t keep up…”

Identify Project Risks With Respect and Empathy

Seeing repeated failure is frustrating. It’s only human to become frustrated and fear failure. Sometimes it sounds like the naysayers are full of “doom and gloom” but their urban legends really only spur from a place of fearful imagination. Because of their fear, there’s a certain level of “attitude” and defensiveness we may face we when first initiate a dialog with our jaded sages, however, treating them with respect, dignity, and lots of empathy will go a long way. This attitude will quickly dissipate and they’ll open up and impart some of their wisdom and lessons learned.

Our Goal Is To Identify Project Risks Early

Our goal is to identify project risks quickly and find that grain of truth in their urban legends. Their wisdom should never fall on deaf ears. As a coach, project manager, or product owner, it’s our duty to ensure our organization doesn’t miss out on opportunities to learn from past mistakes and to identify risks as early as possible so they are not realized, or at the very least, so risks can be mitigated and managed.

As a project manager, we can add these items to our risk management plan and start a qualitative analysis with the project team. Product owners and scrum teams can conduct a retrospective focused on the risks. Some of my favorites are:

  • The Sailboat – Use this technique to identify what things are helping the project, what is slowing the project down, and what risks are ahead (I like to draw a pirate ship and jagged rocks below the water line and differentiate between known risks and possible unknown risks for prioritization).
  • The 5 Whys – Use this technique to help identify root causes of known risks and get at the root of problems.
  • SWOT Analysis – Strengths, Weaknesses, Opportunities, and Threats. A classic technique usually used to form organizational strategy can easily be framed for risk identification. I like this one because “opportunities” can include good risk that we should plan for (example: We are planning an event for 200 people, however, what if 1000 people show up? This would be a good thing but jeopardize the success of the event if we don’t have a contingency plan to accommodate the extra 800 guests).

If you’d like to discuss more about managing risk and dealing with naysayers, I’d love to hear from you! Let’s connect and have a conversation.


Photo Credit: Flickr