I hear this a lot, “Do you use Agile?” “Yes, we use Scrum”
I believe most Development shops don’t truly understand what it means to be Agile and Scrum doesn’t accomplish what many of them think it does. I believe that a lot of teams start off using Agile with the best intentions but slowly revert back to traditional non-agile methodologies. This usually happens when things goes wrong during the Software Development Lifecycle and when the Development Teams are forced to be reactive instead of proactive.
Many Software Development Teams work within the constraints of a non-software companies that do not understand how to develop software. Scrum is typically viewed as a fad or as a way to put off doing work. Scrum should be seen as a Project Management solution for running software development projects. Scrum includes using a product backlog, defining iterations, and using stand ups. You can even use it to better understand the roles that exist beyond titles within a team. Scrum is strictly how to define what work is going to be done and when it will be worked on. Scrum does not provide guidance on how to actually do the work.
What inevitably happens while using scrum is that non-technical stakeholders put too much focus on the burndown chart. They seem to get tunnel vision on this one metric. The tasks created and estimated for a User Story are the development teams best guess at what it will take to complete the work. I have noticed that although the development team has every intention to focus on the work defined in their scrum, they usually have to perform some work that was neither defined nor captured.
This additional work is also a metric that should be captured. It is directly related to defects in requirements, defects in code, and defects in design. By capturing these additional metrics a Team can better understand or explain the impact on the burndown chart.
To summarize my thoughts, Scrum is merely a means to manage a software development project. If you’re going to focus on metrics, include more than just the hours that are completed and the hours remaining. Using additional metrics is needed to view the project status as a whole. I believe if you include additional metrics you’ll gain valuable insight into your Software Development Process. Also, just because you say you’re Agile doesn’t make you Agile.