The #1 characteristic of a great teammate #WinnipegJets #Pavelec

ondrej-pavelec-by-clint-trahan

I was watching a recent Winnipeg Jets game when I was reminded about the #1 characteristic of a great teammate.

Connor Hellebuyck was anointed as the starting goaltender for the Winnipeg Jets this year. He had a great season in the AHL last year. He had all of the great reviews as he moved through the various levels of hockey. The Winnipeg Jets had grown tired of Andrej Pavelec and his inconsistent play over the last few years. With Pavelec’s contract expiring at the end of this year, the writing was on the wall that a switch was going to be made sooner or later.

Resiliency

But we saw play from Hellebuyck that was very similar to Pavelec. Inconsistent, with a bad goal given up almost every night. Both goalies also had pure gems of games that could get you hoping of what the future could hold. But when Hellebuyck got pulled in three straight games in January, you saw a difference between the two goalies. And then when Pavelec came up to the big club and started three straight games and won you again saw the difference.

Various radio shows called it something different – ‘timely saves’ was the term most commonly used. Whatever the term, Pavelec may give up the bad goal, but then didn’t give up the next goal. He fought through the shots and kept his team in the game. And his team knew that Pavelec would fight to prevent the next goal and keep them in the game. We was a fighter and it was hard to get the ‘next’ goal on him.

Ondrej Pavelec has Resiliency that Connor Hellebuyck doesn’t have yet. The Winnipeg Jets players know that and due to that, they play better in front of Pavelec because it gives them confidence to play their game. They don’t need to worry about making a bad play, because Pavelec will overcome it if it happens. It is a larger worry making a mistake in front of a goalie where it may open the floodgates. Because of that you hold your stick a bit tighter and ironically make more mistakes.

Summary

Resiliency is the #1 characteristic of a great teammate. That trait in a teammate that they are resolute, plucky, committed, able to rebound and recover. We all make mistakes, but those people who take a shot, dust themselves off and stand tall are the special teammates we all want on our team. Give me a resilient craftsman over a fragile artisan every day.

Another example of Pavelec’s Resiliency is how he took his demotion with class and professionalism. Resilient teammates accept decisions made for the good of the team, confident in their abilities and committed to rebounding and proving themselves when the opportunity arises.

I hope Connor Hellebuyck can build these characteristics. But until then, I’d start Pavelec.

My Pride and Joy Project

I came across a blog by Liza Wood on her pride and joy project. You can read her excellent post here.

It made me think about what my pride and joy project would be for me.

I consider myself very lucky to work on the projects I have worked on. I am constantly amazed by the excellent teammates I have been lucky enough to have worked with. I started to list off the projects I have worked on and two projects seemed to set themselves apart:

1) Agile Delivery of a new Parks Reservation Service. You can read about this project here.

2) Providing Data to Investors Group Advisors

Three things

As I reviewed these two projects, there were three things that they both had that made them something that I was very proud of.

1) There was a great challenge that was solved by the team – both projects were difficult and challenging in different ways. And both projects solved those problems through the hard work and dedication of the entire team. And by entire team I mean business and technology teammates together.

2) There was a great amount of learning – both projects required a huge amount of learning. This learning was both for myself and the entire team. These two projects probably resulted in the most advancement of my knowledge throughout my entire career.

3) The people on the project were awesome – This is closely related to the second point, but it deserves a point of its own. The people on these projects taught me so much, but they were also so proficient in what they did that is was a pleasure just to work beside them. There was a sense of camaraderie that we were all there to solve a problem. There were many great memories of late night, laughs, frustrations, and broken builds.

The Project

Ultimately, I choose the project where we provided data to Investors Group Advisors. The project was actually much more than this. It was an entire infrastructure project of rolling out laptops and a download process to 4,500 Financial Advisors. In 1997. 17 years ago….

The project would be less of a challenge today but back in the mid 90’s we were implementing cutting edge technologies. I was on the database team that defined and loaded an Oracle Operational Data Store. I was in charge of a small team that loaded the Oracle database and we worked hand in hand with another small team that extracted the data from Legacy systems. Although there are many toolsets now that can help with these Extract, Transform, and Load processes, the landscape in the 90’s was quite different. So we wrote our own. from scratch. And we had the easy part of the project. The application team that was building the laptop application in Visual Basic was really working on some challenging components…

I chose this project instead of the other one due to one important factor, I developed.

Don’t get me wrong, I love Project Managing. But there is a certain sense of accomplishment and gratification working together with a team and developing software functionality that addresses a business need. I know Project Managers do this as well, but from a distance. The ability to be one of the few that directly authored the solution, was, well awesome.

And that is why the current project I’m working on with be my favourite project once it is implemented. I’m coding again and there is no feeling like it.

 

Everything I needed to know about teams I learned from Dungeons and Dragons #PMOT

It occurred to me that the five key principles of teams that I learned early on were taught to me at an early age by Dungeons and Dragons. Now I’m not talking about any movie or video game knock-off of Dungeons and Dragons,  but the original Dungeons and Dragons in-person game. You know the one with the 20-sided dice and the Dungeon Master’s screen with the awesome red dragon on it? It even got better with Advanced Dungeon and Dragons with all the extra Monster Manuals – but I digress.

Here are the five principles I learned about good teams that I learned from Dungeons and Dragons

1) Have a diverse team

Early on it became very apparent how ineffective an entire team of Magic-Users were. I mean all we get to do is to roll the darn 4-sided die and strike with a dagger? That sucks. Ditto for Fighters and not being able to have cool attacks from a distance. To be able to get great treasure and defeat the cool monsters we need a diverse team with diverse races to take full advantage. Ever try to defeat a dragon with just a team of Halflings? enough said.

2) Have diverse team members

I must admit there are two vivid memories I have from my childhood. The first time I tried pizza and when I discovered multi-class characters. I mean it just blew my mind. You mean I can fight with a sword AND cast spells? Sign a brother up! That was the coolest thing in the world. I immediately became more powerful as I could do different attacks based upon the need of the situation. And when everyone on the team became multi-classed and we could as a group change to fit the situation? Nothing could defeat us.

3) Nothing replaces experience

I mean the gold was great and the magic items rocked. It was also great to collect all these things and trade and buy more, but the only thing that really mattered was getting experience. As I was predominantly a Magic-User, I became very aware how the level 1 and 2 spells sucked ducks. (Shout out to Troy Westwood on Banjo Bowl  Weekend) I mean the early spells were very limited, but when I looked at the latter spells I could raise the dead and have a Finger of Death? Now that was cool. Nothing replaces experience.

4) Seek out the Druids

I must admit early on I never saw the value of Druids. I mean commune with nature? Heal? That was kinda interesting, but did we really need a tree-hugger in our group? I mean we were all about hacking and slashing and pillaging. It was only later I looked at the druids as team members who would not only help all other members of the team, but as people who already had placed the needs of the environment and others ahead of their own. These were people who had empathy and concern for their teammates. They were willing to make the sacrifice for the greater good. I must admit, I really respected Druids for this. They traded their individual aspirations in and could not use a sharp-edged instrument at all. Mace and Clubs? Now that is a sacrifice.

Every successful project team I have been on has had a resident Druid who essentially was the glue of the team.

5) Exploration and investigation is the key to success

If you had a really good Dungeon Master, all the really good treasure was hard to find. Usually in a secret room or secret panel.

Dungeon crawling is quite similar to a project. You have an initial quest that you need to complete, but the real key to completing the quest and succeeding is examining the periphery of the quest and discovering the items that may not be immediately visible. But by finding these items, individual and group accomplishments became much easier and greater.

And if your Dungeon Master was really good, the quest was impossible to complete unless you explored and investigated. Just like in real life. Some projects may not succeed unless you exhaust all the options that may not be immediately apparent.

Summary

There is actually one more principle that I learned from Dungeons and Dragons. The Importance of Friendship. In our early levels we conducted ourselves as a group of individuals, but as we grew we showed more concern for our teammates and for splitting up the treasure appropriately. (and saving each other when our hit points were low)  The game taught us how to share, sacrifice, and appreciate members of the team. It also made us appreciate the fact that we grew-up together side by side.

You see this on really great teams that have accomplished great things. The bond that the individuals have never seem to fade. The generosity and concern for each other never fades. When they see each other they are taken back to the project and quests when they found the +25 Axe of Smiting.

Thanks Gary Gygax

The role of emotions in performance feedback discussions

Lately I have been reading quite a few blogs on the topic of performance feedback and how to try to make feedback a more valuable process. Recently I came across Bob Marshall’s post:

How to give Feedback

I’ve already had great discussion with @adaptivecoach on the Core Protocols and their potential impact to the communication process. You can see my previous post here:

My Core Protocol Check-in

After reading these different perspectives, I find myself aligned most with Steve Rogalsky’s post. Which is very fortunate since we work together at Protegra and on the same project. 🙂

A Systems Thinking alternative to Performance Feedback

After thinking about all these different approaches, I thought I would add my thoughts to the discussion.

Feedback Guidelines

I try to follow some simple guidelines for my performance feedback discussions. I believe the feedback process should have four simple components:

1)      Agreement on my view of the project’s expectations of you

2)      Feedback on my perception of your project actions versus the agreed expectations

3)      Agreement on your view of the project’s expectations of me

4)      Feedback on your perception of my project actions versus the agreed expectations

Once there is agreement on the expectations, we can have productive discussions in the future. These expectations can be as vague or as detailed as both people desire. The key here is to have a baseline that can be used for future discussions. It is patently unfair to provide feedback to someone if you haven’t previously agreed what was expected. These expectations can be both subjective and objective. I would recommend that at least 50% are objective criteria though. It is very important to have a good percentage of objective criteria for discussion. Subjective criteria are, well, subjective. 🙂

The formality of these discussions can be modified to fit the situation and personalities of the people involved. I prefer to always have them face-to-face via back and forth conversations.

Feedback questions

Steve Rogalsky provided some great questions in his recent post and my questions don’t stray too much from his. The questions I like to have as part of a feedback discussion are:

1)      How do you think you have done?

2)      What is your opinion of how I have done?

3)      What did you enjoy most about your work?

4)      What would you like to do in the future?

5)      What would you like me to do differently in the future?

6)      What are you most proud of that you have done recently?

7)      How should we change the expectation agreements we have with each other?

As you can see, my preferred questions are a bit different from Steve’s in that they don’t have the questions grounded in Systems Thinking. But I think we both find our questions productive in generating a productive feedback discussion.

The role of emotion

The one thought that I had after reading these different sources is that my approach does have one significant difference from the Core Protocols and Bob Marshall’s post.

My perspective is that emotion should be left out of feedback discussions. Unlike the Core Protocols and Bob Marshall’s post, I believe that grounding feedback discussion in the emotions of individuals is inappropriate. It can lead to more subjective review that may be not providing the details required to help the individual improve objectively. It can introduce personal biases and agendas into the discussion.

There is also a subtle difference in the feedback questions I prefer that I believe is critical. I believe my wording change makes the process less hierarchical. Instead of the focus on personal emotions, the grounding is on the project requirements.

How have your actions made me feel vs. How have your actions contributed to the project

I believe this is key. By grounding the expectations and feedback on the project, we can reduce personal bias and hierarchical thinking. (we are both there as peers to contribute to the project)

It should be a true peer-to-peer system where we all evaluate each other and our contributions to the project. I believe having feedback discussion grounded in the project also encourages more feedback as it is more objective and less hierarchical. It is still a perception, but it isn’t how you have made me feel,  it is have I perceive you have delivered to the agreed project expectations. I think it makes the discussions less of a personal, confrontational nature.

It is an un-emotional discussion on this is what we agreed to was important for the project and this is how we perceived each other’s contributions. Let’s work together now to determine how we can improve for the next time.

#SDEC12 Conference Review #Agile

Well another Software Development and Evolution conference has come and gone. (You’ve always wondered what SDEC stood for didn’t you?) It was a lot of work and effort to make it all happen, but in the end it was very enjoyable. I learned an immense amount and cant’t wait until next year.

My Highlights

      • The Joe Justice/Wikispeed Keynote on day 1 was entertaining and inspiring. If you aren’t familiar with the Joe Justice and Wikispeed story, I highly recommend you doing a search on YouTube or Google. Inspirational stuff on what can be accomplished when you ask why not? WikiSpeed
      • The Luke Hohmann/Innovation Games keynote on day 2 was energizing. I have been a fan of Innovation Games for a long time and it was energizing to hear Luke speak and provide the context on how and why Innovation Games are successful. InnovationGames
      • Adam Yuret @AdamYuret brought Lean Coffee to SDEC12. It was a highlight of mine to attend his session on Lean Coffee and learn how we can have our own Lean Coffee discussions. Although I must admit, I would prefer an afternoon coffee instead of an early morning one.
      • Chris Dagenais @MDChris had a couple of engaging and informative sessions on team building and peer feedback. Great sessions and audience was very engaged and interactive.
      • Lightning Talks made their first appearance at SDEC and were very well attended. There were great talks and tons of practical information compressed in 5 minute chunks.
      • Best presentation I attended was presented by Mark Kulchycki and Alyson Teterenko of Manitoba Hydro International. It was a real life tale from the trenches on how their team evolved and incorporated Agile principles into their PSCAD product development team. Awesome presentation, pragmatic approaches that everyone can use.
      • My personal highlight of the conference was the Innovation Games workshop with Luke Hohmann after the conference. It was an excellent session where Luke not only covered the Innovation Games themselves, but also the science and psychology of the games and the art of facilitation. Probably learned more in one day than I have for a long time.
      • I loved presenting my Agile Data Warehouse talk. I’m hopeful that I can have a follow-up presentation at SDEC13 that illustrates more how we used Innovation Games and show the actual models that were created.
      • It was great being able to just talk and share with everyone at the conference on what worked for them and what people are still struggling with.

Summary

It was a great conference with over 200 attendees. This was a new record for SDEC and caused us to be flexible to modify the lunch process for Day 2 to be more efficient. 🙂

I can’t wait for next year. We are gathering the feedback forms and listening to our Advisory council to assure the content and structure is even better next year! Thanks for your support and see you at SDEC13!

On the importance of Dreams and Dreaming

I was at a power skating practice for my son and daughter yesterday and it made me think about dreams.

Before I start there are two things to note:

1) Yes, my daughter in playing Hockey instead of Ringette

2) Yes, Hockey season starts in August in Canada. 🙂

When my son had his first skating lessons over two years ago, the apparel of choice was much more diverse. This past week I would estimate that two-thirds of the kids were wearing Winnipeg Jets jerseys. It was pretty obvious the favourite team of the kids was now the Winnipeg Jets. (Although there was a good amount of Sidney Crosby jerseys as well)

It got me thinking about how important dreams are. The definition of a dream that I like most on dictionary.com is:

“a cherished hope; ambition; aspiration”

Neil Degrasse Tyson has a very powerful video on Youtube on the importance of NASA. To paraphrase, the United States has stopped dreaming recently with the decline of NASA. This has had a ripple effect on their economy and the ability to define new industries. You can find the video here: We stopped dreaming

So what?

For those kids that afternoon, when they were skating in that jersey they felt they could become more than just what they currently were. Maybe they could play in the NHL. It might have been my imagination, but I thought those kids skated just a little bit taller and straighter than a couple of years ago. I believe it was because they felt they were part of something bigger than themselves and part of something that was special. 

Probably none of those kids will make the NHL. (including mine) But all of them will be better because they had that dream to inspire them. 

For our teams and teammates the importance of dreaming is no less important. We need to create an environment where people feel comfortable dreaming about everything the team, product, and project could be. It will make the team members and the solution better than it was without any dreams. We need brave people who are willing to dream, take a chance and fall down. Without those dreams we will just do our prescribed jobs in our prescribed ways.

Dreaming is the engine of Innovation. If we need to innovate we need to encourage dreaming and support that dreaming. If we don’t do that, our teams and solutions will become a commodity. And you don’t want to be a commodity in this global economy.

 I wonder if the Jets still need a back-up Goaltender?

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.

Definitions

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.