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.


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…


#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.

#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.


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!

When #Delegation is just #Dictating

I came across an example recently of a person dictating and directing when they believed they were delegating. This tends to be something I see quite frequently in my day-to-day project work. For delegation to occur, I believe that there needs to be three crucial characteristics. These characteristics are:

1) Direction and Leadership

Delegation is more than just getting someone to do a task you don’t have time for. Delegating is also delegating the responsibility for the direction and leadership of the outcomes from that activity. I frequently see people delegating a task, but only if the task is done as it has been envisioned by the delegator. Frequently I see investigation or documentation being ‘delegated’ to another person and then having the outcome reviewed/approved by the delegator. True delegation also has the direction and leadership responsibilities also delegated.

One of the most difficult things to do is to accept the outcome from a delegated activity that you do not agree with. But this is critical to the act of delegation. This is how we are able to create solutions by teams and not just individuals. If there is subsequent approval of the output of delegated activities, we probably have not really delegated the activity.

2) Delegation by end-state

True delegation is delegation by end-state. The delegation is specified according to the objective that is to be realized. There is no or little specification as to the process to achieve that end-state. That will be determined by the person that the activity has been delegated to. If a delegated activity spells out the order of the tasks to be done and what the tasks are, I have some bad news for you…

3) Re-delegation

The key litmus test for me on whether an activity has been truly delegated to me is whether I have been given authority to delegate it to another person. (or multiple people!) If the activity has truly been delegated to me, they are delegating the responsibility for the completion of the activity and just not delegating the execution of the activity to me. If you ever want to test if someone has truly delegated an activity to you, mention that it now has been delegated to another person. Their reaction will be very telling.


At the end of the day, delegation is about having trust and giving control. People who are uncomfortable with delegating have not yet developed that level of trust with the person. (or they prefer to maintain control) This is not a bad thing. Depending on the circumstance, it may not be wise to delegate high-risk activities. But to become a high-performing team, delegation must eventually happen. A team or company cannot scale if all control is in the hands of one person.

Top Three Rules of #Agile Software Estimation

Yep, Estimating is hard. It isn’t easy and it isn’t without peril. Unfortunately it is a fact on 95% of the projects we work on. So given that, I’m not sure that telling people not to estimate is productive. There are a lot of misinformation about estimating though. Not all estimates are evil and not all are a waste of time. Here are the three estimating rules that I follow that have served me well.

1. Estimate Iteratively

I can’t figure out for the life of me why people who discuss Agile projects assume that if you estimate you must be BEUF. (Big Estimate Up Front) I always estimate iteratively with the estimate getting more refined as I go along. Usually the stages are:

Proposal Estimate – At the very start of the process when you don’t know much

Plan Estimate – Creating an executable plan and estimate before you start after you know more about scope

Execution Estimate – Re-planning with the final team just before execution

Iteration Estimate – Re-planning before each Iteration

With an iterative approach to estimating you can provide a line of sight to the clients as to what they can expect and you can also communicate how the whole project will evolve. Even the estimates.

2. Estimate with the team

This is a no-brainer. Always, always, always estimate with the team. If your team composition changes, I would re-estimate with the new team. Friends don’t let friends estimate alone. It is as much a learning experience as anything else.

3. Estimate the Minimum Viable Product

This is probably the most important rule. Let me be clear. You have no business starting or being involved on a Software Development project if you can’t estimate that you can at least deliver the Minimum Viable Product. (MVP) Yes, I know it is hard and difficult and fraught with errors, but an estimation based on years of experience if better than no opinion at all.  It can save wasting money on a project that had no hope of success. And it doesn’t need to be a very detailed estimate at the start, just a high-level estimate that confirms the team believes it can be done. (see rule #1)

Some Estimating Falsehoods

There are some common Estimating Falsehoods out there. I have taken these from the Blog post on estimating by Matt Rogish that takes the point that estimating is harmful.

Here we go:

“In really terrible places to work, someone other than the developer will actually do the estimating. This estimate will then be given to the developer as an implicit (or at especially evil places, explicit) time not to exceed. This is such a depressing situation I cannot dare think of it further.”Correct. This is really a problem with bad leadership rather than estimating. Don’t throw the baby out with the bath water.

“Most estimation is drawn from past experience. What if the developer doesn’t have this experience? How can they estimate? This is where things get tricky. And by tricky, I mean “completely made up.” Sure, for things that have been done before by someone the developer can draw some parallels and make a guesstimate. But what about the stuff that has never been done before (presumably, the secret-sauce that makes you money)? Usually you just take a Wild-Ass Guess (WAG-estimation) and hope you’re not wrong. Given the rarity of being punished for under-promising and over-delivering this WAG tends to be a massive over-estimation.”This is a common Falsehood. As mentioned in Rule 2, no one estimates alone. Senior developers help the less experienced and share their wisdom. This point also again highlights just plain old bad management.

“Completely spec out the entire system ahead of time, spend a lot of time researching and estimating the problem, determine project dependencies, and you can determine the “finish date” before writing a line of code! It’s seductive and taps into the part of our brain that craves order and dependability.”See Rule 1 – Estimate Iteratively. I can’t imagine any Agile professional would fall into this line of thinking.

“If the value of software we’re writing is so low, is it worth being written? If the project has such tight time constraints that a schedule slip will doom the project then you’re in a world of hurt. (The solution is agile: work on the most important things first, have an always-working project, and cut scope to hit a date.)

This exposes a major weakness in most software companies: the inability to determine project value. Given a project of unknown value, the conservative business will then attempt to minimize cost. Unfortunately as we’ll see, cost minimization ends up becoming very expensive in the long run.”This is a strange point to me. We as software developers can’t estimate our projects, but YOU the business need to estimate the value. Well we can’t have it both ways. I agree Agile is the solution, IF we estimate we can complete the Minimum Viable Product within the current budget. See Rule #3.

I’m not entirely sure what this means, but I’ve never seen the folks who are writing the specs, requirements, etc. ever being asked to estimate how long each spec will take to write. Or have the CEO give a date when the company will hit some arbitrary metric, although see the perversity in public company earnings estimates and reporting.”I’ve seen both on all the projects and companies I’ve worked for. CEO bonuses are commonly tied to unrealistic estimates on an arbitrary timeframe.

“Ultimately companies require estimation because they don’t trust anyone. They don’t trust developers to deliver results. They don’t trust mid-management to motivate their reports. The underlying reality is that the folks “in charge” are worried that everyone is going to rip off the company and only by holding people to arbitrary deadlines are they assured stuff will get done.

Committing to a date allows them to sleep better at night and shifts the blame from them to the folks on the front lines. “Wow. If anyone works at a place like this, leave. But don’t blame the estimates. If you don’t produce estimates, this company will just find another way to pull a fast one on you.

“Estimation is ultimately a futile effort. Software, more or less, is like writing poetry. Or solving mathematical proofs. It takes as long as it takes, and it’s done when it’s done. Perfect, or imperfect, estimation won’t change how long it takes to complete the work. If that sounds horrible to you, then go do something else.”I could not disagree more. It is correct that estimation won’t change the amount of work it will take to complete something, but that isn’t the point. The point is about giving some imperfect information to the client to help him/her make business decisions. You remember the client right? The one who is going to pay the bills and we are trying to deliver value to right? I would agree that truly unique software solutions are like writing Poetry. I was on a R&D project recently and the estimating was challenging to say the least. But 95% of Software Development projects are following semi-established patterns. The projects are not routine, but nor are they like creating something fundamentally new all the time.

“Estimation actually slows down development because estimation isn’t free. The developer is incentivised to take as long as possible estimating in an effort to not get beaten when they miss the estimate. Why waste that time when the metric the developer is attempting to hit ultimately generates negative value?”See Rule 1 on estimating iteratively and this is just an example of bad management once again.


Estimation is difficult, never correct, and is fraught with danger. But if you are like me, the vast majority of my clients require them. So the question is not why can’t we stop doing estimates?,  but rather how can we do them better?

In almost all cases, the problems with estimating can be traced to bad leadership on management. That is where I believe our focus should be.

#Agile Goalie

I came across a quote from Ken Dryden on the role of a Goaltender in hockey and I thought it was a great analogy to what I believe a great Project Manager is. Anyway, here is the quote:

“[A goalie’s] job is to stop pucks, … Well, yeah, that’s part of it. But you know what else it is? … You’re trying to deliver a message to your team that things are OK back here. This end of the ice is pretty well cared for. You take it now and go. Go! Feel the freedom you need in order to be that dynamic, creative, offensive player and go out and score. … That was my job. And it was to try to deliver a feeling.”

Although I have read almost all of Ken Dryden’s books I did not remember coming across this quote before. I feel it also communicates the two responsibilities of a great Project Manager extremely well. These two responsibilities are:

1) Stop the Pucks – Manage the project

This is more the traditional expectations from a Project Manager. Create the Project Plan (in whatever format), manage the plan, resolve issues, submit Change Requests, and produce project communications. These are the more explicit expectations of the role. And like Goaltenders, you need to be proficient at doing this responsibility before you can hope to move onto the second. You can’t inspire confidence unless people believe you are competent in the basic role.

2) Encourage creativity – Inspire the team

Once you are able to convince the team that you are competent, you can move to encourage creativity. This is perhaps the greatest attribute of a great Project Manager, to be able to inspire confidence and trust. If a hockey team is unsure of their goalie, they won’t make that daring cross-ice pass, their defencemen won’t pinch, and the forwards won’t make a blind pass to the open wing. They will stifle their creativity and innovation because they are not confident in the outcome if those actions do not go as planned. But when the team knows their goalie has their back and trusts him or her 100%, the offensive creativity and innovation in unmatched. It is no coincidence that every great dynasty in hockey had a great goaltender who inspired that creativity. You can just name the goalies – Ken Dryden, Billy Smith, Grant Fuhr, Patrick Roy…

To extend the analogy even further, the coach will now create challenging and innovative game plans and strategies because he has confident in his Goaltender. Now not only does the team take greater risks that can result in great things, but the project stakeholders will take on more risk because they trust the Project Manager and the team. That is truly a high-performing team.


Inspiring confidence is two-fold. One is being confident and having the team feed off of your confidence. This is very important and a project with a Project Manager without confidence in the project and team is lost from the start. Two is having the team understand that you are 100% part of the team. Sometimes on projects there tends to be a distinction between the Project Manager and the rest of the team. But when you can sit in the room with the entire team and do project work alongside the entire team, the confidence and energy the Project Manager can instill will encourage the team to accomplish unbelievable things.

If you need any additional proof, here is the classic Ken Dryden pose.

This pose just inspires confidence and communicates that ‘Things are fine back here, I don’t have a concern and neither should you’

#BeautifulTeam: #Canada and the #USA

As I mentioned in my last Blog post, I’ve been reading the book ‘Beautiful Teams’. It has been and continues to be one of the best books I have read for quite a long time. Great read. Highly recommended.

After reading a few of the recent team stories in ‘Beautiful Games’ about Computech and the creation of the ‘Little Big Planet’ game, an idea came to me about their beautiful teams and our beautiful countries. It seemed to be a great topic for a Blog post just after our National Holidays. My apologies for writing it on July 5th, but sometime you can’t schedule ideas. 🙂

Many of their stories talk about the balance between staying true to the vision and to the team members. It is something that I am sure many teams struggle with on how to balance these two opposing forces. I then realized how the countries of Canada and the United States of America are perhaps a great example of how the cultures of the countries can reflect these principles.

United States of America

One thing I have always admired about our neighbours to the south, is their patriotism and commitment to the vision of the country. Now there may be differences as to what we think that vision should truly be, but the amount of passion and commitment to the country is inspiring. In Canada, the vision of the country sometime seems to thought of after the individual. We expect we will stay true to the vision of Canada based on how we treat and embrace our diverse citizens. In many ways I think this is true, but in some ways I wonder if this causes a vision to be dispersed and stretched like too little butter spread on toast. (Tip of the hat to J.R.R. Tolkien) Our national identity and vision seems to be less focused than it was in our past.

I believe being committed to a vision is to be committed to principles and an ideal that usually requires individual sacrifice and placing the needs of vision above the needs of the individual or the team. This usually results in the individual having less to ensure the vision is maintained. This commitment to vision is embraced vibrantly in the USA.  


One thing I have always admired about my country, is our commitment to our fellow team mates and citizens. Not everyone in Canada shares this commitment, but I do believe that this ideal is more pronounced in Canada. I believe we consider it our duty to give our ‘fair share’ so those that are less fortunate can be afforded the basic necessities of life. We can discuss whether we do enough in this regard and whether the actions achieve the desired result, but I believe it is core to the culture of Canada to help our fellow citizens as best we can. I think this concept can be easily extended to project teams and commitment to all team members.

In ‘Beautiful Teams’, the story on Computech had a great example on why commitment to all team members is so important. They told the story about an ‘underperformer’ and the extra work this ‘underperformer’ required from everyone. Wouldn’t they be a better team without him?

The answer is a resounding no. How a company works with ‘underperformers’ and helps them grow and work shows the commitment the team has to all members at all times. This loyalty to all team members results in more creativity, innovation, loyalty, and trust in the team because they know everyone has ‘their back’. They know that they will not be fired when they make a mistake.


In combining the best of Canada and the USA, I know we could create a beautiful team. We will have commitment to the vision and commitment to each other. I noticed two things as I typed this:

1)      This discussion made no distinction between managers and team members. This is good, we are all team members.

2)      There was no mention of the individual. Individual needs come after the Vision and the needs of our team mates.  It is logical! (Tip of the hat to Gene Roddenberry)

At the end of the day, the organizational must balance the needs of the individual, team, and vision properly to create a high-performing organization. The emphasis placed on each item may fluctuate over time based on situations, but they need to be balanced over time.

When I reviewed what I perceive to be great organizations, they balance these needs exceedingly well. (From both a short-term and long-term perspective) This is true whether the organization is Unionized, Governmental, Private, or Entrepreneurial. (although the balance in each type of organization can be different as can the type of person that wants to belong to each type of organization)

I believe that combining the USA’s commitment to Vision and Canada’s commitment to our Teammates does create a Beautiful Team.

#Agile Leadership and Reality TV

After being on many Agile teams and reading a lot of thoughts on leadership, I find it harder and harder to not pay attention to leadership (good and bad) in other aspects of life. One of these situations arose last night in Gimli after a long day at the beach.

Master Chef

My wife and I sat down to watch Master Chef after the kids finally went to bed and although I find the process of making the food interesting, unfortunately the leadership demonstrated in this show is similar to what I’ve seen previously on ‘The Apprentice’. And no, that isn’t a good thing. These people are called Project Managers, but they are setting back leadership and Project Managers decades.

Here is what I have observed:

1)      People only want to be Project Managers when they think they can win. This seems to be one of the main criteria for when and where they take a turn as Project Managers.

2)      People become Project Managers with the primary goal of showing what they can do. There really isn’t the concept of winning with the team. The goal of winning is all for themselves and their ego.

3)      And perhaps the worst of all; People seem to want to be Project Managers so they can order people around and make all the decisions on how things will be done. It seems that people love being Project Manager as they feel that can finally decide how everything gets done and get back at the one person that they hate. These people really do need to read the Prime Directive.

So it really isn’t a surprise when almost all of the projects fail. The projects that do succeed do so in spite of the Project Manager not because of it. And when the project fail, there is the stereotypical rounds of blame and people avoiding blame.

In many ways, they are holding Post-Mortems and not a Retrospective as they are not interested in saving future patients, just in coldly finding a reason for the project’s death. (even if it is the wrong one..)

Silent Brainstorming

The ‘brainstorming’ that occurs on the shows can be a commercial for why Silent Brainstorming is so useful. The team sits around the table yelling out ideas with the loudest person winning and the Project Manager ultimately overriding any ideas to fit his or her vision.

When I explained Silent Brainstorming to my wife, she immediately saw the benefit of the technique and hit on one other aspect that I never considered. On Master Chef, ideas were shot down and dismissed just due to whom brought them forward before they were fully considered. Usually this was due to a personal bias towards one person and their ideas. (i.e. a grudge) Silent Brainstorming would help to prevent this selective dismissal of ideas. When I think of Silent Brainstorming, I think about how it helps to bring out the best in people and help to bring out ideas that people may be too shy or reserved to bring forward. But in addition, it certainly can help to limit negative behaviours and their impact on brainstorming.

She agreed that Silent Brainstorming would be the ideal way to gather ideas for the best plan possible.

To be honest, there was no brainstorming going on. Just yelling.


I am currently reading ‘Beautiful Teams’ and they have one quote that captures my feelings on what leadership and Project Management should be.

Edwin Schlossberg once said about writing: “The skill of writing is to create a context in which other people can think”. I think this idea is so profound and true it can easily be extended to leadership and Project Management:

“The purpose of leadership and Project Management is to create a context and atmosphere where team members can think, innovate, and create ideas. In addition, Project Managers and leaders are just one voice equal to all the others when it comes to ideas and innovations.”

The #Heart, #Mind, and #Soul of #Leadership

Frequently when I see discussions of Agile Leadership, I have mixed feelings. Although I believe the intent of these discussions are focused on how to make projects and teams better, I do have problems where we immediately create two classes of agile practitioners: Agile Leaders and the rest. To me, it just didn’t seem right.

I have had some great discussions recently on what an Agile leader is and what makes a great leader. Unlike stereotypical leaders, Agile leaders are not expected to make all the decisions and define the vision for the team. Those responsibilities belong in a more standard command and control project structure. So what then is an Agile leader? What do they do?

I reviewed the people who I believe are exemplary leaders. They were from a variety of sources:

  • Wadood Ibrahim – Protegra
  • David Angus – Chamber of Commerce
  • Steve Yzerman – NHL Centreman
  • Ray Lweis – NFL Linebacker
  • Neil DeGrasse Tyson – Astrophysicist
  • to name but a few…

Three statements

My opinion of an Agile Leader and leaders in general are summed in three simple statements:

  1. Honest care and concern for all team members and clients (the Heart)
  2. Relentless effort to increase the value to the client and team members (the Mind)
  3. Relentless hunger to learn and improve. (The Soul)

Honest care and concern for all team members and clients

One of my favourite leadership quotes is:

Before people care how much you know, they need to know how much you care”

I must admit I do not know whose quote it is, but I believe it captures the heart of leadership. Before anybody will consider following you, they must trust you. And to trust you, they must understand that you honestly have care and concern for their opinions and well-being. Can you direct people without this trust? Sure you can, but we call these people managers instead of leaders. These are people who direct by position instead of leading by trust.

Relentless effort to increase the value to the client and team members (the Mind)

Great leaders I have worked with all share this relentless effort and work ethic to make the team and project the best that it can be. The video below from Ray Lewis shows the effort level that defines a leader:

Ray Lewis-Effort

Great leaders are able to relentlessly improve the value to the client and team members without making those decisions for the client and the team members. This is an important distinction to make. The leader can not make the decisions for the client and team members and expect them to follow. Great leaders have exceptional influencing skills, but also believe that the client and team have the ultimate decision on what value is and what improvements make sense. Great leaders do not get caught up in making improvements themselves, rather they focus on the facilitation with the team and client to make improvements.

Relentless hunger to learn and improve

Great leaders have an open mind to all new ideas. They seek on new ideas and concepts. They seek to understand before commenting. They honestly believe that none of us is as smart as all of us.

One anecdote I love that illustrates this point is about Ray Lewis. Ray Lewis had just learned that Mike Singletary (former Bear’s linebacker) was the new defensive co-ordinator for the Baltimore Ravens. I believe Ray Lewis had been in the league for over 5 years and at this point and had already made the Pro Bowl and possibly already won a Super Bowl. The first day Mike Singletary showed up for work, Ray Lewis was in his office at 6:00 am asking him to teach him. That demonstrates the hunger for improvement and leading that true leaders have better than any other anecdote or quotes I have heard. I can imagine the impact this had on the team’s other players when they heard of this hunger to learn.


I believe Agile Leaders and Leadership have the three characteristics of Care for the team, Effort to improve, and hunger to Learn. All the people I believe to be great leaders share these characteristics. In retrospect, these characteristics don’t define great leadership – just great team mates. Maybe that is all great leaders are? – Thought for another day…