Scrum Burndown using Trac

In a recent draft of "The Scrum Papers" I document the use of the GNATS bug tracking system at my company PatientKeeper for managing a complex Scrum implementation. In my Scrum Tuning course I use a complexity number which equals (number of teams) x (number of releases per year) x (number of products) x (number of kits or separate release branches to support vendor platforms). PatientKeeper has a complexity number of 3240 which is higher than any other Scrum company I have seen except for a British Telecom project of over 1000 people.

Supporting this level of complexity at PatientKeeper requires an "All-At-Once-Scrum" using a completely automated system. I'm deprecating the term Type C Scrum used in my Agile 2005 paper as Scrum Trainers feel it confuses people. There is only one Scrum and a few would even claim a Scrum that multithreads Sprints through multiple teams is not really Scrum at all. Let me just note that Mary and Tom Poppendieck have documented the All-At-Once-Scrum in their recent book on implementing lean software development as one of the highest performing Agile implementations on the planet, Ken Schwaber has remarked that it is a "competitive monster," and at least five companies have discussed with me their implementation of this ugly duckling. One of them even published a paper on their implementation at the Hawaii International Conference on Software Systems in January, 2007. This Scrum implementation requires complete and total participation of senior management and a MetaScrum led by a Chief Product Owner that drives product strategy for the company, not to mention live deployment at the end of every Sprint. But I digress ...

Very few companies using Scrum are platform companies. These companies tend to use layered architecture teams, as the APIs on various software layers are products used by dozens of technology partners and therefore are features that must be supported even more carefully than a typical user-oriented feature in a web application. The ones I have worked with are Google, Palm, and PatientKeeper. Amazon is using Scrum to address similar platform features. To properly support the complexity of these implementations advanced tooling is required. One of the advantages of the tooling needed is that it supports scalable, distributed, and outsourced teams as a trivial, yet important, side effect.

The tooling implemented at PatientKeeper had a key requirement laid down by the development team in the early days of the company. It had to take less than 60 seconds a day for a developer to use and less than 10 minutes a day for the ScrumMaster to provide updated burndown report to the company and any other report a manager might request on demand.

The solution was to add five data items to an open source bug tracking system along with minor enhancements to the user interface and the ability to do nightly dumps of data for import into Excel spreadsheets. While I have regularly recommended upgrading the PatientKeeper GNATS system to a newer open source solution, it has become as mission critical to PatientKeeper as an online accounting system to a bank. If it goes down the company goes down. Therefore, the development team has refused to even think about upgrading it.

Some of the many features I would like in a new system are a better user interface and an automated connection to a version control system. Trac was of interest because it is a wiki-based bug tracking system that can be extended to support an "All-At-Once-Scrum" and has a direct binding to Subversion. Since the Subversion code configuration management system is an easy upgrade from CVS, I recommend that to PatientKeeper also. However, the nature of our complex management of code branches to support an All-At-Once-Scrum is even more mission critical than the real-time Scrum reporting system. "Alas," engineering says, "don't even think about it!"

I trust the day will come when PatientKeeper will decide to upgrade. They will need to do it like the big banks I used to work with running dual online systems in parallel for several weeks to ensure that everything works flawlessly before cutting over. For those of you who have not already gone completely paperless, cardless, and noteless there are more options.

Note: In 2008 PatientKeeper upgraded to Jira and Subversion.

Early versions of Trac would not easily support Scrum. However, the latest version of Trac has more flexibility and a London-based company developed an open source Scrum plugin, the first of several requirements for the tool I need.

See Daan's Blog for latest updates on the Trac Scrum plugin.

Agilo is also a nice Scrum plugin for Trac.