Too much time since my last post... too much to do during the last weeks. Between other we started consulting services in Adobe Flex and we created a Flex user group in Florianópolis.At the same time, the offshore project we are working on is continuing with pretty good results. This interesting experience of agile offshore is bringing thoughts that are worth sharing here.
The Context
A Belgian start-up outsourced to us the development of part of its product. The component we are developing for the moment can be considered a mid-size project, around 36 man/month work. And we have the happiness to use an agile process, Scrum - which contributes without doubt to our good results.
After 6 two-weeks sprints, we are reaching the second half of the project.
Velocity Measurement and Causes
Following the Scrum practices, we evaluate the velocity of the team in points. I will not repeat here the theory about velocity, i will rather share some purely empirical observations.
Here is an history of the first 6 sprints:
1,2) For the first two sprints, during what would be the elaboration phase in RUP (technical and architectural investigations), the velocity has been pretty low: nothing has been delivered during the first sprint, 7 points for the second. Normal with a new team on a new project with a new technology in a new environment.
3) Then we had an iteration for which the work have been underestimated and in addition a great pressure of the client to speed up the development. The team strived to reach the sprint objectives and achieved a pretty high velocity (42). But at the expense of less testing, hence creating of a technical debt.
4) During the fourth sprint we faced tough environment problems, with a far lower velocity (23).
5,6) Heavy re-orientation of part of the team has occured during the last 2 sprints. One member has been dedicated to specifications redaction (documentation demanded by the client). One other to the resolution of the environment issues. Two developers have worked on a technical POC. And one senior developer had to be assigned part-time to an other project.
We should recognize that after 3 months development the velocity isn't accurately measured yet due to a complete instability in the work to be done and in the team structure.
The Question
This scenario is pretty common in software development. Actually this volatility is one of the main reasons behind the emergency of agile (if everything could be planned up-front, agile wouldn't have any reason to exist).
On the other hand, it is this exact volatility that impeaches an accurate use of the velocity.
In other words: the main reason for agile is also an obstacle to the principal agile metric.
Hence the question: is velocity really agile ?
Thanks to share your thoughts, comments and advices on this...
(Note I do not mean that velocity is fundamentally flawed. Even imperfect, i think velocity is worth measuring. But we shouldn't give this measure more value that it really has)
See also:
An explanatory page about velocity by Version One
jan blog, "Velocity (not so) simple value"
The Puf Principle, "Scrum: utilization vs. velocity"
Posts
