Sense of Urgency

Mike Hill tweeted a thread about giving teams a sense of urgency. The thread is long gone but here’s the related article. Please read it now.

Welcome back! Here are my thoughts:

Overall

Overall, I like Hill’s ideas on RAMPS a lot. I am already a big fan of Purpose, Autonomy, and Mastery as key motivators, as I wrote about in Nature. Hill’s additions are good as well. I’d been thinking about whether “Cadence” should be part of the New Framework that I’m not creating, and his “Rhythm” makes me think of that. Anyway, here are my comments on the topics:

Sense of Urgency

Wrong, wrong, wrong!
Also erroneous.

I would cringe visibly if a manager asked me how to instill a sense of urgency, and obviously Hill does as well. I am reminded of the phrase “assholes and elbows”, used in the military and elsewhere to mean that people had better be visibly working really hard. The manager who asks for urgency has his head … well, sorry, I was distracted by my own rhetoric for a moment … a manager who asks for urgency wants people to look busy. He wants to see action. He wants to see people scurrying around.

This manager is living in fear. He probably has no way to tell where the team is, no way to know whether the project is in trouble or not (and it probably is), and no way to know how much trouble he’s in when the truth finally comes out.

He’s living in fear, and without knowledge, he wants to demand action.

On the face of it, asking people to live with a sense of urgency is both cruel and ineffective, especially in software development. Cruel because why should people work 8 or so hours every day in a panic? Ineffective because software development is mental work and when you are feeling a sense of urgency, your mind flails around, you thrash, you make mistakes, you cut corners.

Now, of course, I believe that the Increment is a key deliverable to keep managers calm, but we can talk about that elsewhere.

In any case, a sense of urgency is not something a manager should attempt to instill, and asking for it is a strong clue that there’s something dangerously wrong going on.

Let’s note that Hill is talking about what one should provide to one’s team. He doesn’t discuss (yet) how providing RAMPS will solve the manager’s fear problem … and in fact I don’t believe it will solve the manager’s fear problem. It will, however, be much better for the team. That makes it worth doing.

RAMPS

Rhythm

Ba dum TISS

Hill describes tension and release, the coming and going of energy. I recall Ward Cunningham describing the way a system’s design evolves, becoming more complex and then being simplified. He uses an expanding-contracting gesture when he talks about it.

Agile methods like XP and Scrum have time boxes, iterations or Sprints, which provide a Cadence for the work. Kanban methods also describe Cadence. Cadence is rhythm.

Working with TDD has a rhythm, as we write a test, make it work, then refactor. A really good clue that you’re off track, when TDDing, is when the next test takes a much longer time than the others. For me, when TDD is going well, the rhythm is about one test per ten minutes or less. If something takes 20 minutes, it’s a sign that something is wrong somewhere. It could be a weak design, a lack of knowledge, too big a bite for one test – it’s not clear just what is wrong, but the broken rhythm tells me something’s up.

The week provides a natural rhythm, as does the month. The day does, as well, and inside the day we might have cycles of a half-day (time for lunch) or quarter-day (time for a break).

The Pomodoro Technique of my friend Francesco Cirillo calls for a rhythm of 25 minutes working, 5 minute break, repeated four times, with a longer break of 15 to 30 minutes.

All these notions fit Hill’s description of a building and release of tension and energy. These rhythms help keep work from becoming a grind, and that’s good. For effective “Agile”, rhythm seems to be a key component.

Autonomy

I’d rather not pick up a hundred dollar bill than follow your orders to do so.

To me, autonomy is life, and it’s life in “Agile” as well. Individuals and interactions. Self-organizing teams.

There’s an old saw about buying a dog and then barking for yourself. Why would you hire a bunch of intelligent people to build software and then tell them every step they should take every moment of the day? Why would you tell them how to build software? They surely know that better than you do.

Scrum has this notion right: the Product Owner says what is needed, and the Dev team decides how to do it.

Mastery

Please God let me be good at something.

Most of us have a desire to be really good at one or a few things. I believe that the few people who have no such desire have had it beaten out of them.

The desire to be really good at something can come, originally, from anywhere, but if it sticks with us and we stick with it, it generally comes down to having some success with it. There can be great joy in tasting a bit of success, working to get better, getting more success, rinse, repeat.

The organization wants its people to be good at what they do. What good would a “sense of urgency” be if people couldn’t do the work? Of course, pushing for a sense of urgency ensures that they can’t do the work, but our point here is that we need our people to be skilled. We need them to advance their skills all the time.

Fortunately, people enjoy mastering new skills, and becoming better in other ways. Most of the ways people can become better help the team and the organization, and since improving makes people feel better, even if they’re improving at something that’s not directly applicable to the work, that’s probably good.

Purpose

What was our point, again?

Most of us benefit from a purpose, a mission of some kind, a thing we’re trying to do, or a person we’re trying to help to accomplish something. If our work doesn’t lead somewhere appealing, we’re disinclined to focus on it. We won’t move at a good pace along the path, if there isn’t good stuff up ahead.

In a way this is the team side of Mastery. For ourselves, we’re trying to get better at what we do.¹ For the team, we need a common, well, purpose, to which we can all contribute.

Hill suggests that managers usually score 9 or 10 on purpose, but I don’t think that filters down to the team. If the official purpose is “Write this big damn product”, or “Code up all these stories”, or “Meet this huge volume of requirements”, that doesn’t constitute a purpose. A purpose is more like a problem to be solved, and it needs to be visible, and there needs to be a possibility of actually attaining the purpose.

Maybe the manager understands that big purpose, though my experience suggests otherwise. For the team to benefit from a purpose, it has to be their purpose, not just a poster on the wall. They have to understand it, adopt it, make it their own. The team must engage in shaping the purpose, not just pick it up somewhere.

That said, I fully agree that for best results, and best team happiness, they do need a shared purpose that all can get behind.

Safety

Fear is the mindkiller.

• Bene Gesserit Litany Against Fear

The notion of safety in “Agile” was first presented, or at least best presented, by Joshua Kerievsky of Industrial Logic. Despite a tendency to brand-name things that I think should not be branded, Joshua is a brilliant and successful Agilista, who has helped a lot of people. A few years back, he started talking about safety and “Anjen”, which I guess is the Japanese term. It’s a key notion.

Agile software development is about people coming together to build something. The developers must collaborate closely, and they all need to collaborate with their Product Champion or equivalent, and they need to communicate effectively with whatever management structure they find themselves in.

If people feel safe, they can contribute best. They’re less conservative, they don’t hold back. They’ll take on risk sensibly, offering the best they have, rather than acting fearfully and holding back.

For people to give their best, they must feel safe. They must be safe. You can’t fake safety.

Summing up for now

Basically I’m singing harmony here, agreeing with Hill’s framing, and adding in little riffs and frills of my own. It’s good stuff, in my opinion, and I’m glad he wrote it.²

RAMPS. Use the acronym to remember these key ideas: Rhythm, Autonomy, Mastery, Purpose, and Safety. They’re critical to your team’s success.