One of the standard issues with going to swarming or mob programming is always "How will we spot the bad programmers then? How will we catch the people who are loafing? How will we spot underskilled people if they don't do individual work?"
I went as far as to add it to my slide deck when I am teaching whole-team structures. It is going to come up anyway, and people are usually glad it's already in the topics list.
Of course, the first thing I say is "I don't know. I've not seen it yet. Swarms seem to keep everyone involved and interested pretty much all the time." This is true. It's hard for people to believe.
This suggests that either it doesn't happen, or they're REALLY good at hiding in groups. ;-)
The other thing I ask is how they managed to hire bad programmers who don't want to work.
Were they this bad when they were hired?
How long have you had them on staff without catching them so far?
And, of course, how are you sure that there ARE any bad programmers? Considering your rigorous hiring guidelines and the accelerated schedules you've had, why do you think that you must have loafers, slackers, and losers in your teams? Maybe everyone is pretty good?
I often am told that it's human nature, that anyone given the chance to get paid for doing nothing will happily do so. But this isn't what I've observed: developers WANT to develop. They WANT to solve problems. They WANT to ship code.
Self-motivation is common.
but...
... the other things I've seen is that people can be tired and demotivated if they've been pushed hard to do work that is beneath their ability ("don't design, don't test, don't learn, just hack") for a long time.
They don't loaf though; they rest.
They might back off a bit.
After having a moment to recover, though, I tend to find them eager to get into meaty, complex, interesting work and often are surprisingly driven.
You probably don't have any bad people working for you.
They may be frustrated or exhausted and they may need a break. That's okay, work is hard sometimes.
I wouldn't insist on calling them "bad" or "spent."
Here, again, I suspect we might want to suspend judgment and exercise curiosity.
What if you don't have any bad people?
What would you do instead of rooting them out and firing them?
• • •
Missing some Tweet in this thread? You can try to
force a refresh
What does software development look like from the outside?
I request N things. A few of them come out months later.
Hence: these programmers need to work faster.
1/
however, each of the N things really only took about 4 days to complete on average. Working 2x as fast (a dubious prospect) would carve off only 2 days from delivery time.
2/
What you don't see is that the work was delayed, prioritized, queued up behind dozens or hundreds of other bits of work, rejected and reworked, queued up some more, approved, and then batched up with a bunch of other work while it waited for a few more things to finish.
3/
Test first - red.
Oh, I don't like the way that message reads.
Ah, better.
Code - not green?
Quick, most obvious solution.
Still not green.
Oh, why didn't that work?
Was it the test or the new code?
AH! It's the new code. Okay...
Green.
Refactor: I don't like how I structured that test.
Still Green.
The code has some funny names in it. Rename.
Still Green.
Oh, crud, there's a library function for that.
Revise.
Still Green.
Okay.
A: Why do you use a ticket tracker?
B: We have thousands of backlog entries.
A: wait... what? Why? How does that help?
B: If we don't store them, we may forget.
A: if you have a list of thousands, you'll remember them all?
B: No, but if we review it we can see that we stored them and might pull them into the sprint.
A: How often do you do that?
B: We don't, there's always too much new work.
A: Okay, so you store them in case you ever run out of new work to do and need to pull something old and forgotten into the sprint.
B: Well, yes, and so we can tell people it's in the backlog.
Sometimes you cannot plan. This is either because of the prevailing circumstances (chaos, complexity, extreme complication, dependency) or because you just don't know how.
In those cases, you set an intention and take advantage of opportunities.
At the end of the road, looking back, an excellent opportunist or an exquisite planner will not only have the same results, but their paths are indistinguishable.
Everyone thinks people reach their goals through exquisite planning and flawless execution, but (truth be told) it was largely intention & exploited opportunity.
“How long does a 2-point story usually take?”
“We peg story points to half-days so 2 points is one day.”
“Yes, how long does a 2-point story usually take?”
“One day.”
“Historically, or ideally?”
“One day.”
“Most of the features you released are over 40 days old.”
“But, um….”
“So 40 days is more than one day, right?”
“Yeah, but the coding part only takes one day.”
“Are you sure. Did you check the actuals on that?”
“No, but they are estimated for one day, so it’s got to be pretty close.”
“But is it?”
“Now that you mention it, no.”
“So how do you know?”
“Well, we always fail our sprints by coming in short. We need the developers to work faster.”
“Work faster so that the estimates become true?”