How can you tell when a programmer is stuck?

There’s a famous quote, “The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.”

As Homer might say, It’s funny because it’s true.

But how can you tell when a programmer is stuck on a problem?

One way is to pay attention to their behavior, and if anything is out of the ordinary for a day or two, then you know something’s up.

Another way is to scope all work such that they should be implementable in a day, and this certainly has the side effect of it being easy to tell when a programmer is stuck, it also has the unwanted side effect of putting more overhead into planning — not something anyone wants.

This is one of the areas where daily standups — properly used — can help. Weekly “status” meetings don’t invite the sort of conversation you need to uncover problems people are encountering, and normal daily standups reward papering over problems if you’re not in a high trust environment (if you are in a high trust environment people will likely tell you when they’re stuck — so before all else, think about how you can increase trust).

During a standup, most programmers aren’t going to say, “I’m stuck on X”, and it’s not because they’re afraid of getting in ‘trouble’, it’s because they don’t want to lose face in front of their peers. However, they will give hints that they’re having issues, and you can take that as an indication to follow up with them alone, away from their peers.

So how do you ask a programmer non-confrontationally if they’re stuck?

Try these:

“Hey, it looks like <that thing you’re working on> is a bit more involved than we initially thought; who do you think would be best able to help you make forward progress on this?”

“I can tell that you seem frustrated by what you’re working on. I get that. Hard problems have a way of being frustrating and draining. How can I help, or who can I enlist to help you get un-frustrated by this?”

Use your own terms of art; but there are three things you want to communicate when dealing with programmers:

1. Programming — even things we’ve done hundreds of times before — is hard. A minor update to a library can steal days worth of effort.
2. Because it’s hard, programmers aren’t to blame when things slow down. It’s either a combination of understanding, alignment of skill to the problem domain, or general difficulty of the problem domain. If you ask direct questions, “How do we unblock you?” You’re inadvertently challenging the competency of the programmer, even if you don’t mean to (a literal programmer might say, “I’m not blocked”, even though they’ve spent a week on something they thought would take a day, and a programmer that has an ego might think their peers would think less of them if they answered truthfully).
3. You’re there to quietly help them move forward. No fuss, no muss, no loud hullabaloo about their progress. You’re there to get them unstuck, without them feeling embarrassed by it.

Should the code be owned by the team?

One of the tenets of agile is a sense of “Collective Code Ownership”, that is, that everyone on the team owns the code.

The “traditional” model is for people to specialize in different areas of the code and to rely on those people for their respective parts of the code. The way this manifests itself is that at most 1 or 2 people understand the harder parts of the code and everyone else are “generalists”. OK across the code base but not well versed in any particular area.

Fred Brooks, in The Mythical Man Month, spoke of a surgical team, where one person acted as the “surgeon” (doing the work) and everyone else supported the surgeon with whatever they needed.

Large and complex systems will invariably have people specialized in sections of that system, and those people will necessarily be harder to replace should they win the lottery.

agile methodologies (like Scrum and XP) try to solve this through collective code ownership.

Projects often rely on ‘fast’ work (when have you been part of a software project that was released on time, budget, and original scope?) and that has a natural tension against collective code ownership.

Developers work faster in areas of the code they understand, and specialization helps that. Developers also hate to be pigeon-holed.

So what do we do? Push code ownership for the sake of delivery? Or Push collective ownership for the sake of the bus factor?

Why Not Both?

Encourage developers to learn and specialize, and also encourage them to trade off and teach each other about what they know. This can take the form of documentation, brown-bag sessions, or a post standup teardown of a problem they’re having.

Bottlenecks and Constraints

How do you get your team to move faster?

I don’t know. Truly. I know what’s worked for some teams and some contexts, and what has failed in others, and I know there aren’t any silver bullets.

I spend my time working with enterprise software teams and helping discover what works for them.

We want methodologies to be the answer, but they’re not. Software is a human discovery and creation process; and it needs context to work. Methodologies lack context.

That’s why I focus on helping teams automate their hand-offs, and automate the mundane. Those parts can be streamlined without requiring a culture shift. And for many teams, speeding those things up results in a considerable boost in productivity. If you’re truly ready to have everyone outside of the team developing the software butt-out of the decisions, then you’re ready to adopt an agile mindset.

All software teams have bottlenecks and constraints. All software teams handle those constraints and bottlenecks differently. Agile teams try to reduce the bottlenecks by allowing only the team delivering the software to make the decisions.

For the rest of us, the teams that haven’t fully embraced an agile mindset, we still operate in this murky middle ground, and that murky middle ground is where the productivity gains lie. What bottlenecks and constraints does your team have? What processes add to those constraints? Do you have a way to automate those?

Make the seams invisible

Lots of ink has been spilled as to why small startups deliver value faster than large companies, and I won’t rehash it all here. I’ve been a part of small startups, large enterprises, and everything in between (different sized product companies, services companies, and hybrids), and the companies that have moved the fastest had two things in common:

1. A shared vision that everyone understood (We exist to help X do Y)
2. There were either no seams, or the seams were invisible

In a cross-functional agile team, you would have no seams — everyone acts as one and delivers together; but in an enterprise where you have matrix’d reporting structures or traditional reporting structures, you would have visible seams. The UX designer reports to the UX lead, the Automated QA person reports to the QA lead, etc. Those QA testers may even be working for several teams that all have demands on their time.

You can remove the seam (go entirely cross-functional and keep a team on one project or product without splitting their time), or you can work to make it invisible through automating JIRA.

What would this invisible seam look like? (the pun was unavoidable, I didn’t see it coming) It may look like automated hand-offs between groups based on their workload and their availability. It may look like a warning when you assign an item to a person that they won’t have availability to work on it. It may look like JIRA suggesting a person to hand it off to based on their past work. It may be an automated email that let’s people know who have worked on that area before that your code is ready to review.

There’s a lot you can automate in JIRA to hide the fact that handoffs take place. Automating JIRA to hide the seams enables two major wins: 1) JIRA truly is a value-add to your organizational efforts, 2) your software fits your process which enables your team to focus on what matters: delivering value effectively.