Agile abuse: how can we stop ourselves from distorting these 2 agile terms?

One of the beautiful things about agile is that at its heart, it’s a mentality and an approach, rather than a set of unflinchingly rigid rules. This means that when you practice it, you’re encouraged to modify the implementation, as long as you keep with the spirit of the manifesto. Sticking with something that plainly doesn’t work, simply because it has been proclaimed on an dusty old scroll somewhere, obviously isn’t sensible.

I know what it’s like to be looking on the outside-in, at a system like agile. I was there myself, a few years ago. It’s an established system which clearly works for a lot of teams doing software development. When you see that working, and you see how highly people value it, you obviously want to make use of it yourself.

But I’ve got two personal peeves in particular, where I think many people misinterpret and mangle the spirit of what agile is about. We’re trying to prevent this at Hanno, and we’d love to hear from others who have ideas for how to improve this even further!

Peeve #1: Sprinting doesn’t mean ‘running fast’

I wish the term ‘sprint’, which we use to describe a defined length of time during which we’ll be working on a project, didn’t also mean ‘running very fast’, when used outside the context of software development.

We had this issue when we first introduced the concept of sprints in our team and started running remote product design sprints, particularly because we wanted to sell their benefit to clients and persuade them to relinquish hourly billing, and allow us to work with them in weekly, or fortnightly blocks. We found ourselves saying things like “if we work in this way, we’ll get lots more done, and we’ll make faster progress”.

This is true, of course, and we do. But when you’re running an agile sprint, the idea is that it has to be repeatable. According to the agile manifesto:

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

The whole point is that we prevent people from burning out, by restricting scope and workload to manageable levels, so that over time, we consistently build and design better software. If your team runs two sprints, and is completely exhausted by the end of them,due to their intensity, then that’s not sustainable.

For us, it comes down to finding sustainable pace, always. If we’re using the word ‘intense’ to describe a sprint, something is almost certainly wrong.

Has anyone else found ways to try and avoid connecting “sprints” with “intensity”, particularly when working with clients and those who are less experienced with agile?

Peeve #2: A meeting is not a standup

A standup is supposed to be a quick, regularly scheduled status update for the team, where each person quickly outlines their plans and progress, and any issues they’re having. They should really only talk for two minutes or so. It’s designed to make sure everyone is on the same page and is aware of what the rest of the team is working on. And you’re supposed to do it while standing up–hence the name.

This is probably something that all scrum masters and agile coaches have to battle: sometimes, that morning standup can start to get longer and longer, until it’s taking half an hour or more. That doesn’t quite sound like a standup, to me! When you’re working remotely, and the whole team doesn’t have a standing desk, I’d speculate that this is even easier to slip into.

This is a slightly controversial topic for us–we’ve had some heated discussions within the team about this. If you’re working remotely across many timezones, and the morning standup is the point where, for one time during the workday, the whole team is online and in one place, it’s often very convenient to spend more time catching up. The temptation to turn that standup into a longer meeting to work through problems together, is very strong.

On this one, we’ve not fully figured out the solution. Should we be okay with modifying the standup to permit a longer catchup, in the spirit of “making agile work for us”? Or should we be dividing the call into two sections: the first, being a typical, quick standup. The second, continuing immediately after, being a general daily planning meeting, from which anyone is free to drop out if they feel their presence isn’t needed?

We’d love to hear from others who are battling this problem, particularly if you’re working a remote team!

Title photo by stevendepolo