Self-disciplined Agile Monitoring

Note for readers: I wrote this post over a year ago (even more), but for some reason I forgot to post it, so here it is.

Introduction

Now days, we are improving our development process laying-out our organization strategies, development process and methodologies. 

Our experiences point to a mixed approach, with the self-organization from Scrum and self-discipline from eXtreme Programming (XP). But about this kind of “mixed martial arts” for software development approach I will talk in forthcoming blog post. 

As you can read in one of my previous blog post, we use Team Foundation Server (TFS) as issue tracker and thanks to Scrum for Team System v3 (STSv3) process template, we have an “excellent” implemented guidance to execute Scrum “as is”.

But the existing day by day sprint monitoring’s tools around this process template hides the real behavior of the team in the iteration. 

On the other hand, we also have some needs about monitoring. Indeed against the theoretical practice of monitor the whole team we have to track individuals.

Some projects leads (me included) want to track theirs developers work against the importance of monitor the whole team behavior. Sam Guckenheimer (with Juan J. Perez), in his book “Software Engineering with Microsoft Visual Studio Team System”, aims us to use descriptive metrics rather than prescriptive. But here such measurement method “doesn’t work”, we need more control and also need a single view. 

Tracking the daily work in STSv3

Scrum for Team System (v3) is a great process template. Its major advantage of this implementation for TFS is about the usage of the server side event notification API. This allows updating all of computable fields for instance: start and end time for sprints (summarized from team start and end sprint dates), remaining hours for sprints and team sprints, and so on.

Scrum for Team System also comes with a lot of reports, but about daily work sprint monitoring comes with only one (maybe two).  This report is known as Sprint Burn Down. 

The burn down metric

The Sprint Burn Down is good metric but it’s incomplete. Such single line indeed hides the real behavior of iteration. 

Please, try to answer these questions:

• How can you notice if some tasks where moved out of the current sprint?
• How can you notice if some user stories where moved out of the current sprint?
• How can you notice if some tasks where added to the current sprint?
• How can you notice if some user stories where added to the current sprint?

The fact is that as this chart doesn’t display the planned work so it hides these behaviors. 

Notice:

1. If you see an ideal chart, an straight down line from an amount of hours as remaining work (at some point of the sprint) to zero (at the end of the sprint), doesn’t mean that everything is fine. May some tasks were moved of the sprint.
2. If you see a horizontal line doesn’t mean that everything is wrong. May some tasks were added at the same time that others were actually done. 

The burn down metric

The fact is that you are not able to answer this question: What had really happened here?

Complementary tools to track the daily work

One of my favorites tools to track iterations, and also share the iteration status with the whole team is ScrumSprintMonitor. Yes, the multi-process template screen saver. 

The effect of the usage of this tool in the team’s focus is incredible and of course, more over the “guys in red” ;-).

Demo screenshot of ScrumSprintMonitor from codeplex and ScrumSprintMonitor in action but in planning mode in a lab

I like the Scrum Sprint Monitor and have been using it for years, even when I had no longer available the TV in the picture above. But again, the main metric is the Burn Down.

This tool includes a lot of info so I get inspired and wrote my own, just like I thought that it should be written ;-).

Self disciplined agile monitoring

Well, the thing actually started some years ago when I found this chart in the book “The Art of Agile Programming” from James Shore and Shane Warden. Its name is Burn Up. 

Basically consist of a couple of lines. One to show the total of planned work and the second to display the progress.

The burn up metric

In the context of a project to help my own organization to get the right way in terms of software development practices, I bought some time in order to port this metric into this monitoring application.

My own ScrumSprintMonitor in action with the burn up metric

As I said before it was inspired in Scrum Sprint Monitor but it was re-written from scratch to focus in the Burn Up metric. The current version it’s only compatible with STSv3.

Conclusion

1. Now we have a very cool monitoring application with a very meaningful metric. The Burn Up. 
2. In order to distribute as fast as possible this tool and its updates across my organization, I also implemented a draft of NuGet based automatic update system. After done, someone told me about something called Shimmer. I have to review it ;-).
3. I almost forget. This application is powered by Catel and Prism in combination (a.k.a. Catel.Extensions.Prism). 

Happy sprinting and monitoring ;-)