Top 4 qualities for a leader/manager #agile #pmot

I’ve seen quite a few articles recently on the qualities to be a good leader, manager, and Project Manager. Most recently, I read an excellent article by Liza Wood on “Should you become a Manager?”. Highly recommended.

I thought I’d add my opinions to those already out there on what I feel are the top four qualities to be a leader or manager.

1) You are a competent team member already

I’m big fan of leaders and managers needing to be competent members of the team prior to expecting to lead or manage. If you are going to lead and manage people, I think you need to understand the issues your team is dealing with at a detailed level. I know not everyone agrees that this competency is required. I frequently see groups proposing that Software Development Project Managers don’t need to be technical. Let’s just say I must agree to disagree with those groups.

Although I think I’m an OK Project Manager for Software Development teams, I would never think I could be equally efficient managing a team of doctors or truck drivers. What do I know about those areas? How could I possibly help them in the issues they encounter.

2) You don’t want to make decisions for other team members and you don’t want to “manage” people

It is a red flag for me immediately when I hear someone say they want to manage. I wonder what their drivers are and whether they want to “manage” people due to the perceived status and traditional career path. Sometimes people will even confess that they want to be managers so they can make decisions.

I find the best managers are those team members that don’t want to manage. They also don’t want to make decisions for their team mates.

They grudgingly accept being a manager because:

  1. They are good at it
  2. They have the respect of their teammates
  3. They recognize it is probably the best way they can help the team and client

3) You enjoy working with clients and team members and helping to facilitate decisions

This point is connected to the previous item. Great leaders and managers love working with people and helping to facilitate decisions.

They love building relationships and helping people to grow in their careers.

Most importantly they love helping the team to solve problems by facilitating. They realize that the team must solve the problem and their role is to help the team build consensus as a group. Great managers always are careful to not offer solutions for the team. This would be the easy thing to do as the team is looking to the manager to make these decisions. But the really great leaders and managers will always defer to the team. (even though they have the preferred solution already decided in their head)

This deference to team decision-making can sometimes be perceived negatively by team members. I remember thinking this about one Project Manager I worked with. I thought that he wasn’t doing his job because he never decided anything, he always just deferred to us. Only in retrospect did I appreciate his masterful skill to facilitating team decisions.

4) You are always perceived as calm and professional and never blame anyone

Probably one of the most overlooked characteristics.

I feel that the job of a leader is to always build confidence in the team.

Great managers and leaders are always calm, never blame anyone, and just work the problem. Doesn’t matter how the problem arose – lets just resolve it.

And it never hurts to have a great sense of humour…

Lest we Forget the ultimate teammates


On a day like today I am reminded on how we in Software Development sometimes take ourselves and our opinions too seriously. We treat people with differing opinions as enemies we are at war against. We in the Agile community sometimes criticize those in the traditional community as not trusting employees and being stuck in the past. People in the traditional community sometimes criticize Agile proponents as being cowboys and not understanding why certain  business processes like estimating and budgeting are required. We need to ask ourselves if we are truly seeking to understand the position of the person we are yelling at.

Are we interested in learning and growing or just yelling and being right?

But today, we should put those differences aside and respect those men and women who went before us and made the ultimate sacrifice so we can live the way we do today.

These men and women were the ultimate teammates. They were willing to give their lives so that our country and our way of life could thrive. They left loved ones and children behind and made the ultimate sacrifice.

I encourage everyone to take an hour to break and watch the ceremonies today. Even better, make your next book selection a book about a war and the sacrifices the veterans made. I also encourage you to volunteer to assist veterans after they come home.

I believe that by respecting their sacrifice we are not glorifying war. Like all good teammates we should respect the decisions made by other teammates as we can not fully appreciate the context of their situation. We should always seek to understand their situation and sacrifice. It is the ultimate hubris to think we know better now.

That is the least we can do.

Top three signs a company is masquerading as employee-focused #halloween

Everyone says their company is employee-focused. Everyone says that their most important asset is their people. Everyone says that they have a flat structure and that there is an open door policy for everyone. So how can you tell the difference between the companies that are employee-focused and those that merely say they are employee focused?

I find there are three signs and they all involve a Suggestions Box.

Suggestion Box

A suggestion box? Isn’t that a sign that the management is honestly interested on improving and engaging the employees to improve the company? Not always.

In fact, there are three signs related to suggestions boxes that illustrate how committed management is to being employee-focus. These are:

1. You have a Suggestion Box

Although many people take this as an indication that the company is honestly interested in their employee’s suggestions and ideas, that is not always the case. In fact, a Suggestion Box reinforces a hierarchical structure. They may be interested in your ideas, but only after a review process. A suggestion box says:

“Thanks for your suggestion, we will review it and let you know if it has merit. Don’t call us, we will call you”

The suggestion box, still sets up an us and them structure between employees and management. This was re-inforced to me during an awesome keynote by Mark Graban at SDEC13. Mark pointed out that several Lean hospitals have moved towards suggestions Kan-Ban boards so that everyone can see their co-workers suggestions and see the progression of those ideas from submission to completion!

That shows the engagement and commitment the hospital has to their employee’s ideas. Brutal visibility.

2. The Suggestion Box is not actively used

An even worse situation is if you have a suggestion box and it is not actively used. This usually results from suggestions being submitted and dismissed by management. Employees soon discover that there is no action taken on their suggestions, so why should they bother? Even worse, lack of suggestions sometimes indicates a lack of trust in management. There may be suspicion about whether people making suggestions will be labelled as trouble-makers.

3. You have an anonymous suggestion box

Oh boy. If a company has an anonymous suggestion box, it almost is an acknowledgement that management can’t be trusted with knowing who submitted an idea. And that employees feel they need anonymity to be safe to submit ideas.


I love the idea of a suggestion Kan Ban board. It provides brutal visibility as to the suggestions submitted by employees and shows employees that management takes their ideas seriously and are implementing them. It requires absolute commitment by management to implement employee’s ideas though. Any filtering, removal, or dismissal of ideas by management will be visible to everyone.

What the #BlueBombers taught me about #leadership and #teams

Oh boy, every time I watch the Winnipeg Blue Bombers I learn something. Sometimes I learn sometime just by watching the game or listening to post game interviews. Recently I listened to an interview with Head Coach Tim Burke and it was a great learning experience. Unfortunately for Tim Burke it was an example of what I feel you should never do to your team.

Unfortunately Tim Burke is in the public eye. I’m sure if I was interviewed about my teams throughout the years there would be a couple of doozy quotes that I would love to take back. Many times we state something and it comes out in a way we never intended. That was probably the situation with Tim Burke in this interview.

The Interview

In the interview, Tim Burke stated that the one of the main causes of the poor record was a lack of talent.

Oh Boy.

My Thoughts

Was Tim Burke telling the truth? Maybe, Probably. But you don’t say those things outside the team. The team is an organization where you can  be honest within the bounds, but you never throw team mates under the bus. Even if a problem could be traced to some team members

I have been brought up to fundamentally believe one thing in regards to the teams I belong to.

You never separate yourself from the team. You never state that a problem exists because of those guys over there. In these situations, you are placing yourself above the team. I’m OK, it is those guys over there that have caused all of the losses. How are those guys now supposed to have your back? And I know athletes are paid handsomely, but deep down they are still human beings with feelings and motivations like all of us. Would any of us put the extra work in when a boss called us out of the carpet? Maybe yes, probably no.

I’ve been taught that leaders should hold the team sacrosanct. I’m not saying you lie to protect your team, but you certainly don’t separate yourself to paint yourself in a better light.

Don’t get me wrong, I not saying Tim Burke should pretend a lack of talent isn’t a partial cause. But it can be phrased that it is one cause of many and we all have contributed to where we are. Suddenly a moment that divides the team becomes a moment that unites the team.

My belief system was forged in the fire of making mistakes.

I’m sure Time Burke regrets what he said. I sure hope he does.

#Agile and Music – Have we been selecting Project Managers incorrectly all along? #PMOT

I’m always fascinated by stories where other industries seem to have arrived at the same practices that have become common place in Agile.

In the final chapter of “Beautiful Teams”, there is a chapter focused on how Tony Visconti manages his projects to produce music. He has worked with David Bowie, The Moody Blues, Thin Lizzy, among others. You can check out his story on his Wikipedia page that can be found here.

Musical Planning

I was fascinated to read how Tony manages a process that is even more dynamic and creative than the Software Development process. But he did make one observation first that I believe translates to Software Development. He states that the reason artists place their faith in him is because he was/is a musician as well. For artists to place their faith in him they have to feel that he understands them and their perspective. He has to have the context to tell them they are being unreasonable at some points.

I also feel that great Project Managers should have been developers in the past for the developers to trust them during the project. A Project Manager who has limited knowledge of technology and the process of Software Development is at a great disadvantage when trying to assist Software Development teams. How can he or she understand why something is truly an issue? How can they spot a small issue that can balloon into a major risk if they don’t understand the process. They also need to have the context to tell the team or the business that they are being unreasonable.

Equally fascinating was the discussion about the two visual boards that Tony uses. He uses a derivative of a Kan Ban board so that the musicians can understand at one glance what the status of the project is. He also employs a separate board that lists the number of days left until the next milestone. (whether than be an intermediate one or the end of the project. Tony also talks about how the entire team comes up with the content of the plans. Tony seems to manage his projects in a very collaborative and Agile manner.

Here is a snapshot of his Kan Ban board derivative.



















Tony also makes many other great observations that translate  into Software Development. His discussion about how important personalities and team chemistry is fantastic. Highly recommended read.

The one Idea

But the one idea I took away from his story is that I believe we have been assigning Project Managers incorrectly all these years. Instead of having Project Managers being one of the first people assigned and then building a team around them, I feel that the team should be assembled first and the entire team should then decide on the Project Manager. Like the artists who elect to have Tony work with them, the project team is being asked to place their faith in the Project Manager. The project team needs to have 100% faith in the Project Manager – after all they are trusting him with their project.

Rather than viewing the Project Manager as managing the project and the team, the Project Manager is really just producing something for the team. I wonder how much more successful Software Development projects would be if the teams were able to select their Project Managers. The team would start out with enhanced trust of the Project Manager as they choose him or her.

Great book and excellent chapter. You can find the book on Amazon at the following link.

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.


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

How my kids are learning about #Leadership

Both my kids are attending a Mini-University camp at the University of Manitoba this week. My daughter is taking a craft camp and my son is taking a myth-busters camp. For the record, they love the camps and I love how the camps are being taught.

Over dinner on Monday I saw that my daughter was a team leader, on Tuesday my son was team leader for the day. I thought this would be a great time to discuss was a leader was. So I asked both of them what a leader does on a team.

I’ve watched my son interact with his friends enough times to guess that the leadership role would probably end up being a competition with his friends. My daughter also likes to be ‘directional’ with her friends, I was really intrigued as to how they conducted themselves as leaders.

My first question was whether they enjoyed being leaders. Both of them mentioned that it was a lot of work. They both said they wouldn’t want to be a leader tomorrow. They thought it would be good for each of the kids to have a turn.

Alright! So far, so good.

My second question was what they did they do as leaders? Did they order people around? Did they tell people what to do? Both of them mentioned that they assigned tasks to the rest of the team.

Hmmmm… I was a little concerned until my daughter piped in..

“But then my team had better ideas as to who should do what tasks. So we decided as a group to change how we did things and I spent my time getting things for the rest of the team”

I’ve never been so proud.

My thoughts

My thoughts on great leaders fall into these two principles illustrated by my kids…

1) Great leaders don’t usually want to be leaders. They usually take on the role when encouraged by their team. Given their choice, they would much rather operate in the shadows performing a practitioner role on the project.

2) Great leaders don’t direct the team, they serve the team by providing whatever the team needs. Sometimes it can be vision or structure but most of the time it is facilitation and serving the needs of the team.

Ultimately I think great leaders are coaches who just want to be players again. I’m glad to see my kids are learning this far earlier than I did…


Can an #Agile team mate #telecommute?

When Yahoo released the memo about employees not being able to work from home any more, there was the expected backlash against something which has become more and more common. It was especially unexpected given that Yahoo’s new CEO recently had a child and might be expected as someone who would find value in being able to work from home.

If you haven’t seen the story. Here is a link to one of the many articles on the subject:

Yahoo Reaction

Individual versus Team

My thoughts on this matter revolve around the concept of individual versus team performance. In fact, the link to the article provides a perfect quote:

“They didn’t lose my productivity,”

As someone who has a 6 and 7-year-old, I can’t see how someone who works from home could be as effective by working the same amount of time. Little questions and requests have context switches inherent in them. We always talk about the impact of task switching at work. We have to be consistent and also recognize the impact of task switching at home. So let’s assume that the person in question puts in the extra time to be as productive at home as they were at work.


What about the Team?

But what about team productivity? Unless you are working on a solitary project, having a remote member has to affect the team productivity. People work around the missing person. Instead of an immediate in-person discussion they have to make a phone call, instead of white-boarding they either create an electronic diagram or set up a video-conference. Now what happens when the remote person may not be available due to an urgent issue on their side? Technology can help, but the experience isn’t the same and there is an effect on the team.

But what about remote Agile teams?

My opinion, and it is only my opinion, is that I would prefer to not have to deal with a remote team. Now this isn’t possible in some circumstances, but we can’t pretend a remote team will be as efficient as a co-located team. The only question is how bad it will be.

I’d prefer Agile teams to always be co-located in one room. I don’t want to be in a separate room in one building, never mind some people being at home or across the continent.


I think Yahoo is correct. The company and teams work best when everyone is together. The collaboration and innovation that happens when people are together can’t be replicated.

I understand that are complexities that make everyone co-located a challenge. But if you gave me the choice, I’d choose everyone in same room every single time.

Every quote I had seen on this topic also had the individual aspect as the primary focus. The quotes proposed that “I” was still as productive. No one ever stated that the “team” was still as productive.

#1 rule of #Agile Culture

I recently went on a two-day excursion to the United States to support the local economy in Grand Forks and I was struck with a unique message on a bill board on the way back to Winnipeg. There were the usual bill boards that listed the shopping malls, hotels, and restaurants that you should visit. But amongst all these capitalist bill boards, was a plain white bill board with black letters with a simple message.

“Be Kind.”

I wish I could have taken a picture to include in this post. But when I searched for the image on Google, lo and behold someone else had taken a photo and uploaded it. It seems I wasn’t the only one affected by this simple message.


What it means to me

To me this simple message was a reminder of what I feel is most important in all teams. Whether the teams be project teams, family, sports teams, or any other grouping of like-minded individuals. It is even more important in leadership or management positions to place kindness first – before egos, agendas, vision, or politics.

As I start 2013 with my family and project teams, my New Year’s resolution is to always keep this in mind.

  • To be kind to my team mates as we discuss different opinions
  • To be kind to my clients as we discuss changing requirements and how we can make them delighted
  • To be kind to agilists with other opinions that I may not initially agree with. To strive to understand their positions before making up my mind.
  • To be kind to the value we are delivering and to eagerly accept change when it adds more value.
  • To be kind to change and to not react against any new ideas.
  • To be kind with my family and smile and laugh every day.


My goal is to have that image of that sign as I go through 2013.  As I thought about it, I felt that if I was truly kind to all the people I interact with and the project, then the project and relationships I had would be very successful.

Recently it seems more focus has been placed on Agile Culture and less on Agile Methods.

To me, “Be Kind” should be the first principle of Agile Culture.

My #CoreProtocol Check-in

I’ve spent quite a bit of time reading up on the Core Protocols over the last few months. They have honestly intrigued me. If you haven’t read the Core Protocols and are interested, I would suggest starting with the Core Commitment and then reading the Core Protocols. You can find the Core Commitment here.


There are some great guidelines and ideas within the Core Protocols. But while I find the Core Protocols interesting, I must admit that the I found the structure to be somewhat restrictive. After thinking about it for a while, I think my concerns fall into two general categories.

1) I see the application of the Core Protocols to be more for broken teams that are severely challenged. I don’t believe I would get as much value when I have a team that already has worked together and has trust. I could see the use of the Core Protocols if you have a severely culturally diverse team and are looking for a common set of guidelines that everyone can follow and refer to.

2) For a long time the check-in and check-out protocols and their use troubled me. I couldn’t place my finger on why. Then I realized that what I was struggling with is that the protocols seemed to put the individual and the individual’s emotions above the  team and team mates. (and possibly the client)

For Example:

1) On Check-in I can check in a state that I am sad, glad, mad, or afraid. (Or I can pass) These emotions can be about team mates, clients, or anything in general. If it involves a person, my first thought is whether they have discussed the issue with the other person first. If they haven’t, bringing it up in Check-in only provides safety for the reporting individual. For the other individuals and the psyche of the project? Not so much. Having these check-ins could have some adverse effects that could and should have been handled by one on one conversations.

2) On team mates Check-ins I can’t ask questions or refer to it in my check-ins. Once again this may benefit the reporting individual, but it limits the benefit that the team can get based on interactions and questioning between team members during check-in meetings. I absolutely love the quick discussions that happen during stand-ups that identify common issues between individuals and then create a plan of attack. The efficiency and team work is very energizing.

3) Anybody can check out at any time and physically leave discussions at any time. This can be even at the detriment of the team and the discussion at hand. You can imagine a current discussion about a key factor and perhaps a key architect check outs. So what happens now? We can’t even ask him/her why she has checked out or encourage them to return. Based on the person and the situation, the act of checking out may have created a material issue for the project. (depending when the person decides to check back in) The protocol of Check-out is different from Pass as you physically leave the room, with Pass you are still in the room but have declined to interact.


Like most methods in Agile I know there are some situations, clients, and team that the Core Protocols would probably deliver value.

I think my concerns come from a personal style preference. I would prefer my teams to strive to have individual conversations first when they have issues and to try to place the team’s goals above their own at all times. Perhaps some modification to the protocols would assist this if people needed to seek the team’s permission first before passing or checking out. I’m not sure if this would be acceptable to the Core Protocols.

At the end of the day, I feel these Protocols will probably increase one way communication, but at the expense of two-way communication. And that is where I think the magic happens. I think effort should instead be spent trying to build trust and make people comfortable to maximize the amount of two-way communication instead of implementing a structure that limits two-way communication.