They really believed working in parallel had to be more efficient, but when they actually tried collaborating, they got more done in less time than they’d ever experienced before. They realized that for complex work, collaboration does in fact work better.
In this episode, Richard and Peter answer the question: “My team members always grab things to work on separately in parallel. How can I get us collaborating more as a team?”
Resources Mentioned
The Magic of 1-Day Sprints
Team Launch Sequence (TLS)
Episode Transcription
Richard Lawrence
Welcome to the Humanizing Work mailbag, where we answer questions from the humanizing work community.
Peter Green
Today, we’re answering a question that came to us from a coaching client who said, “My team members always grab things to work on separately in parallel. How can I get us collaborating more as a team?” So in this episode, we’ll go a bit controversial and acknowledge that sometimes doing a bunch of parallel, separate work is the right approach.
Then we’ll share how to know when that’s not the right approach and some ideas for how to get out of it when that’s the case. We’ll also share a solution we’ve developed to help teams rapidly experiment with new ways of collaboration.
Richard
Before we jump into it, a reminder we want to help you with whatever challenges are most frustrating you right now.
You can send us an email at mailbag@humanizingwork.com with a few details about your challenging situation, and we’ll share our thoughts and advice right here on the humanizing work show in a future episode.
Peter
And just a quick reminder to rate and review the humanizing work show in your podcast app, or if you’re watching on YouTube, please subscribe, like, and share today’s episode if you find it valuable to you. We appreciate your help sharing the word.
Richard
If you want to get access to more content we produce, not just the show, have us send you our newsletter where we share one key idea every week. Sign up for that at humanizingwork.com/hwnews.
Peter
Okay, so let’s talk about collaboration versus parallel work. We usually assume that collaboration–actually working together on things– is always the goal for a team, but maybe you don’t always need it. Maybe your compelling purpose doesn’t require it or require it for most of the things that you do. For example, I was recently working with a marketing team, and that team was responsible for launching new products into existing channels.
They had experts on the team at copywriting, video editing, photography, localization, etc. and most of that work was very predictable. And as we talked about it, we realized that the experts probably wouldn’t get a lot of benefit from collaboration for the majority of their work. Occasionally it would help, especially in the early design stages for a new product launch.
But once they got to execution, the work was firmly in the predictable realm where those experts really should be working in parallel.
Richard
The extreme case of this that we see sometimes is a group of people who aren’t really a team in the sense of working together on a shared purpose. It’s just a group that does meetings together. Some groups of people that get called teams are really individuals doing related (thematically similar) but separate work and trying to behave like a team in that case can be painful and wasteful. You may be better off finding ways to get just enough alignment and coordination, but not trying to be a team in the kind of rich collaborative sense.
Peter
So if your team is doing work that would actually benefit from collaboration, that usually means that different perspectives are going to be valuable because new things are going to emerge as you do the work.
That’s very common on product teams, on software development teams, and that was certainly the case for the first team that I used Scrum on, which was the Adobe audition team. When we adopted Scrum, we had pretty separate roles. We were treating the work as if we didn’t really need to collaborate too much outside of our specialties. So for example, on that team we had a team that was called the engineering team, another team that was called the QA team, and they kind of did their work separately in different phases.
And when we adopted Scrum, we said, “All right, we’re supposed to be a cross-functional team now,” but the first several sprints, that didn’t work so well; we didn’t really know how to collaborate across those specialties. And we spent, I think, the first eight sprints trying different things to figure out how to collaborate more effectively. And each one of those sprints failed for a different reason or another, where most of the sprint was the engineering team doing their work, and then the last little bit was QA trying to finish everything that engineering had started. Eventually, though, after– in fact I remember it was our eighth sprint retrospective– we decided to try and break that constraint and say, “Well, what if just any time an engineer wrote any piece of code, we asked the question, ‘how might we test that code’ so that you could get involved earlier?”
It was a little change, but it led to a major breakthrough because once we asked that question, we started formatting our backlog much differently; what we now know as thin vertical slices. So we started building the structure in the backlog that way, and that allowed development and QA to be talking throughout because now as we’re figuring out what the developer should, what code they should write, the QA person is saying and yeah, and how could I test that?
And it becomes a collaborative effort and with a much faster kind of transition between the two. And I remember after several months of this, walking down the hall and seeing a developer and a tester sitting in an office together, and I kind of hit the brakes and said, “Wait, what’s going on in there?” And Eric and Charles were in there and I listened for a minute and Eric said, okay, that’s ready. Check that out. See if that works the way you expect it to. And Charles said, “Really?” He said, “Oh, actually, it should do this, not that.” And Eric said, “Okay,” did a little bit change and said, “How about that?” And they were.. within just a matter of a few minutes, had made two or three changes that in the old days would have been hard coded, tested, a bug written, gone back, and Eric would have had to remember what he did, etc. So much faster cycles of collaboration and what I would really call collaboration. They were sitting together doing the work.
Richard
So that one took several months, which felt fast compared to these multi-year projects you were doing before. I remember one team I coached in around 2010 that experienced a much faster transition from parallel to collaborative work.
They were working on pretty much everything in parallel and had the cumulative flow diagram to sort of prove it. Everything starts on day one of the sprint. Nothing or maybe a small proportion of things are done at the end of the sprint. When you look at the cycle time of any particular thing, it’s like two or three sprints and they wanted to try getting things done faster but couldn’t figure out how to do it.
They were convinced working in parallel has got to be the most efficient way to do it. We’ll just get in each other’s way if we try to work together. But it’s also really frustrating, never to finish anything in a sprint. So what do we do about it? And so I suggested we do some science. We run an experiment and we use the data we have to shape that experiment. And so they’re nodding along with us. And so I said, okay, let’s adjust our commitment in the next sprint based on how much we’re able to finish in a sprint. We’re like, Okay, that sounds smart. That should work. So we go into sprint planning and I asked, “Okay, how much have we started and finished in the same sprint ever?”
And the answer was basically zero. This team had yet to start and finish something in the same sprint. And I said, “Okay, that is our available capacity in the next sprint using our historical data for what we can complete in a sprint. We’re done planning.” They’re like, “What? What do we do? We have no sprint backlog.” I said, Well, if you finish early in a sprint, the way you normally do it is you pull another item from the top of the backlog and you work on it and get it done.
And then if you’re still done early, you pull another item. And so let’s behave like we finished early. They’re like, “Oh, this is probably going to be really inefficient,” so let’s treat it as an experiment and see what happens. We’ll, at least get something done, this sprint. And so they agreed to try it and immediately pulled something from the top of the backlog, had a conversation about how to work together to get it done as fast as possible, and wouldn’t you know it, they finished it that day and then pulled another thing and said, “how can we work together to get this thing done” and kept doing that for the entire sprint. One story at a time. And we would have this conversation over and over again like, “This shouldn’t work. This has got to be more inefficient than what we normally do, but we’re getting stuff done.”
And at the end of the sprint, they’d completed 13 items off their backlog. They had never completed one before, start to finish, in a single sprint. This team… (Peter interrupts) I hear all the kanban people saying, “Yeah, yeah, yeah,” (Richard adds) Single piece flow! Batch of one.) I think it really was less efficient. So they ended up going later to a WIP limit of two and then three and kind of experimenting with that, there was a sweet spot in between because seven of them in this pretty legacy system didn’t have tools where they really could stay out of each other’s way.
But it was still surprising working in what they would have considered the least efficient, possible way led to them still getting a lot more done. I mean, they really believed that working in parallel had to be more efficient. But then when they actually tried collaborating, they got more done in less time than they’d ever experienced before. And they realized that for complex work like they were doing, collaboration does in fact work better because they would learn something that would benefit from other people’s perspective and doing quick cycles of developing and testing and like you described with the audition team, Peter.
So they discovered we can work better when we collaborate. Now let’s figure out how to collaborate in an efficient way. And that was where they bumped up the WIP limit a little bit. And they committed based on what they actually completed in that previous sprint and started looking more like a healthy scrum team collaborating around a predictable amount of work.
Peter
We need to add that to the “Richard’s Scrum Hacks Series” Sprint planning’s over because our velocity is zero.
Richard
And to give credit where credit’s due, I’m sure I got that from somebody on the original XP team that yesterday’s weather planning and I think I remember Kent or Ron or somebody making a joke about the team that never gets anything done.
Yesterday’s weather is zero, so fastest planning session ever; and I just took it seriously and it worked.
Peter
So that team had almost overnight, a transition from never getting anything done in a sprint to the first day getting something done.
Richard
And parallel to collaborative overnight as well.
Peter
Yeah, yeah. And unfortunately, I think our experience, especially with early agile teams, but a lot of Agile teams these days, as illustrated by the audition team, is that we intentionally experimented with new ways of collaborating every few weeks and that was only if we’re doing very intentional, effective sprint retrospectives, which we were trying hard to do on our team.
So I think over the years we’ve discovered that the audition team’s experience is not unique there. Good Agile teams often start to see really major breakthrough improvements after five, six, seven, maybe eight or nine sprints if it took as long as the audition team did. And it’s almost like we had to get the easy changes out of the way first and then we could start tackling the hard stuff.
And we’ve seen with a good coach that time frame can drop to three or four sprints. But either way, it was months before our teams really experienced a breakthrough in how to collaborate. That’s pretty good compared to never having a breakthrough, which happens on far too many teams. But we started to wonder how could we accelerate it? Could we cut a few months to a few weeks or even a few days to where they’re having experiences like that team that Richard described?
Richard
Mm hmm. Yeah. And I remember the shift kind of accidentally when I went from the long cycles to the short cycles for that, back in, again, probably 2010. I was often working with teams over the course of several sprints, even several months. But then there was one team I got flown in to spend a week with to get them started, and that was going to be all the time we had together.
I realized we can’t get more time together, but we can get more iterations. So rather than getting half a normal two weeks’ sprint with them. What if we did five tiny sprints? So we ran an experiment with one-day sprints and we discovered that five one-day sprints produces almost as much improvement, especially around team collaboration as you’d get from five normal length sprints.
It turned out that team formation and team improvement weren’t a function of the amount of time spent together as a team, but rather a function of the number of cycles, the number of intentional experiments you run together. And you could make those experiments quite short and still get the outcomes you wanted.
Peter
So eventually these patterns have become clear to us– a couple of weeks of one day sprints and a few focused working sessions on topics like team purpose or working agreement, or how we’re structuring our backlog is a pretty reliable way to launch or even relaunch a team.
And we had all of those patterns in our head and we would frequently apply them with the teams we were coaching, but we don’t scale very well. So we decided to package all of what we’ve learned together into a single product that we called the Team Launch Sequence or TLS for short.
Richard
Right. And we’ve now tested TLS with dozens of teams, some that were brand new to Agile, some that had been using it for years.
And it works. Scrum Masters and team leaders can follow the facilitation guides, share the videos that we created, use the Miro boards that we provide, and they reliably get these kind of breakthrough improvements in those two weeks and particularly around this move from “It can’t possibly work for us to collaborate,” to, so often on day four or five of TLS, we hear quotes like, “Oh, this is what collaboration feels like.”
And then the team has this breakthrough.
Peter
Yeah. So we do a version of the TLS that’s fully self-guided and we also have a version where we provide some support via Slack or Teams as the team goes through it and you don’t actually need our products to do these short sprints. There’s kind of the do it yourself version. And so we’ll link to an article that we’ve had out for a few years about the magic of one day sprints and how to run them.
We’ll link to that in the show notes and you can try it with your team for a week or two.
Peter
If you are interested in the TLS, Angie, our head of marketing, has authorized us to give a TLC discount to our humanizing workshop audience, but she didn’t tell us how much of a discount. So with apologies to Angie, we’re going to go a little crazy here.
Any of our listeners, viewers go to the YouTube version and drop a comment on the YouTube version of this episode to get a discount on the self-guided team launch sequence for your team and the first person who comments on the YouTube episode, quote, “I need this for my team” We’ll give you the self-guided version for free and then the next five, we’ll give it to you for half off.
Richard
Sorry, Angie. I don’t know if that’s what she had in mind,, but I like it.
Peter
Maybe a little extreme. Yeah.
Richard
So back to the original question. If you want to help your team move from parallel work to collaborating more, the single best method we know is to actually experiment with collaboration. I don’t think you can talk people into it. You really need to actually try it, see how it feels, see how it works on your team, constrain it to one backlog item or one day at a time and just see what it’s like to work more closely on something that matters until it’s done.
Peter
Many of the teams that we try this with find that it feels clumsy or inefficient at first, but we think that’s actually a sign you might be on the right track because trying new ways of working is almost always uncomfortable. But stick with it for a bit. Give yourself a fighting chance and you might have the same kind of breakthrough that so many teams have had with this in how they collaborate.
Thanks for watching, and…
Richard
Please like and share the episode if you found it useful and keep the questions coming. We love digging into tough topics, so send them our way.
Last updated