At the Scrum User Group South Africa meeting last night Marius de Beer did a really good talk about Software Development Practices. It’s been a long while since I saw anyone attempt to draw so much from such widely spread corners of wisdom. In one slide Marius mentioned the practice of Sustainable Pace. Many take the view that this is about cutting back on working overtime and that it supports the principles of energised work, and work-life balance. Marius did make the same point, and it is correct.
But there is another angle to Sustainable Pace. As a developer, you need to build a rhythm, or flow. It’s a cadence that you establish as you are writing code. It’s a cadence that TDD helps you establish itself. This cadence is also sustainable pace. And one thing that kills this cadence and your pace in a flash is a mid-stream meeting.
In the panel discussion afterwards, there was a question at the end regarding ways to reduce the number of meetings which I just glossed over. If you schedule meetings with developers for only the first hour in the morning, you not only reduce the number of meetings but, also, you don’t destroy the sustainable pace built up from the morning.
So, don’t think about pace as just working 7 hours a day, it’s about what you do in the 7 hours that matters. Get the rhythm going and be anal about things that can kill your flow mid-stream; especially meetings.
f3yourmind 
I like the idea – though it doesn’t work so well when the team starts the day at different times – for some the 1 hour meeting will fall well into their work day.
I try and do meetings every week on the same day. So team X knows that Wednesday from 10 to 1 they have a meeting – usually a few, and its important they attend. I also try my best to minimize meeting time. Just because the room is booked for an hour doesn’t mean we have to sit there for an hour 🙂
Hi Sam
Sure, it can get more complicated with teams starting at different times, but the key point is that developers need uninterrupted time to establish a rhythm which leads to a sustainable pace. So, I’d still try to optimise this by shifting meetings involving developers to the beginning of their day, regardless of the time they start.
I tend to agree with Aslam. What really affected my thinking on the topic of meetings was this post from Paul Graham:
http://www.paulgraham.com/makersschedule.html
In particular:
“I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning. I know this may sound oversensitive, but if you’re a maker, think of your own case. Don’t your spirits rise at the thought of having an entire day free to work, with no appointments at all?”
And then I had this other thought; so what you’re saying Aslam, that flow is good if you’re a developer, but not if you’re a business person demanding value? 😛
Hey Carlo,
Very funny. But don’t confuse the “developer flow” with the Kanban flow. Flow is not fractal in nature. Developer flow is all rhythm that you establish while coding. It’s not about cycle times, etc. It’s about a cadence that comes from TDD, mostly.
At InnerWorkings we had a fairly flexi time. People could arrive in the morning between 8:00 and 9:30 (traffic in Dublin can be bad) As a consequence, we established daily standup meetings at 9:35 sharp. 15 minutes or less, of course. That established a true cadence and cut down a lot of waste (people can go on a tangent for too long otherwise).Sometimes, those meetings would lead to quick “let’s discuss it offline” with quick brainstorming with the people involved. No extra ceremony, no “agendas”, emphasis on delivering value rather than activities.