Teams

Stable Teams Should be Non-Negotiable

How can delivery vary so much in time and quality?

How can delivery vary so much in time and quality?

A few years ago, we had a house built in rural Maryland. Working through a builder, we designed the layout of our home and painlessly moved into our newly constructed home about 6 months later. After we took full ownership of the house, there were minimal construction issues (a few nail pops). Fast-forward a year. A family went through the same builder and purchased land next to ours. It took about 9 months for the builder to complete the house and for them to move it. After they moved into their house, they had major construction issues (plumbing, electrical, HVAC). We were surprised and delighted by the builder and our overall experience. Our new neighbors were not. Considering our houses had the same builder, we wanted to understand why their house took an additional 3 months to complete and had so many quality issues. After comparing notes, we had our answer.

The root cause? The builder foreman left the company after our house was completed and there was nearly a 100% turnover of the main construction team and the sub-contractors (electricians, plumbers, HVAC, cabinet makers…). All of the optimizations the team had accumulated from building homes together were gone. Instead of taking the usual 6 months to build the house, they had to train new people (which slowed the original team members down) and mistakes were made along the way (requiring rework).

STABLE TEAM DEFINED

A stable team is a team that stays together (no adds or drops) over a period of time, ideally for at least 3 months. The construction team for our neighbors’ house had drops and adds throughout the 9-month construction, most importantly the building foreman. We had none.

Stable Teams have a few characteristics:

  1. Individuals on the team only belong to one team.

  2. The team has one backlog or queue of work.

  3. The team has limited dependencies on other teams.

  4. The team stays together (unchanged) for at least 3 months.

CONTEXT

Stable teams can be applied to any organization and at any level, from delivery teams to program teams, to portfolio teams. If they meet the 4 criteria listed above, they are a stable team.

RESULTS

Plenty of surveys and studies have been done noting how stable teams are “better” than non-stable teams.

Particularly, I’m going to reference a 2014 research study by Larry Maccherone. With over 50,000 respondents, let’s note a few key points that it concluded:

  1. Teams that stay together are more productive.

  2. Teams that stay together are more predictable.

  3. Teams that stay together are more responsive.

3-things-stable-teams.png

If we modify teams regularly or staff teams with people who are merely temporary members, we will never allow ourselves the opportunity of high performance. If we consider Tuckman’s stages of group development (forming, storming, norming, and performing), we will continuously be forming and storming. We’ll never have the opportunity to norm and perform at the same level as a stable team.

STABLE TEAMS SHOULD BE NON-NEGOTIABLE

Having unstable teams hurts productivity, which makes sense. If we shift people around (think re-orgs), we have to train the new team members in the norms of the existing teams. While we are ramping up new teams or team members, we’re also not getting work done. The changes, though well-intended, will have negative impacts in the short-term.

When trying to improve an organization, some start with a practices-first approach, installing Scrum, SAFe, Kanban, or some other framework. But whatever your framework, stable teams should be non-negotiable, if you want a predictable system. Have a backlog of work, build and maintain a team, and then deliver value. As noted in the Maccherone research, stable teams resulted in throughput improvements (as much as 60%), increased predictability (variability of throughput effect improved as much as 40%) and quicker responsiveness (time in process improved as much as 60%).

Good organizational design should include stable teams. Leadership should be incentivized to keep teams together and incrementally improve them. Remember, if you make too many organizational changes too often, it will be at the expense of customers and the business.

My Perspective on Remote Work

remote workThe proclamation by Marissa Mayer last month, informing Yahoo employees that working from home is no longer an option, really seemed to bring an important conversation front and center. The memo that started this firestorm stated in part -

"To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices... We need to be one Yahoo! and that starts with physically being together."

I've worn a lot of hats over the years.  In each instance, there has been a common goal:  Be as successful as possible.  Being "successful" is unique to every situation so that's why I include "as possible".  But when you add happiness to the equation, what does that mean?

If you are in a job where you are rapidly iterating a product and continuously collaborating with others on your team, being face-to-face or side-by-side with your teammates will provide an opportunity to be as successful as possible.  Being collocated is no guarantee for success but being distributed (dislocated) is going to certainly limit your chances.  Leaders should focus actions more on making their companies, projects, or products successful and less on trying to make employees or teammates happy.

Now, don't get me wrong.  I'm not saying we shouldn't be empathetic to the needs of others.  I'm just saying there comes a point when you need to look at the costs and the benefits of remote work.  If the team is not realizing its potential, because one or more of them are working remotely (because they want to and not because they have to) we have a misalignment of goals.  Why would they sacrifice potential success for their personal comfort?  Well, businesses are trying to find ways to incentivize their employees. They hope that by incentivizing then, they will be happier and more productive.  But see, that is part of the problem. There is a belief that the incentives will make them happy.  Happiness is one of the byproducts of satisfying work, which can be derived from feelings of mastery, autonomy, and purpose (link to talk by Dan Pink).  I believe (in some cases) the work-from-home incentives will have a negative affect.

When companies hire us, they are NOT hiring us to make people's lives better.  They are hiring us because there is value locked up in these companies and they are unable to produce.  They are hiring us to help them unlock that value.  Period.

What's one of the first things I would propose if I coached teams at Yahoo? Bring the team together, face-to-face or side-by-side.  The only thing I disagree with in the Yahoo memo experpt  is where it states "…we are all present in our offices…"  I propose they get out of the private offices and into a team space.

Balanced piece about the pros and cons of working at home on Fast Company

Image Credit: Pictofigo

Favorite Project Management Quotes

Favorite QuotesThere isn't a week that goes by that I don't hear some awesome quote or analogy.  I put as many as I can into my mental back pocket, hoping for an opportunity to pull one out at a moments notice.  When you're stuck for a quote or analogy, to help someone understand what you're trying to say, do you ever ask yourself what's that awesome quote that I just heard the other day? Here are 10 that I keep handy.  Are there any quotes you would like to share?  Please add them to the comments section.


  • Because the needs of the one... outweigh the needs of the many. - Star Trek III: The Search for Spock, Captain Kirk.  I like to use this quote when explaining the contrast between egoism, utilitarianism, and altruism (servant-leadership).
  • The more they overthink the plumbing, the easier it is to stop up the drain. - Star Trek III: The Search for Spock, Scotty. I'm admittedly a Star Trek geek.  I've used this once when trying to articulate Lean thinking.  I also segway into the untrue but compelling story of the Million Dollar Space Pen.
  • The thing is, Bob, it's not that I'm lazy, it's that I just don't care. - Office Space, Peter Gibbons.  I like to use Office Space quotes, particularly when referring to empowered teams and while drinking from my Initech coffee cup.  Mmm'kay? Greeeeat.
  • Luck is not a factor. Hope is not a strategy. Fear is not an option. - James Cameron.  This quote was on the back of the LeadingAgile t-shirts we all wore at Agile 2012.  I still have strangers walk up to me and ask about its origin.
  • That which does not kill us makes us stronger. - Friedrich Nietzsche.  I think of this quote during almost every run I take.  After taking an inventory as to my physical condition, I have a mental debate as to stopping or keep pushing forward. I keep pushing forward.
  • We keep moving forward, opening new doors, and doing new things, because we're curious and curiosity keeps leading us down new paths.- Walt Disney.  I've told my son over and over again to challenge the status quo (I don't call it the status quo because he's seven) and when given the choice, try new things.
  • When we go into that new project, we believe in it all the way.  We have confidence in our ability to do it right. - Walt Disney  The power of positive thinking and an empowered team.
  • Plans are of little importance, but planning is essential – Winston Churchill.  Another almost identical quote came from Dwight D. Eisenhower: Plans are worthless, but planning is everything When I talk about the Agile Manifesto and how we should be responding to change over following a plan, this becomes one of my most commonly used quotes.
  • Stable Velocity. Sustainable Pace - Mike Cottmeyer.  This quote appears on the back of the LeadingAgile running shirt. It has become the unofficial motto of my life, as it applies to work, family, and running
  • We don’t need an accurate document, we need a shared understanding - Jeff Patton. I was attending Jeff's session at Agile 2012, when I heard him say this.  It really resonated with me.  I don't know if the quote was scripted or impromptu.  Regardless, when I recently quoted him at a Project Managment Symposium in Washington DC, I saw over 400 project managers nodding their heads.

This post was originally published on LeadingAgile

Social Norms at Work

I recently gave a talk in Michigan on the topic of servant-leadership.  Unfortunately, servant-leadership is something that is painfully absent in so many organizations.  Just a few years ago, it (servant-leadership) was not something I had even heard of.  Going back and reviewing the PMBOK made me realize two glaring omissions.  There is a lack of content on stakeholder or team engagement and there is a lack of content on leadership.  Fortunately, in the last few years, I have enjoyed books by authors like Clay Shirky, Seth Godin, Dan Pink, and Dan Ariely.  I've also met and interacted with some amazing people in the Agile community.  I now interact differently with my peers, as a result of these experiences.  I now apply my social norms at work.  What are social norms?  They are patterns of behavior in a particular group, community, or culture, accepted as normal and to which an individual is accepted to conform. We all go to work and we all get paid to do it.  Too many times, we take things for granted.  We don't question the things we do or the things that happen to us.  I'm pretty sure this is based on conditioning over a long period of time.  Perhaps we need to start treating those we work with more like those we socialize with.  Next time you interact with a fellow employee, ask yourself if your behavior is socially acceptable.

Social Norms

Within an organization, where we are working with other people, things can get twisted.  Some exhibit bad behavior and believe it's somehow forgivable because we're all getting paid.  Well, I don't think that's acceptable.  It's very interesting to see the same people behave differently, when not in the office environment.  Why is it some people forget basic manners or common courtesy, when in an office environment?

Case in point, I hold the door open for people, regardless if I know them or not.  I see this as socially expected behavior.  Socially, I expect a thank you.  To say I expect it is a slight embellishment.  Outside of the office, I still expect a thank you.  Unfortunately, at the office, I've started to accept not getting any reciprocation.  There are a few people in my building that I don't personally know but I still hold the door for them.  They won't make eye contact with me and they won't say thank you.  When the situation is reversed, these same people do not hold the door for anyone.  But, I refuse to accept their behavior.

We all need to strive to understand and empathize with others. People need to be accepted and recognized for their special and unique qualities.  Assume the good intentions of your coworkers and don't reject them as people, even while refusing to accept their behavior or performance.

Drawing:  Pictofigo

HT: Business Dictionary

Manipulate or Communicate

I'm always looking for ways to communicate with team members, vendors, and customers.  When trying to understand the range of communications, I recently reassessed what I thought the opposite of communications was.  I no longer believe it is silence. Rather, I believe it is manipulation.

2 Examples:

[1] Buying a Vehicle

You go into an auto dealership. You want to purchase a new vehicle.  You want to pay the lowest price as possible and the dealer wants to make the highest profit possible.  Rather than coming to the table and negotiate based on this mutual understanding, both sides try to remain as silent as possible.  Both sides are trying to manipulate the other, in order maximize the outcome in their favor.

[2] Getting a New Job

You apply for a position with a new company.  You are interviewed and the company believes you are a good fit.  As soon as salary is discussed, the manipulation traditionally begins.  Both sides are trying to manipulate the other, in order maximize the outcome to their respective favor.

How it should be

In the case of the auto dealer, they should be honest about their cost of the vehicle.  They should explain how the dealership and sales person will be paid.  They should ask the buyer what their needs and wants are.  Is it cost or is it the make/model (scope)?  The key here is everyone needs to be honest! I'm not a pessimistic person, but with a (sales) relationship like this, I feel there will always be manipulation involved.

When negotiating salary with a new company, the relationship is different.  Hopefully, both parties want a long term relationship built on honesty.  I propose the applicant tell the potential employer exactly what they are currently being compensated, including benefits and bonuses.  The applicant should explain their motivation for seeking new employment.  Were they being paid too little; Were their benefits too expensive; Was their work/life balance all out of sorts?  Was the previous job just unfulfilling?  The new company should take this into account before making an offer.  They should explain the range of compensation to be offered.  Both sides need to be frank and honest. I recognize this is one of the most uncomfortable conversations you ever have.  That's why I believe both sides should be honest and over-communicate.

How it applies to a project or program

In the previous two examples, both involved negotiations and communications.  From my perspective, these can all be win-win scenarios if we are honest and over-communicate.  Over the weekend, I participated in a live web interview with Peter Saddington from AgileScout.  I stressed the need for over-communications on projects and gave 3 examples on how to do it.  You can over-communicate by using information radiators, daily stand-up meetings, or by having an open-door policy (with rules) with other meetings.

Information Radiators

Use burn-up, burn-down, kanban, or task boards in both executive work areas and team work areas.  I would recommend displaying enterprise (program) level information where all of the executives can see it.  I would recommend displaying team (project) level information where all the teams can see it.

Short Feedback Loops

Have daily stand-up meetings for each of your teams.  Have daily "scrum-of-scrum" or "team-of-team"  meetings to roll information up to an enterprise level.  There is no excuse for anyone to NOT know what is going on every day.

Open Meeting Policy

For all of your meetings, have some simple rules.  Understand that some people are allowed to talk and some are only allowed to listen.  But, all should be informed.  Now, I recognize not everyone should attend a Retrospective meeting or Executive Board meeting.  But, everyone should know what the outcomes are.

Let's face it, the enterprise wants to get as much productivity out of its employees as it can, in order to reach its tactical and strategic goals.  In order to do that, you need empowered teams who trust each other.  You need free-flowing communications.  I'll say it one more time. Be honest and over-communicate.