Friday, May 18, 2018


I am still reading Daniel Kahneman's Thinking, Fast and Slow, and I came across an interesting quote
People can maintain an unshakable faith in any proposition, however absurd, when they are sustained by a community of like-minded believers. 
He used the example of stock traders, who think they are successful in picking stocks even though evidence points otherwise. Two out of three mutual funds underperform the overall market in any given year. However stock traders still believe in their approach.

I thought of the example of project management. I went to my first PMI conference in 1999. I was surrounded by like-minded believers in the waterfall methodology for project management, even though evidence such as the Chaos Report showed that our approach was not effective.

Will we see the same effect with agile approaches? Will we fool ourselves into believing we are successful even if the evidence suggests otherwise? Maybe not.

Philip Tatlock did research for his 2005 book Expert Political Judgment: How Good Is It? How Can We Know? Tatlock interview 284 people covering 80,000 predictions and even though these people were "experts" their results were worse then if these predictions were simply assigned probabilities. To compound the effect, the experts were very reluctant to admit that they were even wrong.

Kahneman sums it up pretty nicely. He says that the "errors of prediction are inevitable because the world is unpredictable." (p. 220) He goes on to say that short-term trends can be predicted but not longer term ones; though even the dividing line between the two is unpredictable. The implication to planning is clear; keep the planning horizon short and don't fool yourself into believing you are better than you really are.

Sunday, April 15, 2018


I'm working on the book Thinking, Fast and Slow by Daniel Kahneman, who won the Nobel Prize in Economics. As you might guess, the book is about how the brain works, based on years of research. He talks about the mind as two systems, the first being fast and intuitive and the second being more deliberate.

One of the ideas he discussing is that of Priming. Priming happens when something such as a set of words impact our thought and actions. He gave a great example of an experiment with two sets of participants. One set was given a set of words associated with being old (gray, wrinkle, Florida) and another group had words not associate with being old. They were asked to create sentences with the words. They were then asked to walk down the hall for the next experiment. The group with the "old" words walked down the hall much slower than the other group...these were all college students so it had nothing to do with their actual age. One group was primed; they had the idea of old planted in their minds and they acted differently because of it without knowing it.

In another experiment, people were asked to put money into an "honesty box" based on how much coffee or tea they drank. There were different posters placed on the wall above the money box. On weeks when the posters had eyes looking down, people paid more money than on weeks when the posters were of flowers.

Think of how easily priming could impact a team. Imaging a team trying to overcome a complex technical challenge such as getting a test case to pass. They aren't sure why it isn't passing and they are discussing solutions. One person's comments could lead the team all in the wrong direction without them even realizing it.

So how do we combat this? The reason priming happens is because our fast, intuitive mind takes over. To combat it, we need to rely on our more cognitive side, which Kahneman points out is also lazy and willing to let the intuitive side run the show. For this imaginary team, using a red teaming approach might work, or an analytical took such as Five Whys. Anything that will get the team to look beyond intuition and engage their more deliberate thinking patterns.

As far as Thinking, Fast and Slow, I'm only about a quarter of the way through and have come across a lot of interesting ideas, so I am sure I'll have more to post on the book.

Tuesday, March 13, 2018

Team of Teams

I recently completed the book Team of Teams by Stanley McChrystal, a retired Army General and former commander of the Joint Special Operations Task Force, operating in Iraq. It's the story of how he transformed that command in order to more effectively execute their mission.  

The book explores the ideas of complicated and complex. I kept thinking about the Cynefin framework, though McChrystal does not specifically mention it in the book. The book starts by talking about the work of Fredrick Taylor around the start of the 20th century (complicated). He then gives some examples of complex problems. My favorite was the introduction of the cane toad in Australia.  

The book then goes into how McChrystal moved his command away from a strict command structure and to a team of teams structure. This change made them more resilient, allowing them to more effectively respond to the enemy.  McChrystal makes a point to show how efficient and resilient are on opposite ends of a spectrum, and being resilient was more important than being efficient. The move to a team of teams was done by cross-pollinating individuals across teams. There was also a liaison program to work with external organizations.  

The parallel between Team of Teams and John Kotter's book Accelerate are interesting. Both recognize the hierarchy can't support today's environment. McChrystal saw the team of teams as a way to be more resilient so that the organization could respond quicker to threats. Kotter viewed it as a way to implement strategy. In both cases, the hierarchy remains, but it is supported by the teams.

The agile world is catching on as well. The Scrum@Scale guide references McChyrstal's book when describing the Scrum of Scrums. I've been trying to build this with my teams. For example, shifting from a status meeting where people report to the manager one at a time while everyone else has their nose in their computer to everyone interacting and building a shared consciousness. The first step, banning computers from meetings so people pay attention.  

Another idea I'm trying is similar to how Spotify uses guilds to share across teams. I'm bringing together developers from across all the teams to discuss technical topics of their choice. We kicked off the initiative by creating an operating agreement, identifying the topics of interest, and picking a topic for the next meeting. I believe this can lead to a number of outcomes: a better shared understanding of the department's work, the ability to move developers more effectively from one team to another to meet changing priorities, and improving skills across all the teams...again, along the line of team of teams.

I recommend Team of Teams for anyone that is working with more than one team and trying to figure out how to create a resilient organization that can keep up with a rapid pace of change.

Thursday, February 08, 2018

Situational Awareness

I have been exploring techniques to help my Scrum teams become more effective and one of the techniques I've been looking at is Crew Resource Management (CRM).

CRM came about because of a number of airplane crashes in the 70s that were attributed to human error. More recently, it is cited as one of the reasons there were no causalities in the US Air flight 1549 (Miracle on the Hudson).

One component of Crew Resource Management is Situation Awareness. A simple definition of situation awareness is how well your perception matches reality. There are a number of factors that can impact situation awareness such as complacency (I've done this so many times…), task saturation (too much work in progress), channelized attention, or poor communications.

I had a situation recently where my scrum master lost situation awareness. We were at the end of the sprint and he told me the team had completed 45 story points, more than any previous sprint. However, a conversation with the product owner a short time later revealed that really wasn't the case. The product owner wasn't satisfied with how some of the work was done.

What happened? The scrum master was fixated (channelized attention) on what the developers were telling him because he wanted to be able to show all the stories done for the sprint. He lost site of the definition of done, which included a review with the product owner before a story was marked done. 

Our kaizen for the week was a review of our definition of done and re-commit that nothing would be marked done without a product owner review. We took this idea into planning and included tasks for product owner review in each story so we could track these tasks to completion on our board so that the scrum master had additional visual cues to help him with his situational awareness.

So how can the team keep better situational awareness? Having a good visual board helps. In addition to tracking work thru the To Do/Doing/Done path, the board also has a place for impediments, the definition of done, release plan, and a burndown. For this team, the board is also in the team room, and any time I walk in, I stand near the board when I'm talking to the team and encouraging them to look at the whole board, similar to how a pilot is constantly scanning all their gauges so they don't miss anything (as opposed to the crew of Flight 173, who fixated on a landing indicator light and forgot to keep check on their fuel).

Wednesday, January 31, 2018

Psychological Safety

I had an interesting experience recently. I was working with a team as they went thru their sprint planning. They had figured out their capacity based on yesterday's weather and their average amount of interrupt. The product owner suggested the sprint goal and they started picking stories based on the goal. They reached the point where one more story met the sprint goal, but put them over their estimated capacity. The scrum master pulled it into the sprint and said he thought they could get the story done.

At this point I stepped in and commented that it was up to the developers to decide if they wanted to commit to the work. The developers remained silent. I made a comment about not over-committing and finally some comments were made by the team to keep the story out and pull it in if they get everything else done.
So what happened here? Why didn't any of the developers speak up when the extra story was first pushed on them? Based on this and other observations in the organization, I attribute it to a lack of psychological safety. The developers didn't feel safe to say "No, that's more than we can get done."

I wrote another article recently talked about group think. The two ideas are related. Group think exists in situations where people don't feel safe stating an opposing view. But psychological safety goes much further than that. A team without psychological safety will be reluctant to take chances, it impacts their ability to learn, they will be afraid to admit mistakes. In general, it keeps them from becoming a high-performing team.

So how does a team fix this? The reality is they can't. It's not the team but the organization around the team that will or won't create a space of psychological safety for the team to exist in.  Product owners and chief product owners need to be coached to understand how their actions impact the environment. It's starts with them showing they are vulnerable, by admitting their mistakes. They need to encourage teams to take risks and not punish failure but show how it can be used as a learning event. It's only when teams see these kinds of behaviors that they will start feeling safer, and next time a developer will speak up and say "No, that's more than we can get done."

Tuesday, December 05, 2017


I am speaking this week at the Projects to the Point (P2P) conference in Cairo, Egypt. The focus of the conference is the book "How Successful Organizations Implement Change" and the speakers (myself included) each wrote one of the chapters of the book by the same title.

We have an interesting approach for implementing change where I'm working, a technique call Nemawashi. It's a Japanese term that literally translates to "digging around the roots" but the meaning is much more than that. Nemawashi is laying the groundwork for a change. The work starts before any formal meeting is conducted. Ideally, the person proposing the change will have already worked on building the relationships with the people who's support is needed. They will know the formal and informal organizational structure so when it comes time to start informal discussions, they know who to speak to.

When it comes time for a change, the change agent determines who the key stakeholders are. The change agent has informal discussions about the proposed change. It may be a quick talk over coffee accompanied by a drawing on a napkin. The discussion may include a history of the proposed change, others that have been consulted, and options. The discussions are a way to solicit feedback and adjust the plan before moving forward. In some cases, they may need to move backwards, having follow-on discussions with stakeholders they've already talked to as the plan evolves.

When it does come time for a formal meeting, all the key stakeholders have already heard the idea and provided their input. The formal meeting should just be a formality. If someone hasn't been included in the nemawashi process, they may reject the proposal just because they feel they were ignored.

This form of consensus building may not be the fastest way to introduce a change but like the meaning of the word, it will ensure that a new change gets to the roots to improve the chance it will take hold.

Thursday, November 09, 2017

PMI Conference observations

The PMI Conference was held this past weekend in Chicago. They've changed the format a bit and even changed the name to reflect the changes. When I first started attending almost 20 years ago, it was the PMI Symposium, then Global Congress and now the PMI Conference.

They had 3 different keynote speakers (though I only saw 2 of them), one each day. On Saturday, the speaker was Sir Tim Berners-Lee, the person that developed the technology that made the world wide web possible, specifically hypertext transfer protocol (HTTP). He talked about how a goal was to make the web a "permission-less place" where anyone could put up a site.

The web developed first through creativity, then collaboration as the world wide web consortium evolved. He did highlight a point of complex systems, that the behavior at the macroscopic level is different than on the microscopic level. While I thought the talk was interesting, some of my non-IT colleagues had trouble following it.

Sunday's keynote was very interesting. The speaker was Nicholas Epley, author of Mindwise and professor at University of Chicago. His presentation was on communications, along the lines of this article he wrote for Huffington Post. He ended with 4 take-away's:

1) Be wary of any gimmicks when it comes to trying to understand others. Always ask for evidence.
2) Cut down your confidence in how well you think you understand what someone else is thinking, you understand them less than you think.
3) Learn to ask questions well, it's the best way to gain an understanding of what someone else is thinking.
4) To communicate well, be painfully clear. Don't assume the other person will easily understand your message.

The best session I sat in on was delivered by Ahmed Sidky. He talked about how the leadership structure of agile teams evolved at Riot Games. Rather than assigning roles such as scrum master or product owner to individuals, they identified 4 key leadership roles;

Team Captain - responsible for overall delivery
Product Lead - responsible for the direction of the product
Delivery Lead - responsible for development
Craft Lead - responsible for the engineering

Each team would associate key responsibilities with the four "hats" as they call them. A team member can wear more than 1 hat but the team decides all of this.This approach takes self-organizing teams to a new level.

I also took part in an interactive session on the new Agile Practice guide that came out with the latest PMBoK. It was led by Jesse Fewell and Mike Griffiths, both long-time agile names in the PMI community.The session was a good way to start understanding what is in the guide.

PMI tried to improve he quality of the sessions. As a speaker, I had to go through a few additional hurdles including creating a story board that was reviewed by an SME and practicing my presentation on the phone with a experienced speaker. I don't know if PMI got the results they wanted. There were regular speakers that did not speak because they didn't want to go through the additional steps. At the same time, I still had 2 sessions I walked out on because they didn't meet my expectations.