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.