What organizations promote as ‘heroism’ is rarely how I would define ‘heroism’ (see photo). In this post, I talk about a ‘hero culture’ and ‘heroism’ in terms of how I have seen organizations promote them. You can be a true hero in a team-encouraged environment, but it works differently than a hero-encouraged environment.

Consider the firefighter who saves a child trapped in a burning building, who is able to do so because of the support of his team; and the team who saves the building. Firefighters work as part of a team where each individual plays a role to keep themselves safe and save whomever or whatever it is they hope to save. The team is heralded for the work they did to save the building, and the individual heralded for rescuing the child. They all do their best work possible, support one another, and get the job done no matter what. Team cultures celebrate both the successes of the team, and of the individuals within the team. Neither is done at the expense of the other. If a ‘hero culture’ such as those I have seen in organizations were promoted in a firefighting department, you would hear about firefighters scrambling over themselves to be the one who saves the child, no matter what, so that they are heralded as the most important hero who saved a person. It is that type of ‘hero culture’ that I speak of in this post.

My Message

The notion of a hero as someone who does things because it is the right thing to do should not be done away with. It is how a ‘hero culture’ is promoted and encouraged in organizations that needs change.

The issue I have is when heroism is upheld above everything else, particularly the Team. Companies can not succeed on one or two individuals alone, at least not in the long term (in my experience and observations). The ability of a Team to pull together to prevent problems they can foresee and solve problems that do arise is important. We need different perspectives, skills, and experiences to prevent and solve problems in the best way possible at a given point in time. When all team members feel like they are contributing to the best of their ability and that management supports them as such, teams can accomplish far more than an individual hero can.

The promotion of heroism in organizations limits teams from accomplishing their potential as a team. Many people seek to achieve individual rewards, to get the top raise, to get the most recognition because the organization encourages it – even if they unknowingly hurt the team, the project, and the organization as a result.

I admit that I have been that person, and I know from experience that some colleagues will shut down and decline to contribute as a result. I have been the person who works 60-80 hour work weeks to solve problems, do the right thing, and help save a project from disaster. I have been the person who stays under the radar doing all the right things, and was recognized as a leader and someone who will save the day.

At the time, I thought that competition was a good thing, as it would help us all raise the bar and do the best work possible. I only understood later that if your bar is so high that other smart, capable people can not reach it, they just won’t bother. So then you have a ‘team’ of people who succeeds only on the efforts of an individual. Why bother having a team then?

I have learned from experience that Teams need to be recognized for the heroic efforts they do, not individuals. Teamwork results from people who trust each other, support each other, and can build relationships with each other. It is difficult for most people to build healthy working relationships that accomplish amazing things together when they feel they are in competition with each other.

So, I will continue to do all those things I’ve done when I feel it necessary, and yes, I want recognition when I do those things. I wouldn’t be human if I didn’t. That said, I work hard to balance this with the promotion of a team-based culture, as the strength of a high-functioning team far outreaches my ability as an individual.

I thus promote Team-culture over Hero-culture; provided the needs of the project, company, customers, and investors, are met, and dare I say, exceeded.

Some Examples

Some specific experiences I have that highlight problems in a “hero culture”:

• A hard-nosed believes-he-is-right-about-everything programmer insists that he doesn’t have time to do things right, and tells everyone he does not test his code before releasing it to testers. He says he is too busy to bother, and it’s their job anyway.  Throughout a 5 month project his features are consistently not testable because they are so broken. This persists until a couple weeks before release when he is finally able to fix the most critical known bugs in the software. Management heralds him as a hero for solving these really difficult problems, and promotes his behaviours as what they want to see in everyone. His poor decisions earlier on are not discussed and are allowed to continue in his future work.

• A senior manager spends the majority of his time talking to people about how bad a shape the company is in, and how he would do things differently if it were his company. He spends most of his evenings and weekends in the office ‘checking up’ on people’s work and getting face time with the CEO who is often in the office. This is because his family and friends live back home many hours away, and he has nothing else to do while living in the city for this job, so he spends waking time at the office. He is quick to point out employee faults, and quick to take credit for employee successes. He is promoted as a hero by his superior’s because he spends so many hours in the office, and was crafty enough to take credit for successes that were not his (without his superior’s catching on to that).

• A team works incredibly hard to release a challenging project. Everyone works together to understand and prevent problems, solve problems as they arise, and put in equal amounts of overtime. They are a high functioning team. Each time a serious problem is averted, two individuals on the team are heralded by those outside the team as the ones who save the day. The rest of the team is demotivated by this and wonders why they bother with their contributions when the other two team members always get the credit. It was a team effort and it should be recognized as such.

While these are specific situations, I have seen many other cases where the promotion of heroism hurt the abilities of teams and organizations. In each of these specific cases, the individuals involved could have behaved differently:

• The programmer could have put his best effort into doing quality work with integrity, including testing his code before sending it for testing. It’s one thing to do your job with integrity and quality and be seen as a hero for solving a problem later on. It’s quite another thing to knowingly do crap work and then come in as the hero to fix the problems you created as a result of your crap work.

• The senior manager could have tried to help the organization improve and do better, instead of complaining to anyone who would listen. He could have informed others that the work people were crediting him with was actually someone else’s. He also could have worked from his in-city apartment (as he had a laptop and VPN access) to do whatever work he was portraying himself as doing during evenings and weekends – he instead chose to be in the office to get credit for just being there.

• The individual team members could have responded to the proclamation of their heroism that it was a team effort (because it was), and that they should be recognized as a team for those efforts.

Final Thought

These examples also highlight issues with management. Management plays a very big part in the culture of organizations, as they have ‘power’. The culture that traditional management encourages is one of individual heroism, which is detrimental to team culture. Now, I’ve often encouraged culture change from the ground up, and have been successful in some cases, but it’s a tough road, and one that many people aren’t willing to attempt.

If you prefer to work in hero-encouraged environments, be my guest. If it works for you, great. I challenge you to consider your motivation in wanting to work in that type of organization – you may have reasons that I completely agree with, or possibly not.

If you want to work in a team-encouraged environment, I implore you to listen to the YouTube clip linked to in my previous post. I summarize some things you can do to help encourage your organization to transform into one.  I challenge you to consider other ways to encourage that transformation and share them here.

Thoughts?

At Agile Coach Camp Canada in June 2010, I lead a session on How to Transform a Hero Culture. It was the first session of the day, and a spirited discussion with many new friends, old friends, and people I admire.

Organizational culture is a critical factor in whether a new process or methodology will be successful. Whether you are an Agile coach, a change agent, or a natural leader, you recognize that if an organization’s culture is not in alignment with the new direction, and is unwilling to shift, the new direction will most likely fail. This is a big challenge!

I have worked in several organizations where a hero culture was prevalent. What I mean by this is that heroic efforts to rescue a failing situation are rewarded and encouraged. In this type of culture, whether fixing a critical issue or working 60 hour weeks, you are what everyone should aspire to be.

There are many types of heroes, for example:

• Someone who wants recognition, power, and rewards, and often happens to be in the right place at the right time to solve problems.
• Someone who doesn’t take care to do a high quality job the first time around, and then swoops in to clean up their own mess.
• Someone who does high quality work, has good judgement, tries to keep a low profile, yet is a natural leader for change and problem resolution.

If you are trying to create a culture that embraces teamwork and collaboration, regardless of the type(s) of hero(es) in your organization, you will want to help evolve the culture away from one that supports and rewards heroes.

How to Transform a Hero Culture

Michael Sahota and I summarized the key findings of the session at Agile Coach Camp Canada to transform a hero culture. You can watch it in the video below.

What do you think?

Do you think a hero culture should be encouraged?

Or do you think they should be transformed into something different? If so, what are your idea’s on how to transform a hero culture?

I look forward to your comments!

- Selena

One thing I have been wondering about is the impact a Scrum Master has on the abilities of a team.

• How large a role does a Scrum Master play in a teams’ effectiveness?
• Are there behaviours a Scrum Master exhibits that encourages a team to succeed and improve?
• Can a Scrum Master hinder the growth and success of a team?

My experiences lead me to conclude that a Scrum Master, despite being a ‘servant’ to a team, plays an integral part in the effectiveness and success of an agile team.  The size of their impact depends upon the maturity of the team and the organization.  A team that has been working together for a long time, is disciplined in their efforts, and is largely successful may need less from a Scrum Master than a newly formed team.  Newly formed teams may need someone to provide guidance in their efforts to adopt agile practices, improve their skills and practices, and keep them focused on what success looks like.

In observing the day-to-day interactions and behaviours of a team and its Scrum Master, it is feasible to measure some level of effectiveness of the Scrum Master.  Until recently in my own experiences, I wasn’t sure this was possible or even worthwhile.  Assessments can be misguided, but can be helpful if used appropriately in the right situations. I realized that opportunities abounded in my situation, and could prove helpful in determining if a Scrum Master was a factor in why a team was struggling.

So what signs can you look for that may indicate whether a Scrum Master is helping or hindering the success of a team?  From my own experiences, I selected five potential categories for assessment, and identified different behaviours and characteristics that could be observed in the Scrum Master and the Team.

The Self-Organizing Team

Admittedly, this category is worth looking at more in-depth to truly grasp and understand it.  For the purpose of this entry I will simplify it as:  When a team is truly self-managed / self-directed / self-organizing, they are able to successfully manage the teams work and processes, and participate in organization-wide systems and strategies. It is in reality much more than that though.

When a team is successfully self-organizing, the Scrum Master:

• Encourages the Team to self-organize and self-manage.
• Understands when to step in and coach the team in solving problems, and when to let the team work through problems on their own.
• Guides the team in disciplined work ethic, retrospectives, and improvements – but only if the team really needs it.
• Does not direct or manage the work, the tasks, or the people at any time.
• Does not commit to work on behalf of the team.

When a team is successfully self-organizing, the Team demonstrates decision-making and ownership. For example they:

• Negotiate, decide on, and accept what work will be done in the sprint.
• Figure out how to best use all team members to complete all the work agreed to during the sprint.
• Report to each other, not the Scrum Master or Product Owner (in daily stand-up, retrospective, etc…).
• Support one another completely.
• Take responsibility for issues, concerns, and in completing stories end-to-end in a sprint.
• Make technical decisions as a team.
• Make ‘how to’ and process decisions as a team.
• Utilize retrospectives to reflect, learn, and grow as a team.

The Scrum Master Serves Team & Product Owner

If an Agile adoption is progressing successfully, the Scrum Master supports the teams efforts, protects them from outside distractions, and provides whatever services the team needs to succeed.  In some cases, the Scrum Master may also support the efforts of the product owner, but only when not in conflict with the teams’ needs.  While the team and Product Owner work together to succeed on a project, they have different interests in their roles.  Similarly with the Scrum Master and Product Owner.

To assess whether the Scrum Master is acting to serve a team, observe whether they:

• Protect the Team from outside distractions.
• Quickly remove impediments for the Team.
• Allow the Team to make mistakes, while facilitating and supporting their success.
• Facilitate productivity through improved tools, practices, and process improvements.
• Guide and enhance the reflection and learning opportunities within the team.
• Support the Team and Product Owner in following Scrum Principles.
• Surrender control to the Team so they decide what/how/when/who.
• If appropriate, when supporting the Product Owner, they similarly surrender control to them in relation to their role – but only if not in conflict with the teams’ interests.

If a Team is utilizing their Scrum Master appropriately, they will:

• Give impediments to the Scrum Master to unblock – they trust that they will be removed quickly.
• Allow the Scrum Master to track progress and communicate information for the team – they trust it will be done accurately and timely.
• Respect the guidance of the Scrum Master when provided, as they trust that it is provided only when they don’t have the skills needed.

Transparent Communication

A critical aspect of Agile is clear and open communication by all stakeholders.  Agile will not succeed if people restrict who has access to what information, and there is a reliance on pulling of information, instead of pushing it.  The Scrum Master is critical in ensuring that information is pushed in various directions:  into the Team, out of the Team, and within the Team.

In an organization where communication is transparent, and specifically so for the Team, the Scrum Master will:

• Disseminate information across stakeholders, including:  the Team, product owner, management, and others.
• Provide a variety of statistical information about how the team is doing (historical velocity, current velocity, escaped bug counts, etc..).
• Provide visible project progress & successes (impediment backlog, sprint backlog, burndown chart).
• Ensure everyone on the project is up to speed at all times.
• Be the communication hub – they push information out, so others don’t have to pull.

Team Collaboration

Collaboration is key in Agile organizations.  Developers collaborate openly and consistently with testers, product owners collaborate with all Team members, and Team members collaborate with customers.  In a healthy collaborative environment, people are respectful of one another, seek out other ideas and perspectives, are empowered to make decisions, and solve problems creatively and quickly.

To support the creation and maintenance of a collaborative environment, the Scrum Master will:

• Encourage team members to collaborate frequently (to understand requirements, design software, test software, investigate issues,…)
• Let the Team figure things out on their own, when they are skilled to do so.
• When the Team is not skilled to do so, use coaching techniques like ‘questioning’ to draw solutions and ideas out of the Team, NOT provide them with solutions/answers.

When the Team is collaborating well, they will:

• Come up with options, alternatives, and creative ideas on their own.
• See more balanced contributions from team members, rather than seeing the same people making the largest contributions.
• See skills transferred amongst team members so people are able to take on any task.
• See that there are fewer specialists, and more skilled generalists on the Team.
• Work closely with other stakeholders as needed without encouragement.

Visible Results

Most businesses need to feel and see tangible results to believe that an organization is doing the best job possible.  It comes down to the bottom line – return on investment, visible metrics to show improvement & success, and sales figures.   When a Scrum Master is doing their job to support and enhance the success of a Team, there will be visible results that the executive team can happily track to if desired.

When the Team is successful, the Scrum Master is usually doing their job properly.  In this case stakeholders will see that the Team is:

• Able to meet their deadlines and level of quality as negotiated and agreed to with product owner.  This results in improved business value, which can be measured through:
  • Improved time to market
  • Improved customer satisfaction
  • Fewer technical support calls
• Able to reliably predict their results, which can be measured through:
  • Deadlines being met
  • No excess overtime or unbalanced workloads across team
  • People not burning out
  • No vacation restrictions necessary
• Making time for product, skills, and knowledge improvements throughout sprints.  This results in:
  • Decreased time to market
  • Increased customer satisfaction
  • Improved skill sets
  • Improved return and satisfaction on employee surveys