I find SCRUM’s “sprint” a very intriguing name for an iteration. In the heart of agile development there is continuous delivery of a working software. To do that we time-box software development into iterations / sprints.
They have their rhythm and require different kind of discipline from our team. We become sprinters who continuously plan, test, implement, evolve architectures, deliver, improve the process, celebrate to finally be back in the starting blocks to launch another sprint. We do that iteration by iteration.
Can sprinter be a long distance runner?
A very common technique in agile projects is tracking team’s average velocity. It’s said that it should stabilize after few initial iterations on some level. This is also called finding a sustainable pace for a team, which in short means that our team members commit to just enough work to become productive without burning out to early at the same time.
I’m not going to convince you here why a sustainable pace is a good thing and why a tired developer is not going to be efficient and creative. It’s the opposite that always intrigues me in the name “sprint”.
When we sprint, we put all our energy to run a short distance (a single iteration) the best we can. However we plan our efforts differently when we are about to run a marathon of 20 iterations. So how long are we able to sprint and keep our average velocity constant?
Is there a point at which the team will start to loose it’s velocity? Well the answer might be that that’s where the sustainable pace comes to mind. We do not overcommit and we in fact stop sprinting at the maximum available velocity that we can achieve to sustain the pace.
Sustainable pace or sustainable undercommitment?
So how do we distinguish sustainable pace from sustainable undercommitment? Where is that point that we know we should not commit to more work as a team without being accused of just not being willing to do more while hiding behind a very nice term of “sustainable pace”?
My answer to that is great people, trust and transparency – all being the key parts of agile development. What is yours? How do you keep it at the level everybody accepts?