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

Agile Coach Camp Canada 2010, photo credit: Michael Lant

In my research last year, I learned that at an Open Space event, participants will create and manage their own agenda of working sessions around a central theme. This all happens onsite just before the sessions themselves begin.

What a novel idea! Meetings and conferences that are focused on what matters to the people attending, rather than being planned and decided upon by a committee or management ahead of time.

My first Open Space event was Agile Coach Camp Canada on June 11-12th, here in Waterloo, Ontario.

I was quite excited to see how Open Space would run… and how more than 60 people could possibly define and set a session schedule in less than 30 minutes.

After the unkeynote (more on that in my Agile Coach Camp Canada post), all conference participants gathered together. Our Open Space facilitator spent a short amount of time explaining what was going to happen:

• A large 8 x 4 grid was on the wall, with four time slots, and space for 8 parallel working sessions. If we needed more working sessions, we could easily add another parallel track.
• All participants were welcome to propose sessions of interest that were important to them, preferably in the form of a question. That will invite people with something to contribute to attend the session.
• Proposed sessions were written on an 8”x11” piece of paper, and signed with the session proposer’s name. The proposer then put their session into an available time slot.
• Participants juggled the session topics around to merge overlapping topics, and ensure that everyone would feel that their most important concerns and questions would be addressed throughout the day.
• The session board could change, shrink, or grow throughout the day as participants saw fit. We just couldn’t add more time slots.

Agile Coach Camp Canada 2010 - The Board; photo credit: Michael Lant

In about 20 minutes, more than 60 people had created the conference schedule for the day. It was amazing to observe and be a part of.

Who says large groups of people can’t get things done?

Our facilitator then outlined some simple “rules” in how the sessions would be run:

• Attend any session that we felt we could contribute to and learn something from (give and take).
• The Law of Two Feet meant that our feet are to be used to carry us to a place where we are contributing and learning. We could leave sessions part way through to attend another session. We could choose not to attend any session and instead have an important discussion with someone (or several people) about another topic entirely. The key was to make sure we were active participants.
• Spend no more than 1/N of the session talking to ensure everyone has opportunity to contribute (where N = # of session participants).

And that was it!

Each session involved active participants, with session leadership often changing hands throughout the hour-long time box. After the morning sessions were complete, all 16 were summarize by participants in 90 seconds apiece. This shared learnings from each session with the rest of the conference participants; a practice rarely seen at conferences. This repeated for the afternoon sessions.

To finish the day, we participated in closing activities that had people sharing highlights of their experiences, communicating appreciations to individual’s they appreciated through the weekend, and saying goodbye to both old and new friends.

The process used for Open Space sounds a bit familiar, don’t you think?

The difference between traditional conference formats and an open space format is akin to planning projects to the final detail upfront, versus using a just-in-time agile approach that addresses the most important needs at the right time. Add to that the important agile values of putting people first through collaboration, communication, appreciation, and celebration.

My colleague was right. I did love Open Space! I can’t wait to use it for future events and client engagements.

Note: I am not an advocate for McDonald’s, own no stock in the company, and would never ever step foot in one again if I can help it, due to a variety of reasons not relevant to these postings or this particular weblog.

One of the first things I learned working in the fast food industry was how important customers were. Customers are necessary for keeping a company operating, but are also important in shaping many business operations and decision points. Here are three things that stuck with me after working the daily grind at McD’s:

Customers keep the business running, and your job intact.

Seems obvious, doesn’t it?

Sadly, it doesn’t seem to be in many companies. I bet you can quickly think of at least three bad customer service experiences you have had in the last three months. Sub-standard customer service, interactions, and expectations have become common place in today’s society.

The good news is that companies who make customers feel valued, listen to them, and actually improve their business based on customer suggestions are further ahead of the competition. Customers return when they have had great experiences.

While working at McDonald’s I focused on ensuring customers had a great experience. It all started with the first friendly and happy greeting, through to listening carefully to their requests, filling the request quickly and accurately, and finishing with a friendly good-bye. If anything happened to go wrong with an order, I quickly stepped in to compensate before they became frustrated and upset.

Customers also keep the business running and our jobs intact in the software industry.

Whether you are a programmer, a tester, a project manager, in operations, or in any other role, we need customers so we have a business. The customer may be an actual end-user of a product or service, another company who is purchasing a product or service for delivery to another customer, or even an internal user of the software.

Regardless of who they are, it is our job to provide a positive experience for that customer. That means:

• Understanding what problem they need solved
• Learning what they need to be happy with the product or service
• Determining how they will actually use it, and
• Ensuring every interaction is focused on the customers’ satisfaction and happiness.

Customers drive future products, if you listen to them.

Every customer is going to have some sort of feedback about the product or service they obtained. It may be positive in identifying how well it works for them, recommendations for improvements to improve it’s usefulness for them, or even complaints about how it doesn’t satisfy their need at all.

Running a business comes down to understanding what customers need and why they will buy something. If you don’t provide something they need and will purchase, you’ll quickly be out of business. This makes sense, but how often do you take customer feedback into account?

Context: Restaurants located in Southwestern Ontario, Canada.

In the early 90′s there were several products that McDonald’s offered that I really liked. Salads and pizza. For whatever reason, neither product sold well enough to keep them on the menu. Corporate listened to the customer feedback (which was represented in sales numbers, and in surveys and feedback forms) and removed both of them from the menu. While I was disappointed, customers were happy when new burger selections appeared on the menu to replace them.

Flash forward to early years in the new millennium, and you may remember that salads made a comeback and were added back to the menu as customers became more health conscious in their dietary habits. Additionally, as consumers became more environmentally conscious, most of the styrofoam packaging was done away with and replaced with paper and cardboard products.

Customers should also drive product evolution and new product creation in the software industry.

I have worked in organizations where someone internal to the company came up with ‘the next big thing’, developed it, and it flopped. Why? Because customers didn’t need it, want it, or it didn’t satisfy all their needs appropriately.

Learning customer needs and wants is critical for developing successful products.

• Product Owners/Managers need this information to devise user stories/requirements that will actually satisfy customers and make profits.
• Programmers need this information to ensure they program a solution that satisfies customer requests, wants, and needs.
• Testers need this information to confirm that what is developed not only fulfills a need and desire, but is actually usable for the customer in the way they will use it, continues to evolve per customer feedback, and satisfies many non-spoken product/service requirements.

This requires time to research, learn, and understand customer desires.

Customers evolve company image and business direction.

Most companies are in business to make money. To make money, businesses need customers. To get customers, they need to know how to attract their target market(s). Understanding the desired customer base, their lifestyles, and their interests is paramount for promoting an image and devising a marketing strategy that attracts, and keeps, the people wanted as customers.

Context: Restaurants located in Southwestern Ontario, Canada.

Do you remember the marketing strategy that McDonald’s used in the 80’s and early 90’s? They targeted most of their efforts at children. If children desperately wanted to go to their restaurant, parents would take them. From now-classic characters such as Ronald McDonald, Grimace, and the Fry Guys, through to the bright and bubbly in-store decor and family-sized booths, the company image was all about the kids. Some stores even had train cabooses that were used to host birthday parties, much to the delight of many children.

In the mid-to-late 90’s, McDonald’s changed their target to be less child-focused and more adult and family-focused. In-store decor evolved to be more subdued to attract a new customer base, Children’s Play Places were added so parents could have a break from their kids while knowing they were safe and having fun while in the restaurant, the Monopoly game was introduced to collect pieces and win prizes, and the infamous characters were fading away. McDonald’s was growing up.

From there McDonald’s further evolved to focus predominantly on the adult and teenage market. The company image and direction shifted to obtain customers outside of the established children-and-family market. They became more trendy, hip, and grown-up by introducing the “I’m Lovin’ It” commercials, advertisements and commercials focused on the working professional, and updated decor reminiscent of upscale cafe’s. McDonald’s touted a cool and adult-friendly image.

Consider whether customers influence the image and business operations of your organization.

• Does your company evolve its image as the target customer base evolves?
• Do marketing strategies change to acquire new target markets?
• Does the company consider customer lifestyles and interests into how it promotes itself?

Customers aren’t just the people who make a purchase for an end product or service, but are also internal to a company.

• Does your internal organization modify and adapt it’s image as other organizations in the company evolve and change?
• Do you know how to appeal to them so that working relationships remain strong over time?
• Does your organization evolve as your internal customers evolve?

Let’s go one step further. 

Suppose you have an external customer who likes to be heavily involved in defining a project, makes many changes, and likes to have flexibility in what the final end-product is.

• Does your organization evolve to use more agile practices that can work with this customer more effectively?
• Or does it stick with heavy-documentation, everything-is-planned-upfront, and nothing-can-change approaches? Guess how well that customer relationship will work out.

This isn’t just about company image and branding.

It is also about the processes and methodologies you use to appeal to, work with, and satisfy the customer. That extends from sales and marketing, product management, programming and testing organizations, operations, and customer support. If your organization isn’t adapting how it operates in order to keep up with the customer needs, you will soon be left in the dust.

What’s Next?

Take a moment and consider whether you, your organization, and your company really value your customers.

• Are customers welcomed, appreciated, and treated as a valuable part of the company/organization?
• Is customer feedback gathered and regularly used to adapt in product creation and evolution?
• Does the company image and business direction evolve according to the needs of the target market?
• Do methodologies and approaches adapt to work seamlessly with customer needs and methods of interaction?

Watch for the next part in the Food Service Lessons series, Lesson #2: Teamwork.

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