Book Club Review: Software Teaming

Intro

At Engage, a handful of us get together once a week as a book club to read and discuss selected titles over the course of a couple months. We recently read Software Teaming by Woody Zuill and Kevin Meadows and shared our review and a few take-aways at one of our weekly Lunch & Learn sessions. Here is a transcript (lightly edited for readability) of the presentation:

Transcript

I was thinking for our discussion today it would be good to do a Book Club review of the Software Teaming book. We already talked about this a bit recently, a couple weeks ago, but I wanted to take a chance to revisit it more fully and think it makes sense to get into a habit of doing a review of what we’re looking at in Book Club more regularly and get these ideas spread out more fully.

Software Teaming is the book, A Mob Programming, Whole-Team Approach by Woody Zuill and Kevin Meadows, Foreword by Kent Beck.

The big idea is the whole software development team, including decision makers, testers, frontend, backend, database, whatever, working together. A lot of it is talking from the perspective of being co-located, working in the same room on a single computer with a couple of keyboards that get passed around.

There’s a lot in here about the mechanics of setting it up in a physical space, which is interesting to consider how to take the things that they’re working for in a physical space and think about them in a remote space, but they don’t directly correlate.

Specifically in terms of how the work gets done, they advocate for a driver/navigator model.Which generally means that the there is one person at the keyboard who is the driver and then other people are navigating and so the driver’s doing the mechanics of taking the thoughts of the navigators and putting them into the computer. But ideally that driver is not just doing their own thing, but whatever code that ends up on the computer is the result of conversation, something that someone else has said, so the details are known by kind of the whole team and at least more than one person.

That covers Part 1: Introduction & Part 2: The Details. Part 3 is A Few Other Things which is a hodgepodge but also has a lot of good nuggets in there.

So one piece was continuous learning where the team takes time together to learn and how the team that initially discovered this way of working had already been working, was having regular times where they were getting together and doing practice learning things on a weekly basis that used some of this driver/navigator model from pairing. So part of what they’re talking about here is that they had created an environment in their work where new ideas could bubble up and they could investigate those and see how they worked. So it wasn’t that someone had a bright idea and came up with “we have to work this way”, but it was organic. It made sense for one particular meeting to pull up some code and look through it together and then they said, “That was great, let’s do this tomorrow. What if we kept doing that?”

There’s a lot in here about the social and relational dynamics around creating a team that demonstrates respect for each other and creates an environment where people are willing to work together and be exposed to day-to-day mistakes that you might make and to feel comfortable working through things that aren’t fully formed in a group.

It hit on retrospectives and allowing these practices to work and get better and figuring out what people need. An idea that they took from Extreme Programming that they highlight here is called Turn Up the Good. Rather than focusing on what’s going wrong, focusing on what’s going well, and how could we get more of that? So not just putting out the fires of negativity, but what can we capitalize on that we’re doing well so that we can do more and more of it?

So the idea of pairing itself came from, “How could we turn up the good on code reviews? What if we were reviewing code all the time?” So in one form, mob programming is, “How could we turn up the good on pairing? What if it was the whole team and not just two people?” But that attitude of paying attention to what’s going well and noticing that that’s important has the potential to be powerful and transformative.

Their approach for software teaming is totally voluntary. So the folks who want to do it are gonna do it, and if you want to go off and do your own thing, you’re allowed to do that. With a hope that more people will see that this is working well and will come and experience that.

They have a section talking about concerns about the cost of having the whole team only focused on one thing and they look at that from two different perspectives, the one being “it was not our experience as we were doing this and as we’ve done this on a few different teams that that becomes a problem”. And then also more of the theoretical, what’s the reason that it’s not a problem. That’s because of a number of things that this process improves, but most distinctly the idea of the flow of features that get out the door. When everyone’s working independently, they can check off a bunch of tasks, but the process to get those individual tasks combined together and reviewed and working in a way that makes sense to release it to a customer can take a very long time.

Whereas when everyone’s together, those roadblocks of, “OK, I’m done with my part. Now we’ve got to wait for it to get on somebody else’s plate to get done with their part. Oh, we have a question. We’ve got to wait to get the question answered.” All of those delays in the process of getting that work out get smoothed out. The team all working together ends up delivering valuable results at a higher rate than people going off and doing things on their own.

They did talk about remote software teaming a little bit and there are a few different approaches to that. The all-in approach is you move the development environments to being virtual and so you have a high-spec virtual machine that everyone can remote into for their turn.

So it’s again that same idea that you have in person that we have the one machine that we’re working on and we’re all going to take turns kind of at the keyboard of that machine. Getting that set up potentially saves a lot of headaches, where every person doesn’t have to go through the routine of setting up their own environment, setting up their database connection, setting up whatever else. But you set it up once and then everybody’s got it working. Other approaches being some kind of Live Share situation where there’s one code base on somebody’s machine and other people can remote into that one machine. Or the remote handoff approach that is what we typically do, where everyone has their own environment set up and then when we’re done in one environment, we push the changes to git and then somebody else pulls it and then we can keep going.

It talks a little bit about “What actually is the team” and the overarching answer there is, if we keep needing to stop and ask you a question, you probably should just be on the team.

It talks about flow and productivity versus utilization and flow, addressing the foundational concept of how can it be more productive to work on one thing instead of multiple things at once? It juxtaposes that with team-based flow. Part of what makes the team flow work is that you have multiple people paying attention to what’s going on, so that if somebody does need to get distracted, then you still have the ability to continue forward. That distraction could be, “I’ve got a 5 minute phone call” or “I’m sick today” or “I’m on vacation for a week”. None of those are activities that stop the team. Whereas in individualized flow, “I’ve got to get in the zone and have to focus on not being interrupted for multiple hours at a time so I can let the code fly out of my fingertips.” It’s more fragile and potentially less helpful from that macro view.

It talks about Problems that have Faded Away. So again, this is “in our experience, these are things that we saw happening, not results that we went looking for, but we did this and we noticed these results that happened”.

The first is Faulty Communications. That’s when the people doing the work and the people making the decisions are there together, that there’s less time for communication to degrade. If I tell you what to do and you do it right then there’s less of a gap. If I tell you what to do and you do it right then, and I can see you do it and I can say, “oh wait, no, not that. I didn’t mean to say it like that.” Then there’s less chance for things to get out of sync. And then we’re having those conversations face-to-face. It’s not “I had to write something down that was enough written down for you to know what I really meant.”

Related to that is Issues with Decision Making. Having decision makers as part of the team means that the decisions can be made as those decisions need to be made. Decisions that should be made by those decision makers don’t end up being made by developers because it’s easier to just keep going and not wait for an answer to a decision.

Another Problem that Faded Away is Doing More Than What’s Barely Sufficient. As a team, they already had this value of “we need to do the right amount of work to solve the problem, but not do lots and lots of extra that we may or may not need in the future. We’re going to like solve the problem and move on and then figure out is there more problem to solve?” It’s working in small iterations. Because that was a value of the team, the whole team could police that better than when you’re on your own or even if you’re working as a pair it can be easier to get lost in the “maybe this is important”, but when you have more people there are more people to catch it. “That’s more than what we need. Let’s move on to something else more important.”

Sustainability Erosion is a rephrasing of what’s commonly called “technical debt”, the idea that things get harder and harder within a code base as more code gets added and they found that the property of the sustainability of a code base eroding was less prevalent when they were working in teams. Primarily that comes from the group being able to say together, “no, wait, we should clean that up. No, we should tackle that edge case”. You get both ends, “we should do enough and we shouldn’t do too much”.

The next problem is Thrashing, which is moving from task to task to task and not feeling like you’re making progress and losing focus and direction because “I’ve finished that, but now I’ve got to come back to it because of feedback that somebody else had”. Because you’re all working on the same thing together at the same time, you don’t have that, “I did my part, but now I have to come back to it” piece.

Another Problem that Faded Away was Politics. When you’ve got everybody in the room working together and seeing what’s going on there’s less room for posturing around what is and isn’t important and what we’re doing. Another part that is related to that is the part of politics that’s making myself look better. But with teaming, the whole team is responsible for what’s being delivered. So there’s less room for any individual to try to put themselves individually out there because the whole team together is delivering.

The final Problem that Faded Away is Meetings. If you have everybody in the room who is needed to make the decisions, then you don’t need to have separate meetings and so you’re meeting as the work needs to get done.

All of that said, you get to the end of the book and they’re like, “we don’t know if this is going to work in your environment. We just know these are the results that we’ve seen. It’s an experiment that you can try if you’re in an environment where you can try experiments. Also, do what you can to create an environment where you can have successful experiments.”

That is Software Teaming.