Why #athletes make great #Project team members #PMOT #DnD

I was attending a Manitoba Coaches meeting last week we were discussing the topic of Emotional Intelligence in both leaders and teammates. Emotional Intelligence is usually discussed in conjunction with the ‘soft skills’ that people have.

Emotional Intelligence is usually defined as “the capacity to be aware of, control, and express one’s emotions, and to handle interpersonal relationships judiciously and empathetically. ”

There are four fundamental aspects of Emotional Intelligence : Self-Awareness, Self-Management, Social Awareness, and Relationship Management.

Although Emotional Intelligence can be augmented through training and education, there is the acknowledgement that some people have a propensity to have high Emotional Intelligence. The usual Nature/Nurture discussion arose and it was agreed that Emotional Intelligence is usually built through the relationships that people have in their early years.


It was discussed that people who are Emotionally Intelligent are proficient at:

  • Collaboration
  • Communication
  • Accountability
  • Independence
  • Teamwork
  • Leadership
  • Problem Solving
  • Critical Thinking
  • Listening
  • Conflict Resolution
  • Managing their Emotions

I had an epiphany that team sports is one of the few things that provide consistent, repeated, and evolutionary experiences in most, if not all, of the characteristics listed above that Emotionally Intelligent people excel in. Team mates experience and grow in all of the proficiencies listed above due to the nature of team sports and shared purpose.

In particular, team sports are one of the few activities where peers hold each other accountable, manage conflict, problem solve, manage their emotions, and take turns leading in their own way.


Team sports are critical not only for physical and mental health, but also project health. Great project team mates have usually been great team mates previously in all sorts of sports.

The lesson? If your children want to be developers, sign them up for Hockey, Baseball, Basketball, and Volleyball. Their future team mates will thank you later.

If they really don’t like sports of any kind, get them to play Dungeons and Dragons. And the computer D&D games don’t count. They need to sit down with friends and learn how to co-operate and deal with looking each other in the eye when they betray or disappoint each other.

That’s accountability – Nerd Style.


Shannon Sharpe and the four characteristics of great #Agile #Teams

After listening to Shannon Sharpe’s emotional speech for induction into the National Football League Hall of Fame, I’d like to share my thoughts about teams on Agile projects.I thought about how much I would have liked to be on Shannon Sharpe’s teams. How much I would have enjoyed being around someone who cared so much about playing, succeeding, and winning. How he balanced having fun with never losing sight of the end goal.


The overused definition for a team is:

“A team comprises a group of people linked in a common purpose.” – Wikipedia

The definition for a project team is:

“A team used only for a defined period of time and for a separate, concretely definable purpose, often becomes known as a project team. Managers commonly label groups of people as a “team” based on having a common function. Members of these teams might belong to different groups, but receive assignment to activities for the same project thereby allowing outsiders to view them as a single unit. In this way, setting up a team allegedly facilitates the creation, tracking and assignment of a group of people based on the project in hand. The use of the “team” label in this instance often has no relationship to whether the employees are working as a team.” – Wikipedia

I was somewhat shocked in the acknowledgement that project teams are usually not teams, but project groups. I know we have all been on great teams and not so great teams. What separates one from the other? When does a group of individuals stop being just a group and start being a team?

The four characteristics of a great Agile Team

I believe there are four characteristics of great teams.

1. They care about each other

Great teams care about each other. Not just the chit-chat in the morning as you are standing around the water cooler, but the honest interest and care about every team member. Can a great team not like each other? I’m honestly not sure. Maybe a good team can not like each other, but to be a great team I believe you have to care about one another. I believe you have to be friends and not just co-workers or acquaintances. This may mean that some skilled individuals may not be the best team mates as they don’t have the same level of care and concern that the other team mates may have.

Most importantly, they need to care about the client. There can’t be a division between the development team and the client. The client needs to be the one they care most about. If they care about the client and fellow team mates, the project is usually in good hands.

2. They respect the ‘game’ are driven to win the ‘game’ and are ‘students of the game’

Almost all great teams are respectful of the ‘game’ or process and are ‘students of the game’. They strive to learn and get better, they are never satisfied with being just good enough. They love to learn and are always striving to improve.

But most importantly, they respect the game. They never complete a task halfway to just say it was done. They never complete a document grudgingly, they never give anything but their best effort. They understand this is unprofessional and is cheating themselves and not respecting those they have learned from.

I don’t usually hear the term winning when it comes to projects. I think we have reduced our expectations for projects so much that we are usually happy with just ‘Meets Expectations”. Great teams push each other to not just meet expectations but win the project. Meeting the budget and delivering the agreed scope should not be good enough, we should always strive to do more and never be satisfied. A  project with a green status is really just a ‘C’ grade. We need to strive for the ‘A+’ again. Great teams do this.

I think bringing the concept of winning back to project teams would help the teams strive for continuous improvement. We need to think about how we can win the game with the largest score. And the opponent is not the client or scope. The opponent is the challenge of the project and the client and the development team is working together to deliver the most value.

Although these traits are individual traits, great teams will self-police and demand this from their team members.

3. They sacrifice

Great teams have individuals that sacrifice for each other and for the team. There are no personal agendas, there are no egos. They will do whatever it takes to ensure the project, the team, and their teammates are successful. This is why agile projects stress cross-functional teams. This aspect removes most of the ‘that isn’t my job’ discussions.

This aspect is a consequence of caring for each other. When people truly care about each other, it is very easy to sacrifice for each other.

4. They have fun

Great teams need to have fun while they are going about their business. If not, the team will usually break apart under the stress of the project. Great team mates have the ability to create an environment where other team mates can be relaxed and have fun. This is a critical skill.

How do you create a great team?

I remember one man telling me that great teams and projects are made by ‘putting together people with good hearts and letting them do what they believe in’. This is very true. People with good hearts care about others, strive to always improve personally and are never satisfied, sacrifice for each other, and are usually very easy to smile.

The challenge is finding these people with good hearts. Some of them develop the characteristics of a good team-mate at home, some at school, and some at work. They are all developed under the care of other people with good hearts, people like Mary Porter. Shannon Sharpe’s granny showed all of these traits to Shannon Sharpe. We should all be so lucky to have a granny of our own once in our lives to show us how to be a good team-mate.

Agile Work Schedule, Telecommuting, and Compensation

On the way back from Gimli to celebrate Canada Day, I heard an interesting discussion on the Charles Adler show on telecommuting and whether the current work day really allows for the best contributions from people. This was proposed for both work and school life and the question was asked if we worked from 7:30 AM through 1:00 PM would we accomplish more than the current schedule that works throughout the entire day breaking for lunch. It stated the old argument that the last one or two hours are usually the least efficient anyway.

So why not put in 5.5 solid hours and save the remaining two hours when minimal value is realized. Now obviously the value realized each hour would change for the different types of jobs, but this proposal may hold water for the types of jobs where you are expected to be creative throughout the day.

It also proposed that allowing people to work for home can greatly increase an individual’s productivity as well. It was mentioned that not only does this save on travel time, but also on time potentially wasted due to talking and interacting at work that isn’t directly related to the task at hand.

So that go me thinking about these two things and then that spurred a third idea. Let’s tackle them in order.


I love telecommuting. And the people on the radio loved it too. To a person they stated it made the individual person much more efficient. I think that is the key. In individual work and activities I think it can be a very effective tool. But we always need to remember that our goal isn’t about making just the individual more efficient, it has to also make the team more efficient. It was never asked, but I wish they would have asked if the individual’s telecommuting made the organization more efficient. Although you can use technology to help to counteract any issues that may be caused by remote team members, I have not heard of one person who preferred team members that were not co-located. I think telecommuting and remote teams have their place and can be used to provide individual flexibility and link specific expertise on projects, but we need to be careful that telecommuting always makes the projects better. (I know in my current project the remote team members absolutely make our project the best that it could be)

Work Schedule

This was an interesting one. I’m not sure a generalization can be made of which work schedule is the most efficient. I really think this depends on the individual and how they like to work as individuals. I think again we need to ensure that the work schedule allows for the most efficient team. Although one team member may view the 30 minutes of talking waste, it may have made the other 4 members of the team much more efficient.  We again need to ensure that we are focusing on making the team better when we discuss these options. I know I became a better Project Manager when I stopped planning my day according to the tasks I needed to complete and focused on the assistance I needed to provide to other team members to help them complete tasks.

Agile Compensation

With my thoughts structured nicely with the first two issues, I noticed some questions started to pop into my mind:

  • Although we propose to our client to focus on the project value delivered, many Software Development departments compensate on a combination of seniority, competencies, and ultimately hours.
  • I’m sure we have all been on projects where one or two people had much more output and value than other team members. How can we recognize those contributions?
  • How can we compensate team members for the true value they provide and not just the potential value? (seniority and competency)

My only thought was that we need to start moving compensation to a balanced compensation model that balances individual competencies with value delivered on a team. In this way we can start aligning how we compensate individuals with how we propose projects focus on the value being delivered. I know this is not an easy journey and I don’t have any easy solutions. I do think that being able to recognize individuals for their team value may provide some needed flexibility to compensate people fairly.

In the end for all three of these concepts it is all about the team and the value the team can provide. Amazing what thoughts creep into your mind when you are driving back from a day the beach with a van full of sleeping kids.

An Agile experience – A musical chorus

It struck me as I was watching my mother-in-law’s performance in a musical chorus, how Agile a chorus really needs to be. They were a chorus of approximately 30 women who all had different ranges, outfits, vocal styles, and physical mannerisms while they sang.

I thought they were a great analogy for an Agile team. Here was a team that didn’t try to dress the same or choreograph so that they all sang like 30 versions of the same person. They all had different skills and styles and they embraced those styles. In the end, I believe this added to the quality of the performance and it was quite inspiring. I thought back to how on most teams we try to overly fit people into roles and standardize processes.

It gave me insight to my current and future teams on how we spend effort on choreography rather than outcomes. What did it matter if people had different ranges, outfits, mannerisms, or styles? As long as the outcome was a coordinated effort and delivered value, paying attention to choreographing those other items would have simply been waste.

I believe this excessive choreography comment applies to Agile and non Agile processes and practices. If we blindly follow prescribed methods without ensuring they increase the value of the outcome, we are increasing waste.

And my other observation? All this works when people have passion for what they do. The chorus loved singing and although they went about it differently, the passion came out in the commitment to the outcome. They coordinated the passion and outcome, not the engine that creates output.

All in all, it was a wonderful performance with an unexpected Agile insight. Embrace Individuality, Promote Passion, and focus on Outcome.

Thanks Betty-Anne.