How #Empathy is fixing #Canada

I’ve talked about how Empathy is so important in understanding client needs in the past, how Empathy is important to understand what a client really requires and needs. The other side of Empathy is understanding what your team requires.

Ultimately, Empathy results in Prosocial behaviour. Prosocial is a term I only recently came across. Let’s quickly review the definition from Wikipedia:

Prosocial behavior –  “is a social behaviour that “benefit[s] other people or society as a whole, such as helping, sharing, donating, co-operating, and volunteering. Obeying the rules and conforming to socially accepted behaviors (such as stopping at a “Stop” sign or paying for groceries) are also regarded as prosocial behaviors. These actions may be motivated by empathy and by concern about the welfare and rights of others”

Ultimately this describes team behaviour and client service focus that we like to see in our project teams.

Canada

My country has always prided itself with having a good global conscience. But really until the last little while we have not shown ourselves to be empathetic at home. Let me call attention to a couple of recent news items. The tragedies of missing and murdered aboriginal women is the first item. For the longest time, the media and the majority of Canada have spent a lot of our efforts trying to state why this is someone else’s problem. We haven’t really empathized with the problem. We have hidden behind the fact that the situation was created by our ancestors and not us. In short, we felt comfortable doing nothing unless we were directly responsible. Myself included. 😦

Let’s review the definition of Empathy again:

Empathy – “is the capacity to understand or feel what another being (a human or non-human animal) is experiencing from within the other being’s frame of reference, i.e., the capacity to place oneself in another’s position.”

We haven’t truly put ourselves in the shoes of the aboriginal families and really felt their pain. Recently we are starting. Canada has become outraged that this is happening and everyone has demanded as a whole that this be fixed now. Finally we have exhibited Prosocial behaviour and demanded that this is fixed even when it will result in no personal gain. In some way we are demanding change that will even hurt us by taking money and attention away from other priorities. But we understand that it is the right thing to do. Maybe we are finally gaining some true Empathy.

A similar occurrence has happened recently with the Freedom Road that is finally being built to address a long-standing injustice committed against Shoal Lake #40 First Nations who were isolated by the city of Winnipeg building an aqueduct in 1915. How it took 100 years for our community to become Empathetic and outraged at this situation is unbelievable. But at least now it is being addressed. Finally we have become empathetic and are being Prosocial with our demands from our politicians.

We can even see this recently with our neighbours from the south. For the longest time the United States were content to also determine excuses as to why the number of murdered black men were not a problem. Everyone investigated the victim’s past history, looked in their behaviour that night, and also said much of the violence was black man on black man so certainly there is no racism issue. Finally the United States is demonstrating Prosocial behaviour and also demanding that something be done to address these issues.

The truth is until large groups are willing to be Prosocial and take a stand on issues, they will never be addressed.

In retrospect, the majority of Canada was not empathetic to the massacre at École Polytechnique. 28 people were injured, with 14 Canadian women losing their lives that day. We grieved and mourned, but we didn’t truly empathize and demand action. The best we could muster in the past was Sympathy. We certainly have been sympathetic in the past but finally it seems Canada is learning how to be empathetic.

I see an interesting similarity with the Muslim people and countries around the world in relation to terrorism. Although people are sympathetic with the impact of terrorism, we haven’t yet reached an Empathy with the victims and seen Prosocial behaviours. Once we see those Prosocial behaviours, I have no doubt that the situation will greatly improve. Even with the recent tragedies in Paris, there is could be more we could do.

And I don’t believe building walls like Mr Trump proposes is a Prosocial behaviour. If anything, that is an Antisocial behaviour. By Prosocial behaviour I mean that we would see people independently organizing instead of assuming that it is only the Police’s job to stop terrorism.

Summary

Pretty heady topic for Christmas Eve, but it does relate back to our teams. Our high performing teams always are the ones that manage themselves and work together for the greater good and not just for what they need to individually accomplish. We are getting there. Nice to see our world is as well. 🙂

 

My #NoEstimates disappointment

I must admit I usually come right in the middle between No Estimates proponents and the traditional estimators. I usually like the process of estimating on my projects, but I certainly see the downsides of such estimates.

I also do think estimates and no estimates and Lean Start up are not mutually exclusive. I can still do estimating on a project that I am executing in a Lean Startup method. Sometimes I think we search too much for discrete and absolute answers.

Anyway, that wasn’t what disappointed my about No Estimates this weekend. Rather it was a link to this announcement.

My Opinion

If you haven’t clicked on the link, it is an announcement to a No Estimates workshop in October 2014. The link also asks for questions to be submitted to be answered in the session.

So why did this disappoint me?

I’m always disappointed when the pursuit of new ideas, methods, and practices become an economy. I’ve asked some questions of the presenters before and it was mentioned that they would add it to their list of questions and perhaps they would do a future blog post on the subject. Now it appears to get those answers I may need to attend a workshop in Europe. I’m disappointed because I was hoping to hear the answers to those questions other the next few months. Now perhaps I’m wrong and hopefully this workshop will not hinder the flow of ideas over the next few months. But there still does seem to be many questions out there that are unanswered.

For example, “What you you recommend I do first to try No Estimates on a project?”

I Wonder

I also wonder if the No Estimates workshop will be done in tune with No Estimates principles? For example:

1) Will a full price for the workshop be estimated and required up front? Can I attend for a day and leave for a day if the value I expect isn’t being realized? Can I pay day by day?

2) Will the workshop have a set agenda or can the attendees define the agenda in the first hour collaboratively?

3) Couldn’t we try to answer a few of the questions listed first and validate people would get value out of the session before committing a week of time, considerable training budget, and fossil fuel to jet to Europe?

It almost feels like a week-long workshop is against the principles of No Estimates.

Summary

I’m disappointed as I fear there may also be No Estimates certifications down the road ala PMI and Six Sigma.

But I fear that No Estimates will join the establishment of training courses and specialized consultants. No Estimates to me was always about challenging the establishment and not joining the establishment.

As Obi-Wan said in Revenge of the Sith – “You were the chosen one! It was said that you would destroy the Sith, not join them. You were to bring balance to the force, not leave it in darkness.”

Hopefully I’m mistaken.

 

 

 

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…

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

2 Rules of being an #Agile #Coach

I see that many times people talk about being an Agile Coach, but I fear they are leaving out some very important facts on what a successful coach is. The comparison to a sports coach is very easy. Both coaches are working with teams and also in a very dynamic and fluid situation. The definition of a coach from Wikipedia is:

“Coaching is a teaching, training or development process via which an individual is supported while achieving a specific personal or professional result or goal.”

What are you coaching?

I guess the crux of the question is what are you coaching? Are you coaching someone in the Agile Processes or are you coaching someone in how Agile processes can increase the likelihood of success for a project? The difference may appear to be slight, but there are a myriad of factors underneath the subtle differences.

I believe it is easier and of less value to coach the Agile practices. These standard practices can be gathered from many articles and books out there. The more difficult aspect of being an Agile Coach is coaching the team to “win” the project game.

To “win” the project game, I believe a project team must accomplish the following:

1) The client must be 100% satisfied with the solution

2) The team must have enjoyed the project and felt a feeling of fun and accomplishment.

3) The trust between the team and the client must have at least tripled on a project. (you can pick whatever number you like, but I feel the increase in trust must be significant)

2 Rules of being an Agile Coach

1) There can not be multiple “Oh Well” moments

Sometimes Agile projects propose that we will not provide an estimate and just work on items according to the client’s priorities. While this is good work if you can find it, it certainly does not prevent the “Oh Well, I need more money” moment. It also does not build up trust be between the project team and the client. If anything, repeated incidents like this will diminish the level of trust and may force the client into a more traditional approach. Agile teams must remember that even if we operate it an Agile manner, the clients need to request budget in a very traditional manner. When we have an “Oh Well, I need more money” moment, it makes the client look bad in their traditional environment. You get one, maybe two, “Oh Well” moments on a project before you are back in WBS hell…

So what can we as Agile Coaches do with the uncertainty we face?

2) There must be a holistic plan and a solution vision

It is only my opinion, but I believe that an Agile Coach must, must, must have a vision for what the plan is and what the solution will look like. He or she can then help to guide the team as issues arise. Now this isn’t to say that they can override the team, but they do need to remind the team when an issue looks to be compromising a major project objective or constraint. The Agile Coach has the responsibility to ensure that the project doesn’t just happen, but rather he or she helps the project to achieve what was intended. Most importantly, the Agile Coach must raise issues to the client while there are still multiple options. If the Agile Coach only raises an issue when there is only one solution, get more budget, the trust level will start to take a nosedive. Agile Coaches must remember that the client sets priorities on all project activities – including solution options.

Included in this rule is the fact that the Agile Coach must be very aware of the S-Word. Schedule. 🙂

Part of having a holistic plan is having a preliminary schedule. If you do not have a preliminary schedule, you likely will not be able to raise issues early enough so that the client has multiple options. Having a preliminary schedule allows you to be very aware when iterations start to consistently be late and can compromise the project objectives.

Remember it is all about building trust and ensuring the client has multiple options when an issue is presented. It is all about building trust every week on the project.

Proper Coaching Definition

I really, really like this definition…

“A professional partnership between a qualified coach and an individual or team that supports the achievement of extra-ordinary results, based on goals set by the team “

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.

Analysis

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.

Summary

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.

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