Thread by @GeePawHill

Sooooooo. I'm gonna write a little bit about geekery. But I do want to frame it for you a little.

Geekery is not very important right now.

My country is in the throes of facing down a violent uprising by uniformed militia, spurred on by parts of the government.

So, geekery, no. Not important.

But, to me, and to many of my followers, thinking and talking about geekery is a kind of comfort food.

Comfort doesn't eliminate problems. But the idea behind "respite" is real: people in pain need comfort, in addition to the actions that help get them out of pain.

Lest there be any doubt, I want to be very clear:

I stand with my family, peacefully, in the streets, who are being viciously suppressed by an unprincipled and violent minority. I support them and I encourage them and I am proud of them.

#BlackLivesMatter

I'm not looking away, and this isn't business as usual. It's just a small dose of attempted comfort. It's not the only thing I'm doing, or the best thing, it's just a small thing.

Stay safe and stay strong.

Okay, now what? I went to all the trouble to spell that out, and now I gotta figure out what to write about. What have we been talking about lately?

Hmmm.

Let's do something easy today.

Pull & Swarm is a technique for approaching the workload in front of a small team. It amounts to pulling one story from our queue at a time, and throwing all of our resources and humans at the same story at the same time.

P&S can be useful to Scrum-based teams, but also to any small team using any method. Some teams I have worked with have done *pure* P&S. No planning as a group at all, no ceremonies, just make a queue with a half-dozen things in it, pull one, finish it, on to the next.

But even within a Scrum framework, P&S is valuable: in that context it's more about how we work between sprint planning and sprint review.

Before we even dip further into this, P&S is not some kind of automated psuedo-algorithm ruleset. Such rulesets do not work. Each story we tackle using P&S requires individual judgment and active energetic collaboration.

The main benefits it provides in practice: 1) better knowledge distribution, 2) higher completion rates, 3) improved energy & motivation.

(We'll consider some arguments against, too, tho I find most of these are arguments against some other behavior, not P&S itself.)

One cautionary note: this is not about whether we solo or pair or mob. Teams that mob all the time are doing P&S, for sure, but you can do it even if we're all soloing. What you *can't* do is do it without heavy intermittent iterative incremental collaboration.

P&S relies on direct conversation between collaborators about what's going on. It is very difficult to do if we don't have that.

For teams who don't have that base, I'd suggest starting w/limited mobbing & pairing, stepping towards P&S as you get better at what Mom called "use your words, honey." Side effect: getting better at that will help a team in nearly *every* respect. :)

First, better knowledge transfer. By far the most effective way for a person to learn is by doing, and especially, doing with others. (This is why pairing & mobbing -- once learned as techniques, they're not some natural skill everyone possesses -- is so effective.)

The programs we work on are large, larger than what any one of us can hold in her head at one time. We have specialists, and we *want* specialists, but to be genuinely effective, we want them to have a broad familiarity with how their specialty interacts with the larger program.

By putting us all in the same mental space, working on the same problem, at the same time, we greatly increase our mutual comprehension, and I want to super-emphasize this part: even when we are working on different parts in different ways.

Second, higher completion rates. I have worked with dozens of Scrum teams, and the most consistent problem we encounter, time and again, is just this: we get 100% of our stories 80% done, instead of what everyone in the team would much prefer, 80% of our stories 100% done.

There are multiple factors involved in this problem. One of them is that the plans in the room aren't usually drawn up by the people who are least skilled, but by those who are most. Another is that horizontally-dependent tasks are assigned to individuals. P&S mitigates both.

By getting all of us working the story at once, we greatly decrease hand-offs. P&S style does a lot of what Cockburn called walking skeleton, and it focuses our technique around evolutionary development.

And again, all of us working the story at once means that most-skilled and least-skilled are able to interactively adjust the plan as the development proceeds.

Third, improved energy and morale. I've argued elsewhere that a great deal of our math around efficiency ignores the impact of "winning". P&S gives small teams more frequent wins -- as teams -- than traditional one-story-per-person approaches.

Think of it this way: every completed story is a win for everyone who worked it. Under P&S, that's everyone on the team. Under one-story-per-geek, that's one person. The energy created in this way is tremendous.

An oddity, too: Though shared wins in small teams generate more juice than solo wins, shared *losses* don't reduce juice nearly as much as solo losses do.

Let's talk about the most common objections to this idea. They also come in threes. 1) Collaboration is hard, and structuring non-collaboration is easy. 2) Nine women can't have a baby in one week. 3) How will we evaluate individual performance?

1) Collaboration *is* hard, and structuring non-collaboration *is* easy. Sadly, structuring non-collaboration -- introducing sync points and wait-states and artifacts -- is not nearly as efficient as collaboration, so it doesn't really matter that it's easier.

2) Nine women can't have a baby in one month (sorry for prior word-o). Yes. We're not making babies, we're doing work.

This is, btw, a lousy metaphor, kinda like "fight fire with fire". It shows up so often because it's one of the few real-world cases of the point it's trying to make, just like fighting fire with fire.

In point of fact, nine-person teams *regularly* do open-heart surgery, and believe me, they do it an infinite number of times better than one-person teams do.

The actual point Brooks was making is not that *no* work can be done in a team, and not that *all* work can be done in a team. Some work can be done in a team, and a team that learns how to find and do that work dramatically outperforms soloists.

(Oops. Got a crisis here -- nothing fatal -- I'll be back to finish this in a little bit.)

3) How do we evaluate individual performance? Let that go, for two reasons. Not only does individual story-counting not actually evaluate individual performance very well, but it also impacts team performance, which is why you wanted it in the first place.

Individuals impact team performance in a variety of ways. P&S actually *heightens* individual performance by supporting different people using their different ways to do different things on one story at a time.

Some people are best at raw coding. Some are best at plumbing. Some are best at databases. Some are best at *morale*, best at *focus*, best at *interpretation*. We want all of them, and we routinely need a great many of them to implement a story efficiently.

Pull & Swarm proposes that our whole team work one story at a time, bringing it to completion before we move on to the next. I have found it to be remarkably effective. It does require strong collaboration, but if we can get to that, we'll leave one-story-per-person in the dust.

No pitch today. As I say, it's just not business as usual. I hope reading and talking and thinking about geekery gave you a little respite.

#BlackLivesMatter

Stay safe and stay strong out there.