Attributes of a Good Team Room

As we look at new office space, I had to think about what we would want in new team rooms. Here is what I came up with, with the help of my team…

  • Four walls (ideally with at least one being glass or lots of windows)
    • high enough to provide a sound barrier
    • lots of white-board space
    • wall of offices or conference rooms is OK as long as the doors can be closed
  • At least 5 feet of desk space per person
  • Ability to run HDMI to a large, shared monitor (probably on a rolling stand)
  • 8 – 10 people per room (ideally with removable wall to combine two rooms)
  • Private space nearby
  • Manager’s office nearby

Lunch with Uncle Bob

unclebob

Ever since I stumbled across the original C++ Report articles that have become known as the SOLID principles, I have been a disciple of Robert Martin (aka Uncle Bob). He is a leader within the agile and software craftsmanship movements. He has as good a sense of what makes good software as anyone currently writing and teaching. If he thinks it’s worth writing, then it’s worth reading.

I’m not usually a fan of video for learning. I like the random access referenceability of books and I like the on-the-go accessibility of audio recordings. I find video to be the worst of both worlds: I cannot flip to the a particular page or go at my own pace, nor can I consume it while driving or mowing the lawn. Further, there are so many good conference videos available for free that I find it difficult to justify paying for video content.

clean_codeHowever, when Uncle Bob began releasing the Clean Code video series, I thought I’d at least check them out. I found them to be so good, that I’m now having my development team watch them together over lunch hours. Uncle Bob does a great job teaching (and preaching) the techniques that lead to clean, maintainable software. As we watch the sessions together, we are creating a common baseline of understanding that we can all refer to as we work together.

I highly recommend them for any software development team that is looking to get better (and if your team is not working to get better, it is on it’s way to obsolescence).  If you have trouble justifying the cost ($12 per viewer per video) to management, have them take a look at this excellent explanation of the value of software craftsmanship and professionalism.

Split the Team or Split the Backlog?

Small software companies often find themselves trying to do too much with too little. This was certainly the case at Agentek. At one point earlier this year, we had a problem… We were not finished with the current release (call it release A), but we could not wait until it was finished to get a start on our next release (call it release B). There was too much unknown involved in release B. We had to get started on it. At the same time, we had just committed to ourselves that we would not leave our customers with anymore half-finished releases. What to do?

Our team had four fully dedicated developers, a tester, and me. We needed to dedicate 25% of our time to release B. The first option was to simply intersperse the backlog with stories from release A and release B…

Interspersed Backlog

Interspersed Backlog

There were two problems with the interspersed backlog. First, release A has a good bit of reactive work; so, the backlog is unpredictable and tends to consume the entire team’s attention. Second, since stories vary in actual effort to complete, we cannot really gauge or control what percentage of our capacity is applied to each effort.

The next idea, was to split the team and apply 25% of the people to release B….

Split the Team

Split the Team

This is the mathematically cleanest solution and the option that traditional software managers would probably pick every time. However, this option has major disadvantages…

  1. Only one developer will know anything about how release B was implemented.
  2. The many advantages of pairing are lost on both efforts because we have only one developer on release B and an odd number on release A.

This option really just throws the team-based approach to building software out the window; so, not an option for us.

Next thought was to create two separate backlogs….

Split the Backlog

Split the Backlog

This makes the problem we are trying to solve clearer, but we still have the problem of how do we stay united as a team, yet timebox each backlog.

The next step was to designate days of the week for servicing each backlog. To give the forward-looking release one fourth of our capacity, we dedicated one pair to that backlog for half of the week. To simplify things, and give it a little more than 25%, went ahead and gave it three full days instead of two and a half. So this is what things looked like…

Split the Backlog and the Week

Split the Backlog and the Week

We rotated the release B pair so that there would always be one person that worked on that last week for continuity and one new person.

In our first retrospective after we finished release A (and moved onto release B fulltime), the team was convinced of a few things:

  1. One team working on two releases at once is hard.
  2. Keeping the team together was really important.
  3. Splitting the backlogs and the week turned out to be a great way to do both at the same time.

Misconceptions about Team Rooms and Open Floor Plans

I see this far too often. Well-meaning software organizations embracing agile software development tear down the walls in order to open up the space and allow easier collaboration. This sounds great, and it’s cheap. An easy win, right? Not if it’s done without some care and thought.

Premise 1: Irrelevant conversations are distractions.

Human beings are trained to pick other human beings’ voices out of the background noise and pay attention to them. There is little that is more distracting to concentration than hearing a conversation that has nothing to do with what you are working on.

Premise 2: A team is a group of people working toward a common goal.

If a team is really acting as a team, there is nothing that one subset of the team could be working on that is irrelevant to the rest of the team.

Imagine Team Green working in an open team room, paired at stations with one monitor and dual mice and keyboards…

Team Room

Let’s say that pair number 1 is having a conversation…

Team Room One Conversation

That conversation is heard by all other members of the team. Because Team Green is a team, the fact that the whole team can hear it is a good thing. I cannot count how many times I have seen this…

Pair #1 overhears pair #2 getting stuck on some problem that sounds familiar. Pair #1 stops and gets involved in what pair #2 is doing. The four people discuss the problem and solve it, based largely on some previous experience that someone on pair #1 had. If one pair had not overheard the other pair struggling, they might have wasted a whole day (or at least until the next stand-up).

Now imagine Team Green is really busy and all working and talking…

Team Room Communication Saturation

I first heard this situations referred to as communication saturation by Jeff Sutherland, but I think he got it from Jim Coplien. Here we have everyone able to hear every other conversation. If a stranger were to come upon this team area, it would sound like noise. But to a high-performing agile software team, it is completely natural because every conversation is related to furthering the goal for this iteration.

Now imagine we have a collaborative, high-performing Team Blue…

Team Room Blue 

Team Blue is enjoying the same open space benefit that Team Green is. Now imagine we take our open-spaces-are-good momentum and co-locate Team Green and Team Blue…

Noise

Now we have green conversations in the blue team area and green conversations in the blue area. This is not good. We now have noise distracting both teams.

If the blue conversations are as useful to the green team as green conversations, then you are not doing team based development.

There are two possible remedies: create more space between the teams, put up acoustically meaningful walls, or both.

Team Room Noise Fix Walls

The bottom line: open spaces and shared conversations are good only within a team, not between teams.

Teamwork Is an Individual Skill

I was intrigued by this interview with Christopher Avery about responsibility on agile teams at InfoQ. Intrigued enough to go download and read his book entitled Teamwork Is an Individual Skill: Getting Your Work Done When Sharing Responsibility.

The premise of the book is that, contrary to conventional wisdom, not only is there an “I” in team, but teams are constituted by nothing more than a bunch of “I”s. If none of those individuals takes responsibility for the team’s success, then no one is taking responsibility.

Whether it be the development team at work, the elder council at my church, or even my family, it seems there is virtually no area of life where my personal success is not dependent on the success of a team. Learning to take more responsibility for the success of those teams seemed like a good idea.

I found that the book could have used a good editor to tighten up some of the writing, and the formatting (at least on the Kindle version) was confusing at times; however, there was enough food for thought in there to make it worth the read.

Here are a few highlights to give you some flavor of the book…

Avery coins the term TeamWisdom, which he defines as follows.

TeamWisdom refers to all the individual mental skills and behaviors that lead to highly responsible and productive relationships at work. The idea is based on my definition of “team”: A team is a group of individuals responding successfully to the opportunity presented by shared responsibility. Thus someone with TeamWisdom takes responsibility for ensuring that the group rises to the occasion, and in the process, makes sure his own work gets done and done well.

Avery makes an important distinction between accountability and responsibility

…accountability can be assigned, but responsibility can only be taken.

Accountability and responsibility are not mutually exclusive. In fact, they are extremely complimentary. It is time for each of us in the workplace to take responsibility for relationships as well as accountability for deliverables, and to engage in the conversations that build productive relationships at work.

Avery makes the astute observation that if each team member acts in his own self-interest, then it is important to learn what motivates the other team members and assure that their interests are aligned with those of the team and with your interests. If your interests cannot be aligned, then you should withdraw from that team.

Once you understand your team members interests, it is in your interest to see that your teammates reach their goals.

The great philosopher/inventor, Buckminster Fuller, taught that the best way for one person to win is not by making others lose, but by making others win too. He taught from the 1940’s until his death that the more people a person helps to win, the more people that person can expect will help her win. Fuller’s teaching was in the forefront of a growing body of literature about the power and humanity of “servant leadership.” Being a servant leader means helping one’s followers become successful, instead of expecting followers to serve one’s personal success.

He then gives the following challenge in the Personal Challenge section that is included in with each TeamWisdom principle.

Do your partners and teammates provide you with access to their thoughts because they experience you as a person who helps them achieve their goals? Listen carefully to your associates to learn what is truly important to them. Check in with yourself to determine your level of commitment to them. If this level of commitment is low, ask yourself why. If it is high, ask yourself how you are willing to help. Then offer that help.

Avery talks about collaboration and includes valuable insights like this:

Most people find it much easier to grant a favor than to ask for one. However, people with TeamWisdom know that asking for a favor actually grants the other person a favor. Asking for a favor communicates to the other person that they are important to us, that we depend on them, and that we are even willing to owe them one. People with TeamWisdom understand that the person who asks for the first favor sets the tone for the collaboration.

Here is an example of Avery’s insight on the effect unmotivated team members:

Is the team leader the most powerful member of your team? Is the most inspired member the most powerful? The smartest member? Nope. None of the above. Like it or not, the most powerful member of your team is the one who cares the least about your team’s task. Sorry, but that’s the truth. The least-committed member of your team is the most powerful because his lack of commitment establishes a low baseline to which other
team members may fall. The success—or mediocrity—of your team likely will be determined by him.

Read the book. Take responsibility for the success of your teams, whether you are the leader or simply a contributor.

First Who… Then What

One of the first things I’ve been occupied with on the new job is interview candidates for software development openings we have. In recent years, I’ve been drawn more and more to get involved in the hiring process. I believe there is no more critical, leveraged action you can take toward making a software company successful than finding and hiring the right people. Having the right people is more important than programming language, platform, or methodology. The best people will overcome poor technology choices. The wrong people will eventually fail no matter what technological advantages they have.

In Good to Great, Jim Collins lays out a principle he calls “First who… then what.”

Executives who ignited transformations from good to great did not first figure out where to drive the bus and then get people to take it there. No, they first got the right people on the bus (and the wrong people off the bus) and then figured out where to drive it. They said, in essence, “Look, I don’t really know where we should take this bus. But I know this much: If we get the right people on the bus, the right people in the right seats, and the wrong people off the bus, then we’ll figure out how to take it someplace great.”

To a large extent, I think it is the same way with software. Assemble a great team, then decide what to create. In the world of commercial software, it rarely works quite that way. There is almost always a product in mind before the team is assembled. So, it’s not feasible to get the right team, then decide what to build, but it is realistic to get the right team in place, then decide how to build it. The how is always what separates good software from bad anyway.

As I’ve been immersed back into the hiring mindset, I continue to be struck by how many people who make their living developing software are so weakly grounded in the fundamentals. More on that later…