What is a Team

The last couple posts have focused on teams, but I haven't addressed a basic question; What is a Team? 

I ran cross-country in college, so I was on the team, but was it really a team? On days we had meets, it was really everyone for themselves out their on the course. Once we left the starting line, I would see little of my other teammates until we all finished the race. I could have completed without the rest of my team, and it wouldn't have had an impact on my performance. Sure, we had a coach shouting encouragement, but having a coach doesn't make us a team. 

I recently came across the book Leading Teams by J. Richard Hackman. In the book, he outlines the five conditions that need to be in place for a high-performing team. Among the list is the idea that it has to be a "real" team. He defines this as meaning the team has shared responsibilities, clear boundaries, and stable membership. 

I have worked with more than one team where there was no shared responsibility. Each person had their own role. User stories were assigned to the person that knew how to complete that specific type of work. When I encounter a team like this, my first inclination is to start pairing people on work. In the short run, it makes the team less productive but in the long run the team becomes more agile because each person has built additional skills and they don't get stuck because only one person can complete a certain task. 

Boundaries are important because it keeps the team from being inundated with work. In Team Topologies, Skelton and Pais talk about cognitive loads. If you put to much work on a team, it diminishes their ability to deliver, just like to many things in my "doing" column causes me to suffer from task-switching. 

Clearly, there has been a lot written on teams. Going back to the example I started with, my cross-country team doesn't fit into the category of a real team, but a basketball team would. If we start looking at our work teams thru the lens of Hackman, we can start seeing how we can build more effective teams. 

What is the Right Team Size?

Team in front of Computer Code, generated by DALL-E 2

 What is the right size for a team? Can it be too big or too small? I worked with a team once that had 3 developers. They spent most their time mob programming in front of a 42 inch monitor, taking turns at the keyboard. They didn't need to do traditional stand-ups because they were swarming around one thing at a time. The Scrum Master kept an eye open for impediments, but otherwise was focused on the next thing that would improve the team's productivity. 

I also worked with a team of 15. My first thought was that was too big, but as I watched the team work, I saw that wasn't the case. The team was doing data-science kind of work. They needed people who could write SQL to pull data from legacy systems and put it in data lakes and people who could take that data and package it in a report with Tableau. For this team, having all the skills on one team meant they didn't have dependencies with other teams. 

An often cited paper by George Miller states the magic number at 7 +/- 2 people (sometimes referred to as Miller's Law). The 2-pizza rule says a team should be small enough to feed with 2 pizzas. Robin Dunbar's research suggests 15 is the upper limit of the number of people we can deeply trust. 

There are other considerations beyond just the number of people. As I pointed out in my last post, dependencies slow teams down. My 15 person team was big, but still effective at delivering because they didn't have dependencies on other teams. 

This larger team also had true cross-functional skills. My smaller team was effective because they were developing in a narrow field and didn't need a broad range of skills. However, if they found they were having dependencies on another team because of a missing skill, enlarging the team to include this skill could be a smart move. 

In the book Team Topologies, Matthew Skelton and Manuel Pais talk about cognitive overload. Teams can only handle a limited number of different areas of focus. If the team is asked to do too many different types of work, the effectiveness of the team will suffer. Just like individuals can't multi-task effectively, neither can teams. So when deciding on the team composition, this should also be taken into account. My 15 person team was probably suffering from cognitive overload, but I wasn't looking for that at the time. 

Too often I see teams put together without much thought. Worse yet is when people are partially allocated to more than one team. I think regardless of what framework or methodology you are using, you need to start off with deliberate thought about how to set up teams. I would recommend the book Team Topologies for guidance on this topic. 

Even the Best Chefs can't make a bad recipe taste good; why someone else's Agile Transformation recipe may not work for you

 I've been reflecting on some of the agile transformations I've been involved in over the past few years. In some cases, I see some real progress made. Other times it seems like just re-arranging the deck chairs on the Titanic. An organization follows some recipe, but they don't get the results. Why?

I was working with a large financial institution. They had adopted the "Spotify Model" (yes I know, it's not a real thing) and after that they adopted another scaling framework. I came in and started looking at what was going on and discovered they had a huge challenge with dependencies across teams and products. They failed to realize how much the dependencies on other teams was slowing any one team down.

I took some on-line training recently, a course called Agile Physics - the Math of Flow led by Troy Magennis. In it, he talks about Amdahl's law, which was developed in the late 60s to explain parallel processing. The bottom line is that there is always going to be a limit on how much additional output you can get by adding more processing power. Troy points out the law applies to people and teams as well as CPUs.

One source of the limit is how much can be done in parallel, or said another way, how much dependency there is between teams. So two processors (teams) in parallel with no dependencies can produce twice the output of one. However, as less of the work can be done in parallel (ie, dependencies), the output drops. Using the formula Amdahl developed, if you have 4 teams and 80% parallelization, your output is 2.5 (not 4). If you want to learn more, take the course...it's free and some really interesting ideas.

Back to my client with all the dependencies. What could have helped them? Maybe if before they applied the recipe for scaling, they took some time to look at how their teams were set up and came up with a better approach there, that is, one that reduced/eliminated dependencies. More on this idea in a future blog post. 

Is it Time for Holacracy?

I was doing some research last weekend on Holacracy for a course I’m developing for University of California - Irvine Extension. I have been teaching for them for about 8 years now and I’m helping update their agile class offering.

Holacracy really turns the industrial revolution style of organization on its head. Rather than leadership making the decisions for the workers to execute, the decision making is really pushed down to the people doing the work. The traditional hierarchy is thrown out the window. No more managers reporting to department heads reporting to business unit managers reporting to Vice Presidents…you get the idea.

Instead we have circles. For example, IT may be a circle. In it, each role has a description that gives clear direction on the responsibilities for that roll. There are simple rules that guide people, what they can and can’t do. It is a form of a complex, adaptive system. Everyone focuses on the purpose of the organization, which goes beyond making money.

So what can Holacracy do for us now? With Covid-19 and work from home, the landscape of the work environment has changed. Will Covid-19 be the forcing function that changes the leadership model at companies? Does a remote workforce change how decision making occurs in an organization?

When companies first tried the work from home approach a number of years ago, there were often strings attached. Companies would use the instant messaging app to track when people were at their desks, showing a lack of trust in employees. Are companies ready to stop monitoring output (hours at a desk) and start looking at outcomes?

Holacracy isn’t for everyone. Medium moved away from it when they felt it didn’t scale like they needed. After Zappos moved to Holacracy, they offered employees a severance package. Some of those that took it cited holacracy as the reason they were leaving. Today, Zappos has moved away from a pure Holacracy (article). They are still self-organized, but in a slightly different way.

Amy Edmondson and Michael Lee wrote a paper on the topic of Self-Managing Organizations. One of the quotes from the paper was this: “Longstanding research tradition suggests that managerial hierarchy functions more effectively in stable conditions, but faces serious challenges in dynamic conditions.”

In the latest update to the Scrum Guide, Jeff Sutherland and Ken Schwaber have moved from saying self-organizing teams to self-managing teams. In his book Reinventing Organizations, Fredrick Laloux provides several models of companies in some form of self-managing. So maybe Holacracy isn't for everyone, but it seems like organizations are moving to more self-managing models.

What the Military can teach us about Sprint Planning

As a coach, I've seen many Sprint Planning sessions. Some are more effective than others. When it comes to planning, the military has a long history and we can learn a few things from them.

Plans are worthless, but planning is everything

                                                                              - Dwight Eisenhower

I have always interpreted the meaning behind this quote by Eisenhower to mean that through the act of planning, we gain a shared understanding of what we are attempting to do; the plan itself may change, but the goal won't

The military talks about "Commander's Intent" which looks at the mission, the desired end state, and the purpose of an operation. While this seems to be bigger than a sprint goal, a good sprint goal will help the team understand the end-state of the sprint.

If the team has a good sprint goal, it will help them deliver on the intent but still give some flexibility on how they deliver. Without following any specific military planning technique, here are some other aspects of a military plan that we can borrow in our sprint planning:

• Resources & People: Do we have all the equipment we need? Are test environments ready? Do we have test data? Do we know who is going to be available? Any planned vacations or holidays that impact the sprint? I encourage my scrum masters to keep a spreadsheet to keep track of the team so they can tailor their capacity to the available developers. 
• Lessons Learned: Have we included kaizens from the last retrospective into our plan? Do we have them on the sprint backlog?
• The Plan: The team should self-organize around the work that needs to be accomplished.
• Contingencies: Once we have a plan, do we thing about what could go wrong, a technique the military calls Red Teaming. What do we do if the test environment goes down? What if that snow being predicted for the end of the week is worse than they predict?

Taking the extra time to discuss all these aspects to the plan will build a stronger understanding of the plan, which will help the team make better decisions when things don't go according to plan.

Getting Rusty

I was in the Moab, Utah area last weekend and got some mountain biking in. I haven't spent a lot of time mountain biking this year so I was a bit rusty. By the second day I was starting to get my rhythm but it took a little time.

Just like mountain biking, our agile skills can get rusty. I ran a Lean Coffee last week and before it I read a couple articles because I hadn't done a Lean Coffee in a while and wanted to make sure I didn't miss anything.

I've been working with some of my newer Scrum Masters on facilitation techniques, another skillset that can easily get rusty if you don't do enough of it.

One of my favorite facilitation tools is POWER;

Purpose - why are we having this meeting/workshop.

Outcomes - what do we expect to walk away with.

What's in in for me - Why will participants want to attend and what can they get out of it

Engage - how will you as the facilitator engage the participants. Think about activities, items on the tables to play with, or even snacks.

Roles & Responsibilities - What can the participants do.

I like using this as a way to prepare for workshops so that I can make sure the workshop provides value to the participants. Using this keeps me from getting Rusty on my facilitation techniques.

If You're Going to Offshore, Get it Right

In general, I prefer having fully co-located teams but I've been working with a number of organizations that use off-shoring as part of their delivery model. Some have the right approach, others are missing the mark.

When one organization I worked with decided to move to a Scrum framework, they were also setting up an off-shore model with developers in India. In this case, they brought those developers to the U.S. to be part of the team formation process; learning the Scrum framework, setting up a team operating agreement etc.

When these individuals went back to India, they were set up with the right equipment; good audio and video capability that gave then a tele-presence ability. Each morning the US based part of the team would go to a video conference room and spend the first part of their day with the India part of the team. They could see/hear each other well, share documents, and even walk through code together. It was a pretty effective approach.

Counter this with another client of mine. They also have India-based developers, but they have not had the opportunity to travel to the US. They don't have any real tele-presence, just conference calls and screen sharing. They don't really participate, just listen in on discussions from a US based conference room. Self-organizing is also absent, they are assigned tasks by the lead developer, who is in the US. My observation is that they aren't getting much value out of this approach.

I'm a fan of the Media Richness Theory and have used it with my clients. I have also taken a page from Crew Resource Management (CRM) and their communications practices. One of my favorite assertive communications tools is SBAR (situation, background, assessment, recommendation). I have taught this technique to a number of teams as part of a focus on building up their teaming capability.

Given the choice, I would have all my teams co-located. When that isn't possible, I try to bring them together as often as possible and use good tele-presence tools when they are not together. Regardless of your model, you still have to teach them good communications and teaming techniques so they can be as effective as possible in any configuration.

How to Budget For Your Company’s Technical Debt

Guest post by Dr. Mik Kersten

While “technical debt” is a term that’s frequently used by technologists, the implication and understanding of it tends to be opaque to the business until it’s too late - just look at how Nokia lost the mobile market that it helped create.

The business and finance side of Nokia had the usual tools for assessing financial risks - but why do we not have an equivalent tool for the operational or existential risks when the debts come from the more intangible investment in technology?

What’s technical debt?
Technical debt refers to the refactoring "shortcuts" taken in IT to meet requirements like time to value (TtV) and speed-to-market. Technical debt is like cholesterol; the more it accumulates, the more it impedes the flow of value.
Legacy systems are a perfect example of technical debt. We are all too familiar with that system that everyone dreads to touch and hopes that it doesn’t malfunction because any modifications to improve its business value will cost time and money. Yet the longer you wait, the costlier it will get due to lack of knowledge and support.

Speed-to-market pressures also increase the debt – such as first-to-market, responding to time-critical customer needs, and faster customer feedback to improve performance and value. Compromises are made with the notion of dealing with the consequences later.

Sometimes it’s as simple as realizing the technology or architecture chosen for a particular product is no longer scaling and needs refactoring. All of these technical decisions impact delivery speed and must be managed to ensure any future changes or products are not delayed. Taking on technical debt is not necessarily a bad thing, as long as it is understood by the business decision makers who put in place a plan for that debt to be paid down.

Why should the business care – isn’t this a cost that IT manages?
Technical debt additionally impacts delivery teams by bloating their work-in-progress (WIP) with neglected work. Neglected work can impact a team’s ability to focus and complete value-adding work. Less completed work leads to longer time to delivery, lower product quality, and less value, impacting customer satisfaction and business performance.

How can IT make technical debt visible to the business?
In a project-oriented view, where changes to IT systems are just another initiative, it’s difficult to prioritize and fund critical changes that will improve the speed of future changes. Yet software needs to go through a period of refactoring to maintain performance.

A product-oriented view enables the business to understand how all work interlinks, providing the ability to predict and fix for the impact of technical debt. However, you can’t measure what you can’t see, so it’s crucial to make technical debt visible. The Flow Framework – a new way of seeing, measuring, and managing product delivery – introduces two metrics that help increase visibility of technical debt:

Flow Distribution
This metric shows the distribution of the different types of work that the IT team has delivered, such as value-adding work like features and functionality, and revenue-protecting work like defects, security related work. Yet the more new functionality they deliver, the less time they have to do the other types of work like defect resolution, working on security features etc. It’s important to keep an eye on what the levels are for technical debt in this equation. Has the level of completed tech debt work fallen in the last few releases? If so, it is leading indicator of more defects/delays in the future releases. In addition, the Flow Framework expands on the notion of technical debt to include infrastructure debt (e.g., data centers and servers), and debt in the value streams themselves (e.g., lack of automation).

Flow Load
Flow Load is a Flow Framework metric that shows the amount of work that a team or seat of teams have taken on. How much work do they have and what proportion of it is technical debt? Is there a lot of technical debt left in the backlog accepted but unfinished because new work is taking precedence? Accumulating technical debt on the backlog can have an increasingly negative impact a company and its products.

Budgeting for technical debt
There are two parts to budgeting for technical debt.

1)   Correlating the impact of tech debt with value-adding work can help business understand its danger on the bottom line. Time and resources must be set aside every financial year to tackle technical debt as debt often accumulates due to a lack of funding and sponsorship.

2)   IT and business should look at trends that determine an appropriate level for when appropriate action must be taken to “pay back". It’s similar to the error budget in Systems Reliability Engineering that helps product development and system reliability teams work together on a level of unreliability that can be tolerated.

If technical debt is not actively monitored, it will gradually impact the flow of value to customer-facing products. Neglect the build-up and a cardiac arrest is inevitable. Make sure technical debt is visible and measured so that the business and IT can team up to proactively tackle and reduce technical debt to ensure a healthy product portfolio that can sustain the business.

Dr. Mik Kersten is the CEO of Tasktop and author of Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework. For more information, please visit, www.tasktop.com.

Interview at Agile2018

A long-time colleague and friend, Dave Prior, interviewed me at Agile2018 about my presentation on being an agile coach at Toyota. You can find it here.

Agile 2018 wrap up

I'm on my way home after spending the week at Agile2018. It's been a great conference. I reconnected with old friends, met some new ones, and attended some great presentations.

Monday's keynote was Dom Price (@domprice) from Atlassian. He shared how Atlassian tracked team health via their playbook. One interesting statistic he shared was that 78% of people don't trust their team mates. He also hit a theme that was repeated by many of the speaker; focus on outcomes, not outputs.

Focus on outcomes, not outputs

Wednesday's keynote was a focus on metrics by Troy Magennis. At first I considered not attending, but I'm glad I did. Troy talked about data as a people problem. He said a good way to get "crappy" data is to embarrass people. The data isn't enough, we have to be able to tell a story with it.

There were a number of other sessions that I took something away from;

• Scott Ambler talked about architecture. A key message was that there are no "best practices" and the approach you apply depends on the context.
• Tricia Broderick gave a session on facilitation. A point that stuck with me was that if we need to select mentoring or training or coaching based on the situation we're in and our desired outcome.
• David Bland gave a session on experiments as they relate to new products. He turned the cycle in Lean Startup around and said we should start with Learn. From there, we decide what we want to measure, and based on that we decide what to build. 

This is just a snapshot of the fours days I attended. I have other notes and ideas of things I'm going to use when I get back to my "day job" of coaching. I recommend anyone looking for an infusion of new ideas to consider attending next year. 

Regression to the Mean or High Performing

I had an interesting conversation with one of my Product Owners this week. She thought that over time, planning poker values feel prey to Regression toward the Mean because human nature was such that people didn’t want to stand out and therefore tried to give estimates in line with what they thought others would.

I countered by saying if people were afraid to state what they truely thought the value should be, there is probably a psychological safety issue going on. The purpose of using poker cards during the activity is to avoid anchoring; having everyone influenced by one person stating aloud their estimate. 
After the conversation, another idea crept into my head. I tell teams that small stories are better. I am even a proponent of #noestimates in the right situation. So from this perspective, as a team moves towards high performance, they will get good at vertical slicing and that will lead to smaller stories, and therefore smaller estimate values.

So in response to the original statement, I don't think on a well-functioning team, the estimates are prone to regression toward the mean. However, I can see it happening on a team that is dealing with psychological safety issues. The real test is to watch the velocity over time. If regression toward the mean were happening, the velocity would be dropping over time. If the team is healthy, they will have a steady, or even increasing velocity. 

Illusions

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.

Priming

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.

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.

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

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

Nemawashi

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.

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.

Red Teaming

One of the things we talk about at work is eliminating group think and an approach to do this is using red teaming.

For those not familiar with the term, red team comes from the military and originally stood for a team that represented the opposition. It has since expanded to include any team that might challenge the status quo..aka, group think. 

So how does this apply to the agile world? Even agile teams can get stuck in group think. A great example is during story estimating. If you don’t use planning poker cards, the senior developer might say “oh, that’s a 5” and everyone else agrees, they become anchored to his estimate. Someone else might have had a different opinion (that’s going to be a 21 because we have to create a new database table) and they may be right, but they succumb to group think and let the 5 point estimate go. The obvious solution here is to use planning poker cards but sometimes as a coach I need to point this out to teams. 

Group think can happen during any agile activities. During retrospectives, I coach my teams on the approach of each person writing ideas on post-it notes in silence and then discussing them as a group. 

 Think, Write, Share

This way, ideas can surface before group think can crush them.

Red Teaming can be applied elsewhere as well. Another place I like to use it is at the end of a planning session. The team has finished selecting stories to work on for the iteration, they have set their sprint goal and they’re ready to start. At this point I stop them and ask “what could go wrong with this plan?”  This is another good place to inject “ think, write, share” and start a discuss about risks and responses to them.  So be on the lookout for group think and bring in a red team if you need to counter it. 

Debriefs

I’m working on a new assignment as part of an agile coaching team leading a transformation at a large organization. One of my fellow coaches is also a former Navy officer. We’ve had a number of conversations about how many of the techniques developed by the military can be applied to make any team a high-performing one.

One particular tool is debriefing. I’ll admit, I didn’t do a lot of this in my military career, but the idea is to take time after any activity to review how it went. Kind of sounds like a retrospective, doesn’t it?

As an agile coach, I find this is a great tool. Just the other day I observed one of my teams run a stand-up. As soon as they were done, I gave them a debrief. It only lasted a minute. I highlighted what they did well and where they could improve. I have used the same approach with other teams on everything from iteration planning to retrospectives...sounds kind of “meta” but why shouldn’t you evaluate how effective your retrospective was? This technique is based on the approach of learning a new idea, practicing it, and getting feedback to reinforce the idea.

Learn, Practice, Reinforce

One key to debriefs, and I think this is important for a good retrospective, is to start by stating the goal of the activity. At the end of the iteration, can your team members state what the iteration goal was? How else can you evaluate how you did without thinking about what you set out to do.