Three Reasons Driving The Performance Management Revolution

Last year on my lightly-viewed LinkedIn blog, I wrote a short post proclaiming 2015 as the year of performance management reform – this was after several years coaching in organizations that had an urgent need to evolve into an Agile environment, but continued to drive traditional (and conflicted) performance management & reward/punish appraisal programs through their respective HR departments.

Fast-forward over a year later. We are witnessing the growing momentum for a revolutionary overhaul – especially in knowledge-work organizations. The most recent treatment of this subject is in the October 2016 Harvard Business Review piece entitled The Performance Management Revolution. Consider setting aside some focused time to dig deep into this article, as I found it quite valuable — especially as it directly references the Agile Manifesto within the context of coaching & feedback, the need for frequent learning & growth, and other aspects that optimize for business outcomes in a complex world.

Why Drop Traditional Performance Appraisals?

Three explicit business reasons are shared in the article:

  • The return of people development – With talent now in short supply, optimizing hiring practices and attracting “growth mindset” oriented professionals is key. These are people who have a strong desire for continuous learning, candid feedback and mentorship. Companies must offer strong development opportunities to attract this type of talent.
  • The need for Agility – In today’s world, annual (or bi-annual) performance appraisal “reviews” are not frequent enough to adapt and optimize an organization based on changing business conditions.
  • The centrality of teamwork – Shifting away from appraisals and emphasizing accountability helps foster a team-based behaviors. The article shares experiences from Sears and Gap — two companies that are surprising innovators in performance management.

The case seems strong enough, but there are implications to an overhaul – including goal alignment, rewards, how to identify ‘poor performers’, and the potential for subjective and biased performance assessments. The article discusses these issues, the research, and how some companies are dealing with it.

In Closing

What is the performance management system like in your company? Do you need an overhaul to optimize for people growth, agility and teamwork? What experiences can you share?


If my writings resonate with you, please consider spreading this message so we can energize and inspire the entire professional world together. I invite you to ‘Follow’ my professional journey through LinkedIn. I am also on Twitter.

Are You a Manager or an Enabler?

Are you a Manager that believes in this whole Agile thing? There is a difference between thinking, believing and knowing. Don’t miss out on a huge opportunity to become the next market leader in your space. It’s time to understand your role and how it needs to change in order to survive in a creative economy, and it starts by transforming your mindset from Manager to Enabler.


At the turn of the century, I was a proud and young Manager. I had the job title, a ‘corner office’, people reported to me, and life was good. I was entrusted to manage a lot: people, projects, programs, customers, company strategies and the like. But I could tell that something wasn’t right with the world. What was it?

At the time, I couldn’t put my finger on it, but the signs were deceivingly clear and compelling. Experience a few pieces of painful evidence from my own 360 feedback around the Y2K period, which looked something like this:

  • Subordinate: He is a good Manager and very smart, but he doesn’t trust us.
  • Superior: He is an extremely hard-working Manager, but needs to improve his ability to “drive the teams and the results” to customers.
  • Peer: (blank)
  • Self: (???)

Clear as mud, or clear as crystal? Was I a Manager or an Enabler? What did the organization want me to be?

Transforming from Manager to Enabler

It took some time for me to fully process and understand this feedback, but I eventually had a breakthrough moment that launched my own professional transformation. If you are a Manager who lives in a bureaucratic and controlling company hierarchy, then you might be receiving similar feedback.

Are you ready for your own breakthrough moment? Is this YOUR time? If so, then consider embarking on a challenging and rewarding personal journey from Manager to Enabler. If you are able to transform from a Manager to an Enabler, then great Agile leadership ability will be attainable for you.

Welcome to the innovation economy – where Enablers allow their organizations to effectively compete and succeed in a turbulent and relentlessly-changing marketplace.

I offer a few introductory questions as a thought provoking tool to evaluate your professional frame of mind. These are just some questions – I invite you to think about the answers for yourself. Write them down on sticky notes and take some time to think about each one. Use situational awareness as you reflect on each of these questions and what they mean to you, your teams, your organization, your customers and your competitors.

This is not a formal assessment tool and you won’t receive a chart or graph that explicitly tells you whether you’re a Manager or an Enabler. But I assure you that if you invest some time to think about these questions, you’ll start to understand where you are now and if a journey from Manager to Enabler is right for you. If you’re already an Enabler, then you might be ready for an even more fulfilling journey into great Agile leadership.

Are you a Manager or an Enabler?

How does it feel to coordinate a large group of people and own the results of their work?

Do you enjoy being the go-to person for the answers? Do you pride yourself on being the source of business and technical knowledge in your company?

If you’re a people Manager, what does it feel like to invest in those people? Could their own professional growth and autonomy threaten your position in the company?

What does the concept of self-organization mean to you?

Are these 5 secrets of enablement new or foreign to you?

Does “work” feel like work to you and others in your organization? What would it mean for work to be fun?

Is money the motivator for you and others? If not, what is the motivator for you and others in your organization?

As you work through this on your own, read the beginning of this article again and try to answer these questions from the perspective of the young Manager. This will test your sense of empathy, which is a powerful component of great Agile leadership. What were my answers back in Y2K? What do you think my answers are now?

Are you a Manager or an Enabler? Share ‘your answer’ in the comments section below.


If my writings resonate with you, please consider spreading this message so we can energize and inspire the entire professional world together. I invite you to ‘Follow’ my professional journey through LinkedIn. I am also on Twitter.

7 Ways to Boost Your Ability as a Team Member

Where do you spend your days in the workplace? Are you living in the trenches of your organization, like the vast majority of us? If so, then I celebrate *you* — as a real Team Member — the person who does the actual work that delivers value for your business.

Allow me the humbling honor to present this Kudo Card to you and your Teammates for a job well done in 2015!



So much blogging is about leadership and how to become a great “leader”, and ‘leader this leader that’, so let’s shift gears for a moment and talk about the workplace reality for the vast majority of us, which lies in the art and skill of being a great Team Member in the trenches.

How many of us actually live in the Fortune 500 C-Suite anyway? Instead, we are the ones who live in the trenches of an organization and do the hard work needed to meet a critical set of business objectives that are borne out of the C-Suite. And doing this well requires all of us to act less as individuals and more as Team Members. But what does this actually mean?

Is your annual performance review coming up?

In fact, as we approach our end-of-year annual performance reviews, consider turning the table on this often soul-draining meeting by offering your manager a valuable set of learnings about great Teamwork and what it means to add value in your organization. The meeting could transform into a meaningful feedback exchange that helps you and your manager learn and grow together as workplace professionals.

What is the difference between an individual and a Team Member?

Showing the strength, humility and confidence as a Team Member isn’t as easy as it might sound. It takes a lot for someone to transform from an individual contributor and into a real Team Member. Sure, I could sit in an office cube all day and code apps by myself, but the reality is that we work on much larger and complex projects that require me to work effectively on a Team. Great Teamwork becomes even more essential when my Team has to collaborate and integrate with other Teams in the organization. Does this describe your workplace?

The following are seven recommendations that I offer individuals to help them grow into high performing Team Members. These suggestions represent growth opportunities for many of us, as it requires skills and emotional awareness to develop into a collaborative, cross-skilled and authentic Team Member.

As you read through each suggestion, try pausing for a moment and ask the following self-reflective questions in preparation for your annual performance review:

Where am I on the Team Member spectrum?

Where do I see opportunities for personal Team Member growth heading into next year?

1 – Show Vulnerability in Front of Your Teammates.

To become a great Team Member, we have to feel comfortable in our own skin, which includes admitting our weaknesses and shortcomings in front of our Teammates. As a Software Developer myself, I had days where I was just plain stuck and frustrated. I would look at a piece of defective code and couldn’t figure out the root of the problem. However, I wouldn’t just sit there and stare at my computer screen all day in defeat – I would reach out to a fellow Team Member, admit my frustration, and ask for help. Oftentimes, two heads are much better than one when solving a problem, and it’s okay to let your guard down if you’re struggling. Plus, when you’re willing to be vulnerable, it encourages your Teammates to follow suit.

If you have downtime over the holiday season, then I strongly recommend reading Brené Brown’s Daring Greatly. It’s a life changing book that helps each of us discover the power and strength when being vulnerable in front of others.

2 – Accept That You’re Going to Fail.

In a recent post about failure, I shared a real story about a Team Member who experienced a visible and costly moment of failure on a software development project. Look – we’re ALL human and we make mistakes all the time. This might sound cliché, but a great Team Member accepts responsible failure as a reality and uses every failure as an opportunity to learn and grow. In addition, great Team Members understand that our fellow Teammates are also going to experience failure, so we must handle those situations with respect and compassion by offering a helping hand – all in the interest of learning and growth.

3 – Be Honest About Who You Are.

Don’t be someone you’re not. For example, you are not the invincible-hero Software Developer who has all of the answers to every software development challenge. You are a real person who offers skillfulness and passion to help solve tough problems directly with your Teammates. Authenticity (i.e., your ability to be real and genuine) allows your Teammates to feel comfortable being authentic and real as well. If you walk into the office with more energy than usual, show it! Or if you’re feeling sluggish on a Wednesday, admit it to your Teammates, so they can help you through the day. Great Teams ooze authenticity, which allows the Team to adapt and optimize its performance every single day.

4 – Don’t Accept the Status Quo.

Great Teams constantly (and respectfully) challenge the larger organization to change and improve for the Teams’ benefit. As a Team Member, you can lead the charge by taking ownership of a difficult organizational issue and facilitate a broader conversation that shines the light on the issue, the impact it has on your Team, and ideas for how to solve for it.

No more ho-hum: “This is just the way things are going to be and nothing will ever change” attitude.

To evolve into a great Team Member, you have to be willing to respectfully & politely challenge the status quo and show some leadership for the organization’s benefit. Leadership is not a job title – rather, it’s the ability to inspire and influence positive changes that align with the vision and mission of your organization. You can do this!

5 – Stop Trying to Reach Consensus on Decisions.

Teams make countless numbers of decisions every single day. Software Development Teams, for example, make decisions on clean-code policies, design choices, ownership of work, etc. However, be wary of consensus-based decision protocols. If every Team Member has to completely agree with a decision to move forward, then your Team could get locked in consensus paralysis and endless debates.

Instead, learn how to make decisions using consent, which allows every Team Member’s voice to be heard and genuinely considered, while not having to completely agree 100% with the decision. In consent, I know that my opinion matters, so I am willing to support a decision and live by it (even if I don’t completely agree with it). This technique allows great Teams to make decisions faster and with the collective intelligence of the entire Team.

6 – Demand Clarity.

As a great Team Member, tune your communication skills so you can help establish clarity behind the Team’s goals and decisions. Teams often falter when they realize they’re lacking clarity (uhhhh, what did we decide again??), and this can hamper the pursuit of high performance.

Instead, show some leadership as a Team Member by carefully articulating a goal, a decision, etc. in clear and well-understood language for everyone to consume. Make sure this clarity is made visible and transparent for the entire Team (on a wall or in the electronic tools you use for managing content). This is how a shared commitment works in a great Team. For example, I can’t commit to a certain Team ritual unless we all have clarity on what it is, when it’s held, and most importantly, “why” it’s essential for reaching our goals together.

7 – Stop Passing Judgment.

Truly genuine Team Members bring an open-minded stance into the workplace, which makes you more approachable by your Teammates. If I’m on your Team and you’ve already formed a (negative?) opinion about me, then you won’t be willing to listen when I come to you with a thought or idea.

Your ability to have an open mind is an essential and necessary dynamic in a high performance Team environment. How approachable are you if you constantly assume that your Teammates ideas aren’t as good as yours? To rid yourself of Team-destructive judgment, you must be willing to look at everything through the eyes of your fellow Teammates. You don’t have to completely believe what others believe, and you might even be offended by how another Team Member is behaving, but that doesn’t mean that you have to assume and judge that person indefinitely.

Rather than passing judgment, open your mind long enough to understand how that Team Member thinks, which will drive productive and non-judgmental conversation that helps that Team Member, and the whole Team, learn and grow together.


In Closing

What opportunities do you see for yourself to grow into an outstanding Team Member? What other qualities do you feel makes a person a great Team Member? Please share your thoughts in the comments section below so we can all learn from each other.



If my writings resonate with you, please consider spreading this message so we can energize and inspire the entire professional world together. I invite you to ‘Follow’ my professional journey through LinkedIn. I am also on Twitter.

6 Tips For Mastering Workplace Courage

Have you ever been in a situation where you were afraid to share a difficult, but truthful statement? Was “the obvious” in the room the whole time, but no one would speak up and talk about it? If so, then the time has come for your organization’s leadership to embrace the importance of workplace courage.

Organizations that appear Agile and responsive on the outside usually have inspiring leadership dynamics on the inside. One essential behavior is when senior leaders support the role of courageous communicators. These emerging workplace leaders bring a mastery of skills and emotions to bear when circumstances are difficult and will surface the “hard truth” that is necessary for the success (or perhaps survival) of the organization.

For a culture of courage to thrive, however, an organization’s senior leadership must be supportive of open and honest behavior in the workplace.

What do you think of this courageous situation?

What if a software company ships a broken feature to your smartphone prematurely and it causes you (the customer) a big headache. Application Developers might have known that the quality was suspect, but perhaps they felt management pressure to ship it because of a competitive threat or a customer obligation. Or even worse, maybe the Developers have a financial bonus that will only be awarded if they ship the feature immediately.

If you were a Team Member in this situation, consider the answers to these questions:

How would this management pressure make you feel?

How would your fellow Team members feel about all of this?

What is important to both the Team *and* Management in this situation?

How can you be truthful to management without getting in trouble, losing your bonus, or getting fired?

This situation can be avoided with Courageous Communication. Perhaps someone would respectfully and calmly step up to senior management and say something like:

I feel like the management approach is forcing us to do something that could be damaging to our customers and our company’s reputation. This feature doesn’t meet our mutually-agreed standards of quality and completeness. If it isn’t “done”, what will happen if we ship it now?

What is Courage?

Courage is a profound value of great leadership, but it requires skillful communication, emotional awareness and a degree of professional safety to be effective in the workplace. Let’s use an abbreviated definition from Wikipedia to dive a bit deeper:

Courage – the ability and willingness to confront fear, pain, uncertainty or intimidation.

I’ve seen many great moments of courage unfold in the workplace, especially in organizations that experience a breakthrough moment in the pursuit of higher performance. Someone steps up and makes a truthful (and possibly painful) statement, but at the same time, this person fosters alignment from everyone and creates a better outcome for all. Have you ever seen this play out in your organization?

Try practicing with this situation

Okay — let’s try this one out:

Imagine you’re invited by a Team to observe a critical lessons-learned meeting at the end of a 3-week software delivery effort. This meeting, called a Retrospective, is part of The Scrum Framework – it’s where a Scrum Team inspects its own ‘ways of working’ and examines its performance for improvement opportunities. It can be a powerful learning event if the conditions are healthy, but sometimes, it becomes another wasteful meeting where nothing is accomplished. In a productive Retrospective, Courageous Communication is critical.

As you are observing as a fly-on-the-wall, the servant-leader of the group (called a Scrum Master) intentionally breaks (or bends?) an important rule of this event & invites senior technology managers to participate, so that the Team’s performance can be “evaluated”. You sense that the environment is uncomfortable for the Team, so when it’s time for the Team to examine its own challenges, the room becomes eerily silent – you could drop a pin on the floor. The managers break the silence with feedback: “We have evaluated each Developer’s performance and here’s where you all can improve ….”

<silence gripping the room>

Now what? Where’s the real leadership in the room?

Out of nowhere, a leadership moment emerges from one of the Team Members that sounds like:

I feel like we all understand the importance of this work and the impact it will have on our company’s success. However, I am afraid to admit that none of us understands how The Scrum Framework is really supposed to work. To be successful, we must acknowledge this and commit to a better understanding of Scrum and how we can all work together for a great outcome.

This person goes on to share the issues with an individual-driven performance evaluation process and how it is putting the Team on the defensive. Suddenly, the other Team members come out of their shells and nod their heads in agreement. This person even admitted a fear of being fired right on the spot for honesty, but felt that it was the right thing to do for the organization.

Wow … I mean … Whoa.

That incredible moment of courage shattered the current reality for the managers, but it opened the door for a shared understanding of the real problem (judging individuals), so they could move forward in the right way (empowering and trusting the Team). It changed everything for this Scrum Team’s performance and the relationship with senior management.


6 Tips For Mastering Workplace Courage

This type of communication isn’t easy, but with practice, you can elevate your own leadership ability and exemplify courage to benefit yourself and others around you. Here are a few tips to consider as you examine your own capacity for courage:

1 – Establish a mutual purpose with everyone.

When you’re presented with a fearful situation, first communicate the purpose or goal that’s driving your need for honesty. For example, if we all care about delivering an outstanding customer experience, then we should be willing to accept your thoughts and views (no matter how difficult the truth might be to accept). In addition, if you confirm mutual purpose with an open-ended question, then it encourages open dialogue from others. Silence can also be quite telling, because it could mean that someone does not share the same purpose that you do (e.g., someone’s upcoming job promotion might be more important to them than delivering quality Product to customers).

I’ll sometimes start a difficult conversation with something like: “Since the quality of the Product is of urgency to us and our customers, then I feel that I must share the <reality>. How do others see this?”.

2 – Be open and honest about your own fears.

Courage requires a leader to be vulnerable in front of others. If there is something about the situation that scares you, be honest and say it — respectfully. If you do this, you will help others feel safe to speak their own views in an honest and open manner.

3 – Do not judge.

Read through the example above (again). Notice that the person did not point fingers or verbally attack anyone. Rather, this individual took a non-judgmental stance and did not blame the stakeholders. Point a finger at an issue and not at a person. If it’s a sensitive conversation with your manager, point a finger at your fears and the behaviors that are making you feel that way. Then, seek a common purpose between both of you (see Tip #1), so you can open the door to a fruitful dialogue.

4 – Stay calm.

Don’t let emotions get the best of you. I have seen many situations where someone tried to show courage in the workplace, but emotions were out of control and everyone tuned out. A Courageous Communicator can state “the obvious” in a calm and seasoned manner that helps everyone accept the reality and move forward.

5 – Don’t wait.

The worst thing you can do is go silent and wait until later. If a situation has escalated and the “hard truth” needs to be understood by all, then a great leader will step in on the spot and communicate the truth and foster alignment. The time is now, not later. Just make sure your skills and emotions are in check first.

6 – Encourage and celebrate moments of courage from others.

Courageous Communicators are influential leaders that live in all levels of an organization. Be on the lookout for well-timed and skilled moments of courage, and if you witness courage in action, show some appreciation and praise it! This is a demonstration of your own leadership when you celebrate and encourage others to be courageous in the right way.


Are you a senior leader who just read this post?

If so, then Courageous Communication starts with your willingness to lead by example. If you embody this value within your organization, then you will encourage a healthy environment of professional safety where people are completely comfortable to be open and honest when it matters most. If you don’t, then you will hear what you want to hear, but it might not be the truth that you need to make effective business decisions. Agile leaders constantly reflect the mirror on themselves in an effort to continuously learn & improve. Are *you* a Courageous Communicator? Are you fostering a culture where courage is valued?

Have you witnessed Courageous Communication in action recently? What was it like? I invite you to share your experience in the comments section below.


If my writings resonate with you, please consider spreading this message so we can energize and inspire the entire professional world together. I invite you to ‘Follow’ my professional journey through LinkedIn. I am also on Twitter.

5 Beliefs Every Agile Journey Must Avoid

What are the beliefs that are guiding your organization’s Agile journey? As you’ve probably witnessed, those underlying beliefs influence how people behave on a daily basis, and when they are well aligned with Agile principles, then the pursuit can prove quite beneficial. When there is a stark misalignment, flawed beliefs in Agile can (and will likely) result in a challenging pursuit and even a failed Agile adoption.

What have you experienced in your organization?

High performance Agile organizations share a powerful and principled belief system that leads to increased value, innovation, vibrancy and a healthy element of delivery predictability within the workplace. I’ve also found that these inspiring companies are able to identify and address flawed Agile beliefs that introduce friction against the organization’s pursuit.

Here are a few that I’ve seen play out in a number of organizational contexts:

5 Beliefs Every Agile Journey Must Avoid

Belief #1 to Avoid

We need to compare waterfall and Agile to see which is better.

This belief can lead an organization down a fruitless path of endless opinion-littered debates that waste time, money and energy. When an organization has a sense of urgency for change, then it must invest its resources into changing, not trying to compare and prove that one approach is better than another. Besides, an organization can quickly examine a number of publicly-available comparisons that are available for review and learning.

To better understand the comparison of business outcomes between sequential delivery (waterfall phases with delivery at the end) and Agile (iterative, incremental, continuous value delivery), consider turning to insight-filled works like The New New Product Development Game, this flexible vs. sequential development approach study, and the latest research from The Standish Group. The groups behind these studies have done all of the hard work of comparison for us. Use the conclusions in these (and other) works to decide if an Agile Journey is the right pursuit for addressing your organization’s sense of urgency.

Belief #2 to Avoid

Agile Teams must ‘commit’ to their User Stories at the beginning of a Sprint.

I once encountered a skeptical manager who told me something like: “I believe that *my* Teams must deliver all the User Stories that are ‘committed’.” Careful  … this is a dangerous belief that often leads to challenged business outcomes. When I first encountered this supposedly “Agile” setup, I quickly discovered that the manager was pressuring the Teams to make scope commitments each Sprint. In this situation, no one actually committed to anything except for the manager (who, under organizational pressures, made an unrealistic promise on the scope).

Not only were the Teams consistently falling short of the “commitment” (thus deteriorating Team morale and eroding the predictability element of Agile), the evolving Product was littered with increasing numbers of defects and mounting technical debt.

How do you see this? Is it a recipe for Agile failure?

This flawed belief is in direct conflict with the 3rd value statement from the Agile Manifesto:

Customer collaboration over contract negotiation

In Agile Teams, commitment is a shared value between Team Members —- not a rigid contract between the Teams and management. Once this is understood, it opens the door toward a goal-oriented way of working.

What’s so great about Goals?

In Scrum, for example, Teams craft and strive to meet a clear short-term business Goal each Sprint, which informs mid and long-term Roadmap Goals – all with full alignment to the Vision of the Product (or Project or Program – depending on your organization’s terminology). Goals introduce an element of flexibility, which guides Teams to deliver meaningful and valuable business outcomes on a consistent (i.e., predictable) basis. Most organizations tend to click the “like” button on this delightful rhythm – customers, users, business stakeholders, technology stakeholders, and the great Teams that are empowered with delivery responsibilities.

Continuing on the Scrum example, Teams share a commitment to each other to operate and behave in a way that maximizes their chances of reaching these Goals. When commitment is embraced as a value, then Teams are much better positioned to consistently meet the incremental Goals that ultimately realize the Product’s Vision.

How do you feel about this?

Belief #3 to Avoid

Agile Teams do not have fixed constraint contracts.

We should not confuse Disbelief #2 with the lack of contracts. Agile organizations are often faced with a contract (or an urgent situation) that has either a timeline or scope constraint.

For example, one company I coached had an urgency to deliver the first release of a next-generation app before its competitors, so they had a time-constrained Release Goal. In that situation, they invested extra up-front effort understanding the essential Features needed to deliver a competitive and cohesive first Release into the market. Once the Agile Teams were formed, they worked under the contractual constraint to deliver the first Release within the understood timeframe. To make this work, however, they had a high degree of flexibility to collaborate with the business on two fronts:

(1) the flexibility to deliver essential Features at varying levels of maturity — depending on what was possible within the time frame.

(2) the flexibility to change the Feature list in the Release Backlog — as everyone learned more, they worked together to adapt the Release Backlog to ensure that the highest-valued Features would ship with the first Release.

This flexibility was essential for delivering the first Release within the constrained time frame. I encourage your organization to learn more about the notion of Agile Contracting and how you can structure contractual relationships to operate in this manner.

How do your contractual relationships look right now?

Belief #4 to Avoid

A Daily Stand-up requires the Agile Team to stand, so the meeting will be short and focused.

At first glance, this might sound reasonable. In fact, many organizations’ Agile cultures have adopted this ubiquitous behavior. However, I have observed an alarming number of organizations where the Daily “Stand-up” was nothing more than a group of Developers standing in a circle and reporting their status to a manager who authoritatively stands in the middle of the circle. If this describes your Daily Stand-up, then watch out – because the person in the middle of the circle is not behaving as a Scrum Master and you’re missing out on the pursuit toward high performance, self-organizing Team behavior.

One of the big organizational changes in an Agile journey is the profound shift away from Team-level command & control project management and toward the emergence of small, empowered and self-organizing Delivery Teams. In Agile, daily progress & planning responsibilities shift to the actual Delivery Teams who are doing the work. In a Daily Stand-up event, the Teams don’t have to stand to maintain focus and discipline. Rather, the Teams must fully understand the purpose and intent of this event, which in turn guides their focused and disciplined behaviors during the event.

So, what is the purpose of a Daily Stand-up? It’s designed to provide a transparent and focused environment for Delivery Teams (i.e., Scrum Development Teams) to inspect their progress and adapt their plans in a way that maximizes their chances of reaching their shared Goal with the days that are left in the Sprint. The idea is to reach this outcome in roughly 15 minutes or less. If they choose to physically stand up to do this, great. If not, that’s fine too. In this event, a Scrum Master’s job is to teach and mentor Agile Delivery Teams on how to facilitate this event on their own … to the point where the Scrum Master doesn’t even need to attend.

What do you think of this?

I invite all of us to fully understand The Scrum Guide, which is the official definition of Scrum from the written words of the co-creators, Ken Schwaber and Jeff Sutherland. This will help avoid anchoring Disbelief #4 in your organization. As stated in the guide, this empirical event is called a Daily Scrum, not a Daily Stand-up – although it’s not the name that matters; what matters is fully understanding the purpose and intent of the event (i.e., the “why” behind a Daily Scrum).

If this daily event feels like a wasteful status meeting in your Teams, then consider re-aligning the name of the event and start mentoring around the actual purpose/intent as defined in the Scrum Guide. You might be surprised how quickly it can take hold and launch your Teams to a higher level of delivery performance.

Belief #5 to Avoid

<Insert a common misconception here>

What have you all learned about the beliefs that guide a successful Agile journey? What beliefs pose a danger toward that pursuit? Please share your thoughts on the 5th Belief That Every Agile Journey Must Avoid in the comments section below, so we can all learn from each other.


If my writings resonate with you, please consider spreading this message so we can energize and inspire the entire professional world together. I invite you to ‘Follow’ my professional journey through LinkedIn. I am also on Twitter.

How To Turn Failure Into A Competitive Advantage

Have you ever worked for a manager who made these statements to your Teams?

Failure is not an option.

We cannot fail.

To deepen this scenario — have you ever worked in an organization that rated you as a poor performer for making responsible mistakes? Shockingly, this is still happening in many companies – even the ones that are trying to become more nimble and innovative. For a company to maximize its ability to innovate (which is one measure of an Organization’s Agility), it requires everyone to learn how to fail in a responsible way.

High performing Agile organizations embrace failure as a competitive advantage that leads to sustainable business success. For those of you who work within these remarkable workplaces, I celebrate your success and the courage it takes to embrace this attitude within your company’s culture.

Success is stumbling from failure to failure with no loss of enthusiasm. ~ Winston Churchill

An example of failure and how the company handled it

I once served within a company where a complex software Product was under constant pressure to deliver new features to a mission critical customer segment. As I got to know these Teams from the periphery, I could see how much they cared about their work and how passionate they were for delivering really cool stuff to their customers. To be honest, I was envious of their situation because people were having a lot of fun in that part of the organization. What’s not to love about that?

So, as these Teams prepared to ship a new set of features (on a weekend), I was off work — actually, I was nestled comfortably in a movie theater with my kids when the “buzzzzzzzz” of my pager kicked in (yes, we used to have pagers!). As I quietly scanned the dimly-lit pager screen, it didn’t take long to realize that something went terribly wrong with their latest Product update. As I started following the threads of communication, I could see some panic playing out in that Product organization – the latest update had failed and unfortunately, there was a major loss of customer data that the Teams were unable to recover.

After the shock & awe phase settled down, I had a chance to facilitate a root cause analysis session with the Teams and senior leadership. What they jointly discovered was a lapse in judgment by one (passionate, skillful and caring) Team Member who bypassed company red tape in an effort to ship the Product update quickly – but as a result, this individual made one small mistake that permanently deleted a large portion of customer data.

What happened in this situation? Would you characterize it as a failure? What would you have done to that Team Member?

Every failure is an opportunity to learn and improve.

As you might imagine, the customers were quite unhappy. This was a clear failure, and (as characterized by many) an irresponsible choice in the heat of delivery. Technology executives had to scramble to provide an explanation to customers, how they were going to fix the problem, and how they would avoid it in the future.

How did the senior leaders handle the situation?

1. They pointed the finger at the issue, not the Teams – Through a powerful root cause analysis session, the Teams (including leadership representatives) focused on the issue, not the people. This allowed for open dialogue which surfaced a deeper problem that went well beyond that one Team Member’s mistake. If they had played the blame game, then the underlying organizational root causes would have never emerged.

2. They never used the word FAILURE – In this Product organization’s culture, they called these situations “learning moments”. In this particular situation, it happened to be an enormous learning moment that had an obvious sense of urgency for immediate remediation. Within this culture, it allowed the Teams to analyze the situation swiftly, objectively, and without judgment. What did this teach us? What insights do we have? And … what experiments can we run to prevent this from ever happening again?

3. The person was not fired – Yes, it was a terrible lapse in judgment. Many companies might have fired the employee on the spot – and in some situations (e.g., where people’s lives are at stake), that might have been the best course of action. But in this particular situation, the organization leveraged an environment of professional safety to allow this person to speak freely about his actions and what he had learned from it. The person was not fired, his pay was not docked, and he continued forth as a thriving Team Member within the Product organization. In fact, he led the charge on a series of significant organizational improvements that strengthened the operational capabilities for the company as a whole.

How can your company transform failure into learning moments?

An organization’s attitude toward “failure” will directly influence the actions that it takes in response to these situations. In real Agile organizations, resilience to failure is an advantage that sets these inspiring companies apart from their lagging competitors. They do this by being:

  • Optimistic – “Learning Moments” keep a feeling of optimism in the face of these difficult situations. Failure can be perceived as a permanent state, but learning moments serve as the stepping stone for meaningful improvement within the organization. What happened? What did we learn from it? What do we need to do to prevent it in the future?
  • Compassionate – The senior leaders were able to empathize with the Teams by connecting to their passion for delivering exciting Product features to their customers. In addition, they capitalized on that passion by acting with positive intent (i.e., our goal is to improve how we ship new Product features, not to seek out and fire employees). Compassionate leadership allows the organization to tap into the energy and skills of the Teams to continuously out-improve their competitors.
  • Focused – An Agile organization operates with a high degree of focus. When learning moments emerge, the organization behaves with a “stop and fix” mentality. Agile organizations don’t waste time blaming people, and senior leaders don’t worry about protecting their power in a corporate hierarchy. The focus is on learning and swift improvement; all in the interest of serving the paying customer with high quality and innovative Product.


Your Call to Action

Does your organization treat failure as optimistic, compassionate and focused learning moments? If not, why? What can you do to influence a change in your organization to start thinking and acting this way?

Please share your thoughts in the comments section below so we can all learn from each other.


If my writings resonate with you, please consider spreading this message so we can energize and inspire the entire professional world together. I invite you to ‘Follow’ my professional journey through LinkedIn. I am also on Twitter.

Are you a Scrum Master or a Project Manager?

Do you hold the job title of Scrum Master in your organization? In most big companies today, this oddly-named title is still misrepresented as a Project Manager, which is hindering the pursuit of Organizational Agility and hurting the professionals who are genuinely attempting to make this challenging job change. If you are one of these people, then it might be time for you to make a change.


As we enter one of my darker posts, allow me the opportunity to take you back into my prior career, and my childhood for a moment.

A number of years ago, I made a professional and emotional transition and I quit my job of software development Project Manager and shifted paradigms into the foreign role of ‘Scrum Master’. Or is it ‘ScrumMaster’ without a space? At the beginning of this transition, I confused it with a role I played in my childhood. Do you remember the epic role-playing game called Dungeons & Dragons? As an appointed “Dungeon Master” by my friends in elementary school, I was considered the master of all, mysterious, wise, and the one who largely controlled the fate of Teams.

However, it didn’t take me long to realize that the supposed “master of Scrum” is actually a very different role – it’s one of service-first to others, commitment & sacrifice to a purpose larger than our own, and the wielding of unspeakable power through positive influence, persuasion and genuine appreciation rather than control and coercion. If the role (job?) is fully embraced in the C-suite, then a real Scrum Master emerges as one of inspirational and disciplined leadership that guides an organization to outstanding levels of workplace performance. Sounds magical, doesn’t it?

If you’re someone who has Scrum Master in your job title, consider investing a few minutes into these reflective questions to reveal if this is the right job for you, or even more important, let’s discover if your organization truly understands and embraces this important role:


Does your organization reward Scrum Masters for “driving results”?

Does your organization discourage failure and experimentation in the workplace?

Do you refer to Teams as “my” Teams? Does the organization assign you to Teams to make them improve?

Do you start sentences with phrases like: “What I would like to see from you all…” or “Please help me understand why…”?

Do you feel an urge to assign work to Teams or solve a Team’s problems to keep it on track?

Are you responsible for judging the performance of Team Members and removing poor performers?

Is ‘Scrum Master’ considered a pay-grade job title in the organization that is commensurate with a Project Manager?


Did you answer YES to most of these questions? Then your job title and workplace reality are probably different. It could be time for a job change.

I’ll offer yet one more question in the spirit of this post’s theme:

Is a Scrum Master role really a JOB?

If the answers to these questions feel uncomfortable to you, then your current job is possibly confusing, or even painful. If so, then you might be on a career path that is not right for you and something needs to change. It doesn’t necessarily mean that you need to leave your organization, but you might need to exemplify courage and “quit-your-job”, but in the right way that involves positive learning moments for you, your peers, your manager and your organization. Positive communication will fuel connections rather than burn bridges – which (hint hint) is an attribute of the Scrum Master role.

Is this post connecting with you and your professional goals?

If so, then consider these two pieces of advice for (1) leaving your Project Management job behind and fully embracing the Scrum Master role, or (2) returning back to your previous job as a Project Manager and guiding the organization to remove Scrum Master from your job title. You owe it to your own professional sanity to get this right:


1. Change your mindset and job behavior from Project Manager to Scrum Master. This can be extremely challenging for those who have been Project Managers for a long time, but it requires you to dig deep into your mind & soul and engage in a personal transformation that changes the way you think about ….. well, most everything. Then, go forth into the organization and positively influence your senior leadership on the value of this critical servant-leadership presence, how it enables higher levels of performance in the workplace, and what is means to you personally and professionally to pursue this path in a fruitful and ethical manner. Garner support for this transition. If you aren’t able to gain this support, then perhaps it’s time to take your service-first leadership potential to another organization where you can fulfill your professional purpose.

2. Work with your organization to shift back into a Project Manager job. Organizations have initiatives that continue to be a great fit for a Project Manager, so it’s worth seeking out those opportunities if the *real* Scrum Master role isn’t the right fit for you. If you have a job title called Scrum Master, but you’re acting as a Project Manager, then once again – use positive communication to educate your manager on the mismatch between the job title and the responsibilities, then respectfully request the switch for reasons that best align with your strengths and career aspirations.


In order to change jobs in the right way, you first have to understand what the change means to you and to the organization.

If you recognize a Scrum Master as that of teacher, servant-leader, mentor and coach, then you’ll find that it’s markedly different than that of a traditional Project Manager. As I continue my travels through organizations small and large, I am finding that many job-titled Scrum Masters are unintentionally acting as Project Managers in disguise. This is the cause of great pain in many organizations right now. This pain is real and evokes a strong emotional response when I have the chance to coach within an organization. The emotions are that of PAIN – to people, teams and organizations. The misunderstanding of this role is literally hurting others, and it’s time to get this right in the interest of workplace humanity.

Am I speaking strongly about this? Yes …. I feel strongly about it.

What are some of the pain points I see in organizations? What are some pain points you’re feeling? Use this pain as an opportunity-creation tool when preparing to hold a job-change dialogue with your manager:


1. It’s painful for those who are trying to change into the role – Because of the stark difference in mindset, these former-Project-Managers-trying-to-become-Servant-Leaders are running into an enormous mismatch in how they think and act in the workplace. To make matters more challenging, oftentimes their job description is still written with the responsibilities of a Project Manager. They might also “report to” a boss who is creating performance bonus structures to drive the behaviors of project management, but within the misunderstood role of Scrum Master. It’s confusing and painful to the person trying to change, especially if the wrong behaviors are being rewarded.

In what way would your job change alleviate this pain for you?

2. It’s painful for Teams that are trying to learn how to self-organize – Project Managers are responsible for planning the work of a Team and essentially assigning that work to individuals. In an Agile environment, the world is supposed to work differently – Teams are galvanized by a shared vision of the future, a business opportunity, or a business problem. These Teams self-organize to decide how best to accomplish their work and meet these business opportunities. For Project Managers who are trying to serve a Scrum Master role, I often find that they revert to the behaviors of project management which is in direct conflict to the self-organizing behavior that they are responsible for promoting. It creates pain within a Team and introduces nasty conflicts and other toxic behaviors that actually make Team performance ‘worse’ rather than ‘better’.

In what way would your job change alleviate this pain for self-organizing, autonomous Teams?

3. It’s painful for the Organizations that have a sense of urgency to change – For organizations that have a critical and urgent need to change, the ultimate long-term survival of the business depends on supportive senior leadership that rebuilds the organization on a foundation of trust, respect and openness – which leads to transparency and more effective and nimble decision-making in the workplace. Crippled by the command & control behaviors of old, some organizations try to “install Agile” by training Project Managers with the expectation that they will walk out of a class as proclaimed Scrum Masters. But without the right mindset of senior leadership, this training is quickly lost and the mindset behind a servant-leader role and self-organizing Teams gives way to previous behavior. In some ways, it makes this change effort worse and reduces the effectiveness of the Organization; all because of the Organization’s lack of understanding and willingness to trust Teams and enable Scrum Masters as true servant-first leaders for the organization. Old-school politics and ego take over and a promising transformation to Agile is dead on arrival.

In what way would your job change enable the pursuit of higher levels of organizational performance that address a critical business problem or opportunity?


Remember – use these painful conditions to create positive opportunity focused conversations with your manager. Your job might depend on it.


What is your advice to others?

What do you think of this advice? What advice would you offer others who are trying to become a Scrum Master but are still acting as a Project Manager? Please share your insights in the comments section below so we can all learn from each other.


If my writings resonate with you, please consider spreading this message so we can energize and inspire the entire professional world together. I invite you to ‘Follow’ my professional journey through LinkedIn. I am also on Twitter.