A Story On Anti-Patterns

The Anti-Pattern

In one of my past posts, I asserted that the Product Owner Steers The Ship and that as a coach, we don’t want to make assumptions about the anti-patterns our Product Owners may have inherited from their previous roles. After a few conversations I had with people, I decided to expand a bit on the topic of anti-patterns. There are multiple areas in Agile that need their own list of anti-patterns and context. But isn’t that true in life? I think so. So for this post, I’m going to dive into anti-patterns as a behaviors and a mind-set and treat you with a story. Enjoy!

“An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being counterproductive”

-Andrew Koenig

Design Patterns


Figure It Out, Larry!

Samantha is a District Manager for a manufacturing company and she’s dealing with a new employee, Larry, who isn’t quite performing up to par with the rest of her team. For the third week in a row, Larry has submitted “sub-par work.” The numbers and calculations in his reports are way off from the previous ones she’s used to seeing. It’s obvious to Samantha that Larry isn’t following the templates and checklists correctly. But, she can’t figure out how to get through to him. She doesn’t want to start micro-managing his assignments, but she and her team have been so backlogged that she expected him to follow all the documented procedures and figure it out. He seemed so bright on paper. Maybe she was wrong about her newly hired employee?

After reviewing his first report, she made a passing comment, some thing along the lines of, “you really must have grinded this out at the last minute, Larry?” It was meant as a half-serious joke. She doesn’t really know Larry that well, being that he’s new to the team, but she’s known for being sarcastic in the office and most of the team dish it right back at her. His first day on the job the team had a particularly rowdy meeting. He knew what was up and that no one took the jabs seriously. She has a healthy working relationship with her team, despite what it looks like on the outside. She has full confidence in her staff and she chooses to be hands off with them. Everyone is brilliant. Except maybe one?

The second report came in and she was a bit agitated. She decided to remind everyone at the next staff meeting about using the correct template and the expectation of “quality work from each individual — everyone is busy with their own projects and programs and is expected to pull their weight.” She made eye contact with Larry, letting him know that the message was meant for him. Larry didn’t hold her gaze for long. It was clear he got the message.

After week three, Samantha lost it when she got Larry’s report. Not only was the report turned in late, but Larry was no where to be found. Who was Samantha going to yell at? Samantha immediately navigated to the HR SharePoint page and downloaded the Word document titled “formal written reprimands for employees.” It was time to send a message to Larry, “it’s time to shape up or ship out” she thought to herself. Three weeks and he still hasn’t figured it out.

Samantha went through the report closely and began documenting discrepancies like formatting and the fact that the report wasn’t turned in first thing in the morning — she noted each item on the reprimand document. She combed through it more closely than she had in the past few weeks and saw that Larry added a section titled, Raw Material Rework & Waste. “What is this?” Samantha asked herself. She went on to read the report, “each plant has had a remarkable spike in waste due to poor raw materials after switching to the new South American supplier, Corpo Corp resulting in 18% of  all finished products requiring rework and 2% of finished products un-shippable and designated as waste.” If this was true, Samantha had a serious problem on her hands. This was a multi-million dollar problem. It could end the career of the plant manager.

Samantha saw that Daniel Ramon, one of her plant managers and a close friend, was listed as a reference on this part of the report. She quickly pulled out her phone and called his personal number.

“Samantha, to what do I owe the pleasure?” Daniel’s booming voice broke through the noise of the factory in the background.

“Hey, Daniel. I’m just reading Larry’s report here and I had a few…” Samantha was abruptly interrupted by Daniel.

“Larry saved our butts, Sam! I tell you, you got an eye for talent! He’s here with that intern from upstairs helping us out! I tell ya’, since we switched to that new vendor, Corpo Corp or whatever they’re called, the materials we’ve been getting in have been shit, Sam! I can’t believe this! Larry is just finishing up over here, do you need him?”

“Finishing up with what?” Samantha’s heart was beating hard.

“He helped us re-organize the plant lay out so we can do re-work without missing our ship dates! Ain’t you know what your boy is up to out here?” Daniel laughed.

“You don’t say… uhm.. No, I’ve been so behind… I was just checking in… honestly, no I haven’t looked carefully at his reports until just now,” Samantha admitted and felt a weight on her chest and she was suddenly felt with grief. She was getting ready to write Larry up, to begin his journey to termination, and he was busy saving her ass. Saving Daniel’s ass.

“That’s okay, Sam. Larry didn’t say much about what’s been going on between you two but I heard through the grapevine. Anyways, I scheduled a meeting with some of the big wigs in two weeks. I want you and Larry to present his results to those penny pinchers up-stairs, you got more pull upstairs than anyone and it’s a good way to introduce Larry to the new CEO. You let them know that switching over to this cheaper vendor is actually costing us money in OT, re-work, and useless product,” Daniel exclaimed.

“Of course, Dan. If you don’t mind me asking? When did Larry first start helping you out at the plant?”

“About three weeks ago, I ‘reckon! That boy came down here on his own for a tour of the plant. Don’t you usually bring the newbies down here? Oh, right. Too busy. Anyways, after about twenty minutes of my showing him the place, he had the audacity to tell me that ‘there’s too much waste.’ Can you believe that, Sam? Lecturing me! ME! ABOUT WASTE! I’m the Six Sigma trainer over here and have been the plant manager for going on eight years! I reckon..” Daniel was known for swearing like a sailor and long winded rants. Samantha quickly interrupted before he could take another breath and continue.

“So he tried to tell you how to do your job?” Samantha interjected with a question.

“Nah, not really… Maybe I was bein’ too defensive with the young gun. I had a busy morning fighting fires and I could tell he didn’t mean anything by it when he started blushing and pulled out his binder and reports from purchasing, payroll and sales. He showed me the data and pointed down to the plant where we had bottlenecks and piles of work building up. He showed me there’d been no increase in sales or large volumes of material from purchasing, but our payroll has gone way up in over-time. I wouldn’t have caught it for another two weeks from now because we’ve been practicing lean and Six Sigma for so long that I usually only need a monthly report anymore,” Daniel lowered his voice and took on a serious tone.

“I dropped the ball on this one, Sam. I didn’t have the feedback loops in place to catch this. We would have been screwed royally this quarter if it weren’t for your boy Larry. We still have to deal with the re-work until we can get our old vendor back, but we’ll have minimal overtime and we should be able to meet all our ship dates with Larry’s re-design. I told sales not to run any discounts so we don’t have any large swings in production just to be on the safe side. We’ll break even this quarter but we need our old vendor back,” Daniel finished.

“Of course, I’ll get with Larry and we’ll make sure HQ knows what’s going on, Dan” Samantha assured her long time friend.

“Thanks, Sam! And hold on to Larry, he’s a rockstar! I’m taking him and that intern out for a few drinks tonight after we wrap-up over here. Meet us at AppleBee’s around quittin’ time if you ain’t got any plans for tonight,” Daniel finished and hung up the phone.

“I’ll be there,” Samantha said quietly to herself. She owed someone an apology.

That evening, Samantha walked into AppleBees. She spotted the two at one of the tall tables in the bar area, but she knew where to look because she could hear Daniel’s loud and booming voice over the chatter that filled the crowded restaurant. She ordered a martini and two more drinks for Larry and Daniel before making her way to the table to join them.

“Sam, I’m glad you made it! I was just telling Larry here about the company barbecue and the finer points potato sack racing!” Daniel boasted with a hearty laugh.

“Dan, are you trying to recruit poor Larry here so you can reclaim that trophy? You know My hubby and I won’t be giving it up this year,” Samantha smiled over at Larry who was looking down at his feet.

Daniel looked over at Larry and then at Samantha who was looking ashamed. He excused himself for a much needed restroom break so the two could have a moment together.

“Larry, I owe you an apology. I’m so sorry for the way I’ve been treating you. You saved us from a disaster,” Samantha met Larry’s gaze as he looked up with an embarrassed smile.

“It’s okay, water under the bridge,” Larry said lightly.

“No, it’s not okay. Just like how Daniel didn’t have the appropriate feedback loops in place to catch the re-work issues, I don’t have the appropriate feedback loops in place to see that there’s something wrong with the way my team is running,” Samantha said with sincerity. “Help me out, please?”

“Okay, then can I give you some honest feedback about some of the anti-patterns I’ve seen?” Larry asked tentatively.

Samantha hadn’t heard that term in a while. Anti-patterns was something she remembered during her Lean training last year but could never think of an instance that it applied to her so she forgot about it. He paused and then went on when Samantha nodded her head and smiled; signaling for him to continue.

“Well, I sense there’s little room for outsiders in your group. When I first joined your team, I felt like I an outsider looking in. The first meeting I was in, there was a lot of inappropriate joking and the team engaged in put downs. I don’t know if I can fit in with a culture like that. I believe it’s important to treat each of my team mates with respect and to act professionally,” Larry went on.

“We all respect each other, Larry. There’s so much trust in our group that we can do that and there’s no hard feelings,” Samantha countered.

“Right, I know that. I don’t mean to imply that the group isn’t tight. It’s obvious you are — but, there’s a consequence when those types of behaviors occur. New people feel like outsiders and communication is effected,” Larry said firmly.

Samantha thought on this and saw his point. “Okay, what else?” Samantha asked.

“Well, I observed that everyone on the team is really wrapped up in their own work. People don’t pair up on work or double check things for each other,”

“That’s only because everyone is so swamped with work. Even I put in late nights and weekends just to stay ahead,” Samantha said matter of factly.

“Right, but taking the time to double check each other’s work ensures quality and protects us from mistakes. Pairing up on projects and special tasks ensures the highest quality of work is produced. It’s just like in the factory. We can churn out product quickly, but if we’re doing rework constantly, then we’re really not as productive as we would like to think. It’s no different in the office.” Larry explained.

“True, but that’s why we have established processes and procedures,” Samantha answered.

“Yea… when’s the last time those were updated or even audited?”

Samantha closed her eyes and thought to herself. She couldn’t recall. She opened her eyes and saw Larry starring at her with a look that said he already knew the answer. “I guess it’s been a while.”

“Right, why do you think I made those changes to that report? It was dated and wasn’t fitting our needs anymore. Always be ready to adopt sensible alternatives to fit your needs; otherwise, you’ll be too busy doing work that isn’t adding value. Or worse, people stop thinking and blindly follow a process,” Larry said softly to soften the feedback.

“But, we spent weeks creating that process,” Samantha recalled working on it when she first took over as the District Manager.

“Simplicity. Focus on the most simple and direct solutions possible. I know it can be hard to kill a process that you worked hard on. But if it’s complex and hasn’t been updated in a while, it probably isn’t really being followed anymore or needs to be removed.”

Samantha started to feel the weight on her chest again. She knew deep down that everything Larry was saying was right. It was all so painfully obvious but she had failed to see it. Even after starring it in the face for so long. She must have been deep in thought because she didn’t notice the server take her empty glass away and return with another drink.

Daniel’s hearty laugh finally snapped her out of her haze and she looked up and saw him returning to their table. She looked back to Larry and smiled. “Larry, I’m glad I hired you. I guess I need to make some changes.”

Larry smiled back, “one step at a time; we’ll figure it out.”

Anti-Patterns Are Hard To Spot… Even When You’ve Been Starring Them In The Face For A Long Time

It’s hard to spot anti-patterns. Mainly because we, as humans, are a collection of past behaviors, our genetics, and the environment which acts upon us. Of course, we’re not just behaving creatures, we feel and think as wellMany times, we are unaware of the secondary effects of our behaviors. We start with a certain intention and behave in ways that are similar to our past; however, there can be unintentional consequences that impede the results we initially wanted. This is an anti-pattern.

Just as Larry explained above, Samantha never intended to foster a team culture that made outsiders feel unwelcome. In fact, she felt her team culture was one of trust. But her new employee was unwilling to speak up for himself. Team members were unwilling to pull themselves away from their work to help out a new team mate. It was clear that everyone on that team, even Samantha, was using the same anti-pattern.

Larry also went on to explain that there is too much work on everyone’s plate. So much so that old processes have not been updated and that the quality of work being produced by Samantha’s team was probably questionable. Did you know that putting more paper in the printer doesn’t make it print any faster? There’s only so much we can do in a given work day, and we should ensure quality is a part of our ever day work routines.

Producing quickly should not be the goal of a team. It’s not efficiency either. It’s stability and effectiveness. How long do you think Samantha was receiving that report without really questioning the quality? Without questioning how effective it was anymore? It wasn’t until Larry came along and started doing things effectively that Samantha even noticed.

Putting more paper in the printer doesn’t make it print any faster. Producing quickly should not be the goal of a team. It’s not efficiency either. It’s stability and effectiveness.

One quality of an effective leader is the ability to prioritize work. Not everything is “priority 1.” That sort of defeats the purpose of the word ‘priorities’ and if that’s your management style… Well, your employee turn over rate is probably high and employee satisfaction is likely low. Just saying. Figure out what’s important and let your team know. Only change the priorities after a business need exists. Command and control the priorities, not the people. People can’t produce quality work if they’re constantly being pulled in multiple directions by several priority 1 projects.

One quality of an effective leader is the ability to prioritize work. Command and control the priorities, not the people.

Anti-patterns are not unique to Agile. Or business. They exist in every day life. They can have an impact on our relationships, finances, diet, and our health. That’s why it’s important to constantly seek feedback. Challenge yourself to get perspectives from the highest level and all the way down in the weeds. Challenge your own perspective and poke holes in your logic. Why do you think so many successful leaders read books? Why do you think they take time to meditate? Or take classes or take up new hobbies? It’s because these kinds of activities shape perspective. They help us learn new behaviors and ways of thinking about the world. They help us spot those anti-patterns. They make us better leaders and people.

I’d love to hear your thoughts on anti-patterns or the ones 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

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

Agile Leaders Understand Customer Service And Culture

The Five Levels Of Conflict

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




Jeffrey Varkonyi: The Skinny On Blockchain

About: Jeffrey Varkonyi

Last week, in my Special Topics in the Current Technical Environment class, we had a guest lecturer named Jeff Varkonyi. Jeff is the founder and CEO of MainLink Blockchain Technologies and describes himself as a Blockchain Technology Consultant — specializing in Initial Coin Offerings (ICOs) and Supply Chain Management. He describes his mission as “to enable and promote blockchain technologies to user in the World Wide Ledger of Value.” 

Jeffrey was kind enough to share his presentation on his own blog at: Varkonyi.com

If you’d like to connect with him, he can be contacted via:

Blockchain – The Decentralized Ledger

Blockchain, as Jeff describes, offers a “paradigm shift from a centralized to a decentralized world.” We currently trust centralized banks and their people to ensure that our assets transfer from point A to point B. An example is when we make purchases at the store. We use a credit card terminal and that transaction occurs across multiple entities. The card terminal processes the transaction by contacting the merchant bank and requests authorization from the issuing bank (our bank). If our PIN is valid and we have the appropriate funds, then approval is sent back to the merchant bank and then to the card terminal and the transaction is completed with a receipt being issued. This all occurs in a few seconds, however, the actual transfer of funds may sit “pending” for a few minutes up to multiple days.

In the blockchain, the only trust that needs to occur is in a fundamental trust in math. If you “believe that 1+1=2” then you can trust blockchain. That’s because the very nature of the technology allows for greater integrity of information. The shift we will see, once blockchain and it’s applications are more widely adopted, is moving from “trusted to trust-less.” We will no longer have a need for centralized entities.

Moving Past The Lip-Service

Okay, I agree. That all sounds really cool, but how does it all actually work? To be honest with you, I’m still trying to wrap my head around the technology and I wouldn’t be doing you justice trying to explain it. Instead, I’ll leave you with two links that I found the most beneficial.

The first video features Bettina Warburg, a political scientist and blockchain researcher, explaining the technology to five different people: a child, a teen, a college student, a graduate student, and an expert.

Blockchain Expert Explains One Concept in 5 Levels of Difficulty |WIRED


The second video explains why blockchains are so special and describes blockchains and how they work.

How Does a Blockchain Work – Simply Explained

Blockchain Is A Platform For New Technologies And Services

I see blockchain as a platform for technology and services — in the same way that the world wide web is a platform for services like Facebook, Twitter, WordPress, etc. Blockchain is the underlying technology for cryptocurrencies like Bitcoin, Ethereum, and Litecoin. Additionally, there are so many more uses and applications for the technology. Here’s a great article I recently read that expands more: 17 Blockchain Applications That Are Transforming Society. 

Share your thoughts on Blockchain 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




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

You Know The Data. What About The Science? An IT Professional’s Primer To Data Science

Data Science: Business Meet Science

Nearly all IT professionals can explain “data” and how it lives, however, what about the “science” part? Do you know enough about Hypothesis Testing? Falsifiability? P-values? If not, that’s okay, IT Professionals, meet science.

Falsifiability: The Sun Will Explode At The End Of The Month

Falsifiability is the assertion that for any proposed explanation made on the basis of limited evidence, must be inherently disprovable before it can become accepted as a scientific theory.

Where “no theory is completely correct, but if it can be shown both to be falsifiable and supported with evidence that shows its true, it can be accepted as truth” (Shuttleworth & Wilson, 2008). This means that an idea is falsifiable if it can be true and observed.

Example: “The sun will explode at the end of the month.” This is not yet been falsified because it’s a future prediction. However, we can begin making observations and as the date draws closers, we can observe if the sun will explode or not and falsify the claim. Hopefully! (In the case of Einstein, it was a solar eclipse. +1 if you knew this).

In science, we “make claims or statements about a property of a population” (Triola, 2015) which we call a hypothesis – again, it must be inherently falsifiable. Our hypothesis is tested by using a model and we attempt to disprove our models. Our models are not truth; rather, considered evidence to support our claim about the population.

Testing The Hypothesis

Making Claims: The Null And The Alternative

Again, we are attempting to make claims about a property of the population(s) we are studying, however, we do not have the ability, except in very rare circumstances, to know the true properties of the population(s) in question. This is why statistics and a rigorous set of procedures is used to help scientists. This is why we perform hypothesis testing.

The process is simple and repeatable. The first step is to create a set of claims to be used – the Null Hypothesis (Ho) and an Alternative Hypothesis (H1).

The Null Hypothesis is the assumption we are making about the population. Maybe we’re saying, “There is a 50% chance of landing heads in a coin flip.”

The Alternative Hypothesis states that the model we are testing is different from the Null (Ho). If we’re skeptical of the coins produced in 1987 and claim they have a tendency for heads then we might say, “There is a greater than 50% chance of landing heads in a coin flip.”

This would look like:

(Ho): p = 0.5 (Null Hypothesis)

(H1): p > 0.5 (Alternative Hypothesis)


Next we want to select the Significance Level  (alpha) based on the seriousness of error. We call this a Type 1 error – where we mistakenly reject the Null Hypothesis when it is actually the correct hypothesis. Using the example above, we would be saying, “Coins produced in 1987 have a tendency for heads” when, in reality, there’s nothing wrong with the coins.

You might be asking yourself, “if we can’t accept the Alternative Hypothesis, do we accept the Null Hypothesis?” Unfortunately, no we can’t. Remember, our assumptions about the population are impossible to know and our Alternative Hypothesis is being used to help provide evidence for our original claim. Again, we are creating a model to assess if there is evidence to reject our assumption of the population.

Is that confusing? I hope not, but one metaphor I find useful is a courtroom and the rule of ‘innocent until proven guilty beyond a reasonable doubt’… let’s say with 95% certainty. If there is “evidence presented that doesn’t prove the defendant is guilty, you have not proven that the defendant is innocent; but, based on the evidence, you can’t reject that possibility” (Martz, 2013). Our job is to prove the model of being guilty beyond a reasonable doubt.

Most hypothesis tests use a Significance Level (alpha) of 95%. Scientists are saying, “we need to be confident by 95%, however, we accept the risk of rejecting the Null Hypothesis when we really shouldn’t by 5%.” This accounts for the Type 1 error discussed above.

Test statistics and p-values

There is no single test statistic that can be used for all applications. However, the test statistics are generally measuring how far things are falling away from the mean (aka “the average”). When things are falling further away from the mean then they are not conforming to the norms of the population that we assume in our model. If we are flipping coins from 1987 and the average flips landing on heads is somewhere around 80%; but coins from other years are closer to 50% then our test statistic would show that 1987 coins are several deviations away from the average population of all coins flipped.

In a normal distribution, 95% of all observations are within 2 standard deviations of the mean. This means if we got a test statistic, like a t-score, that is 3.25 then we are approximately 3 standard deviations away from the mean. That’s important because it helps us decide if we are going to accept our Alternative Hypothesis (and 3.25 standard deviations away from the mean is a pretty big deal). 

The next thing we want to look to is the p-value. When our observation is several standard deviations away from the mean, the p-value is the probability of getting another observation that is as contradictory as the first in our model. Generally, when the p-value is less than 0.05, we know we’re in good shape, due to the level of risk we assumed for a Type 1 error.

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


Aschwanden, C. (2015, November 24). Not Even Scientists Can Easily Explain P-values. Retrieved February 2018, from FiveThirtyEight: http://fivethirtyeight.com/features/not-even-scientists-can-easily-explain-p-values/

Aschwanden, C. (2015, August 19). Science Isn’t Broken. Retrieved February 2018, from FiveThirtyEight: https://fivethirtyeight.com/features/science-isnt-broken/#part1

Aschwanden, C. (2016, March 07). Statisticians Found One Thing They Can Agree On: It’s Time To Stop Misusing P-Values. Retrieved February 2018, from FiveThirtyEight: http://fivethirtyeight.com/features/statisticians-found-one-thing-they-can-agree-on-its-time-to-stop-misusing-p-values/

Becker, K. (2015, February 11). Does Science Need Falsifiability? Retrieved February 2018, from PBS: http://www.pbs.org/wgbh/nova/blogs/physics/2015/02/falsifiability/

Martz, E. (2013, January 30). Bewildering Things Statisticians Say: “Failure to Reject the Null Hypothesis”. Retrieved from The Minitab Blog: http://blog.minitab.com/blog/understanding-statistics/things-statisticians-say-failure-to-reject-the-null-hypothesis

Resnick, B. (2017, July 31). What a nerdy debate about p-values shows about science — and how to fix it. Retrieved February 2018, from Vox: https://www.vox.com/science-and-health/2017/7/31/16021654/p-values-statistical-significance-redefine-0005

Shuttleworth, M., & Wilson, L. T. (2008, September 21). Falsifiability. Retrieved February 2018, from Explorable: https://explorable.com/falsifiability

Triola, M. F. (2015). Essentials Of Statistics 5th Edition. Boston, MA, USA: Pearson Education, Inc.


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

Scrum Product Owners Part 2

The Product Owner Chooses Business Value

As the “single wring-able neck,” the Product Owner is tasked with maximizing business value and setting the direction for a new or existing product. She shares the guiding view into the future and collaborates with customers, stakeholders, technical teams, and supporting roles to steer the product to the desired end-state. In this article, I would like to share my favorite two value areas that effective Product Owners understand.

  1. Customer Service
  2. Operational Efficiency

1. Customer Service

An organization is nothing without it’s customers — they are either external or internal customers. Customers are the people who use the product to fulfill a specific need. A product that is easy to use and accurately fulfills a customer’s needs is valuable to the organization. Design considerations like User Interface and User Experience need to be considered when crafting user stories, however, the main consideration is, “how are we best serving our customer with this feature?” 

External Customers look to “exploit artefacts[sic] produced by the organization with specific requirements and specifications” (Hobbs, 2016). External customers are essential to the success of the organization as it operates to produce the artifacts specified by external customers.

Internal customers are all members of the organization who rely on assistance from each other to fulfill their duties in the production of artifacts specified by the external customers.

“If you build a great experience customers tell each other about that. Word of mouth is very powerful.”

— Jeff Bezos, Amazon

2. Operational Efficiency

An organization is unable to best serve it’s customers if it’s inefficient. While running the air conditioning in the middle of winter is wasteful, Product Owners go beyond the obvious to make operations more efficient. Below is a list of operational efficiencies in a ‘lean’ context that Product Owners should consider in their user stories. Product Owners should start with, “how does this feature improve our operations or reduce waste?”

  1. Reducing defects – features aimed at reducing defects strive to reduce errors, mistakes, rework, and preserve data integrity of internal and external customers.
  2. Reducing motion – features directed at reducing motion strive to automate a formerly paper-driven process. This helps improve efficiency and standardizes the quality of those processes. Additionally, frees up resource capacity so internal customers can engage in more technical work.
  3. Creating a common language – features sighted on centralizing information in a common place creates a lexicon synonymous with the organization. It simplifies the way information is shared and understood throughout the organization. Internal customers are all speaking and sharing the same meanings and when extended to client-facing applications, external customers speak the language too.
  4. Improving decision making – features trained on increasing transparency allow internal customer to make decisions quickly — ultimately helping organizations exercise business agility and ‘pivot’ when the internal or external environment prompts for it. 

Leave your thoughts on Product Ownership or Business Value 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


Hobbs, B. &. (2016). Projects with internal vs. external customers: An empirical investigation of variation in practice. International Journal of Project Management Volume 34, Issue 4, 675 – 687.

Related Posts

Scrum Product Owners Part 1: The Product Owner Steers The Ship

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

Six Elements Of An Effective Strategy

Agile Leaders Understand Customer Service and Culture 




Scrum Product Owners Part 1

The Product Owner Steers The Ship

The Product Owner can be described as the “single wring-able neck” in Scrum. They are responsible for maximizing value and setting the direction for a new or existing product. They work with development teams, stakeholders, groom & prioritize their backlog, and share a guiding view into the future. The Product Owner is the most important role in the organization and only a special kind of person volunteers for it. The rest are usually ‘volun-told.’

Intention and style shape the effectiveness of a Product Owner. Like all of us, Product Owners come from different backgrounds or roles. Angela Druckman, of the Druckman Company has a wonderful series on Product Ownership and I have personally worked with her and attended her Certified Scrum Master and Certified Scrum Product Owner courses during our Agile Transformation at the Nevada Department of Transportation.

As a coach, we don’t want to make assumptions about the anti-patterns our Product Owners may have inherited from their previous roles.

“An anti-pattern is something that looks like a good idea, but which backfires badly when applied.”

-Jim Coplien

Never assume that an ex-project manager uses “command and control” with their teams or that ex-business analyst will struggle with emotional intelligence. Leave all judgement to Judge Judy. Your job as a coach isn’t to fix anti-patterns. It’s to tap into people’s potential. Anti-patterns will extinguish as each person’s potential is unlocked and the agile mindset becomes a part of who they are. 

Captain & First Mate: Product Owner & Scrum Master

The first thing I want to stress is the relationship between a Product Owner and Scrum Master. These two roles, when combined with the Delivery Team, are a lot like a Project Manager and Delivery Team. Let’s take a 30,000ft view of the 10 Knowledge Areas of Project Management and see where the Product Owner and Scrum Master have responsibility in regards to traditional project management and its’ relation to iterative product development.

  • Integration Management
    • Traditional: This responsibility falls onto the Project Manager via a Work Breakdown Structure (WBS) and Gantt Charts.
    • Scrum: This responsibility is shared among the Delivery Team, Product Owner, and Scrum Master via collaboration and iterative development.
  • Scope Management 
    • Traditional: This responsibility falls onto the Project Manager and Change Control Board via the Scope Baseline and Change Management Process.
    • Scrum: This responsibility is the Product Owner’s via collaboration with stakeholders, prioritizing business objectives, and the product backlog.
  • Cost Management
    • Traditional: This responsibility falls onto the Project Manager via the Cost Baseline, budget, and Change Management Process
    • Scrum: This responsibility is the Product Owner’s via iterative delivery, business objectives, and budget.
  • Time Management (formerly Schedule Management)
    • Traditional: This responsibility fall onto the Project Manager via the Schedule Baseline, critical path, and Gantt Chart.
    • Scrum: This responsibility is shared among the Delivery Team and Product Owner via iterative releases.
  • Quality Management
    • Traditional: This responsibility falls onto the Project Manager and delivery team via Quality Assurance (QA), Quality Control (QC), and User Acceptance Testing (UAT).
    • Scrum: This responsibility is shared among the Delivery Team, Scrum Master, and Product Owner via Quality Assurance (QA), Quality Control (QC), Sprint Reviews with stakeholders & Product Owner, Scrum Master resolving impediments during the daily stand-up, and Agile Retrospectives.
  • Procurement Management
    • Traditional: This responsibility falls onto the Project Manager and stakeholders via the organization’s Project Management Office procurement Policies, Processes, and Procedures
    • Scrum: This responsibility is not defined in Scrum, however, the organization’s Policies, Processes, and Procedures should be followed. A Scrum Master or  Product Owner should work closely with the Project Management Office.
  • Stakeholder Management
    • Traditional: This responsibility falls onto the Project Manager via the stakeholder management plan.
    • Scrum: This responsibility is shared among by the Product Owner and Scrum Master. The Product Owner elicits requirements from stakeholders and the Scrum Master insulates the Delivery Team so they can focus on the product.
  • Communication Management
    • Traditional: This responsibility falls onto the Project Manager via the communication plan.
    • Scrum: This responsibility is shared among the Delivery Team, Product Owner, and Scrum Master. The Delivery Team meets daily and communicates progress and impediments. The Product Owner manages stakeholder expectations. The Scrum Master can assist with managing stakeholder expectations, facilitates the Daily Stand-up, Sprint Planning, The Sprint Review, The Sprint Retrospective, and coaches the principles of Agile to everyone in the organization.
  • Resource Management (formerly Human Resource Management)
    • Traditional: This responsibility falls onto the Project Manager via the Resource Management Plan.
    • Scrum: This responsibility falls onto the Delivery Team and Scrum Master via iterative planning sessions, capacity planning for each iteration, and relative estimation and using past performance to forecast velocity.
  • Risk Management
    • Traditional: This responsibility falls onto the Project Manager via the Risk Register, Risk Management Plan, and Contingency Reserves.
    • Scrum: This responsibility is shared among the Delivery Team, Scrum Master, and Product Owner. The Delivery Team and Scrum Master use retrospectives to address risk and improve how they work. The Product Owner sets the guiding view into the future, sets the priorities for each iteration via the backlog, and makes informed decisions based on the technical expertise of the team and the strategy of the organization.

While the above is a high-level, “vanilla,” list of the shared responsibilities and activities, it illustrates my point. The Product Owner and Scrum Master are a lot like a Project Manager split into two roles. This allows them to share responsibilities and specialize in select areas — making them more effective and increasing the chances of success. As a coach, we need to make sure these two stand as a united front. The Product Owner steers the ship and the Scrum Master is the first-mate.

Leave your thoughts on Product Ownership, Scrum, or Project Management in a comment below or if you’d like to have a discussion, please contact me or connect with me on social media!

Photo Credit: Pixabay

Related Posts

Improving Agile Retrospectives with SMART Goals