Firstly, apologies for the long delay in posting anything, my current client has a project in trouble, and I’m doing what I can to help them keep it moving. I wanted to share some thoughts on what it takes for a business to be successful with agile adoption, in particular, what you have to be willing to do as a company in order to achieve the kinds of success that people brag about when they talk about agile development. This is likely the first of several posts on the topic, and we’re going to talk about estimating and measuring progress on an agile project.The two edged sword of a minimal, customizable process is it’s sometimes hard to know what you should customize, and what should be left alone because if you touch it, you’re going to break something. I’ve seen a number of businesses now decide to adopt parts of agile, while keeping parts of waterfall processes, and the mess it can create. I’m not at all convinced that when companies decide to try agile techniques, or to adopt them wholesale that they understand that agility isn’t strictly speaking just about software: it affects the entire ecosystem around the project. What’s that mean?
Most agile frameworks use empirical methods of measuring progress. In the case of Scrum, for instance, there’s a project’s velocity and the size of the backlog that help you understand how fast you’re going, and consequently when you’ll be done.
Many organizations don’t adopt this method of measurement, preferring instead to keep the Microsoft Project plan around, based on the original project baseline, and continue to try to measure percent complete for tasks. What’s wrong with this approach? Well, mostly it just doesn’t work.
Software development is an incredibly complicated process: the goals, and even the tools available to achieve those goals change on an almost daily basis (and that’s no exaggeration). The best estimates we’ve been able to create are based on doing something similar, which is how the empirical estimating process works: we create a backlog, have the team work on the project for a bit (a few sprints), and measure their progress. From there, we can extrapolate likely further progress by their velocity. If you change the composition of the team, you change the velocity, and you need to re-baseline your velocity in order to update your estimates.
If you continue to use a project plan grounded in the idea (I almost said “reality”) of estimated hours, you’re not accounting for the variability in experience of the team members. Is that 8 hours for Bob who’s been working in this area for 15 years, or for Annie who’s just been hired?
You can try to adjust for all of these things with ideas like load factors on resources and available hours, but really isn’t it easier, and probably more accurate, to simply measure the team as a whole, using the velocity as a gauge?
Many organizations continue to insist however that they have to have a project plan, based in a Gantt chart. They’re unwilling to give up on the failed idea of managing development projects the way they always have: by creating estimates and measuring percent done, even though they will admit that it doesn’t work very well.
If you’re going to adopt agile, you should be prepared to change the way that your company measures progress of development projects, otherwise you’re throwing away the ability to more accurately measure progress on your projects.
No comments yet.