White PapersMore >>
Like it or not, software developers often find themselves working for managers who insist that they write and submit a regular, weekly status report. While agilists have discovered that short, daily stand-up meetings are a far more effective way of communicating status than written reports, many traditional managers still insist on documentation. These reports take valuable timetime that could be better spent developing working software. Unfortunately, that paper isn't going to push itself. One of the maxims of agile software development is to maximize the amount of work not done, so as to automate drudgery whenever possible. Writing status reports is clearly drudgework, and they can often be extracted automatically from various electronic sources, matching the formatting requirements.
I'm proud to officially announce the Eclipse Status Report Automation project, codenamed "Blocker." The name comes from the blocking strategy presented in my July 2003 column entitled "Running Interference." This strategy is applied when you cannot convince management that your team shouldn't be investing time writing needless documentation or following inappropriate procedures. The solution is to assign someone the role of producing unnecessary documentation and attending endless bureaucratic meetings, freeing up the rest of the team to do real work. In short, you lose one team member, the Blocker, instead of the entire team. Now we're taking it one step further and automating status reporting. The Blocker project has been accepted by the Eclipse Project team and is currently in the validation phase of the Eclipse development process (www.eclipse.org/ projects/dev_process/), in which working code is developed.
"The Blocker Architecture" (this page) is an overview of our strategy for building Blocker, which will be written in Java as an Eclipse plug-in. There are two main components to Blocker: the status report generator and the configuration file editor. The status report generator takes information from your time reporting, project/portfolio management, version-control software (VCS), software configuration management (SCM) and defect tracking systems, and combines it with information in your configuration files to generate the status reports. The configuration file editor enables you to manage both the project-specific and developer-specific XML files that provide the information required for generating distinct status reports.
Status, Status Everywhere
Let's start with the project configuration file. There is one XML file per project, indicating the fundamental information describing it. This includes the name of the project, a brief overview paragraph, business keywords describing the project and an indication of the main technologies used to implement the system. There is a reference to a configuration file for the project manager so that Blocker knows who to send the status reports to. This file also contains connectivity information for accessing the other tools, such as your version-control system, from which Blocker gathers status information. In a future version, we intend to support optional references to other project configuration files, one for each subproject, to support program management status reporting.
There is a configuration file for each individual on the project for which a status report is either created or sent. This file indicates the name, position, e-mail address and phone number for the person. It also notes whether a status report should be generated for them and, if so, includes a reference to the appropriate manager to send it to. Most importantly, each individual can define his or her own catch phrases such as "Sounds like a plan" or "No rest for the wicked." These terms are occasionally inserted into status reports based on defined criteria to support the illusion that the reports are being manually written.
Configuration files for managers who receive only status reports can be maintained by someone on the project team, thus improving the odds that the manager doesn't discover developers aren't wasting their time writing status reports. This configuration file also indicates which status report template to use, and how often to generate and submit the status reports. Although the default is weekly, it is also possible to send status reports monthly, bi-weekly, or even daily if you really want to make it look like your team is getting a lot of work done.
[click for larger image]
The Blocker Architecture
Blocker takes information from various systems and configuration files to automatically generate status reports for management.
To generate a status report, basic scheduling information is extracted from your project and/or portfolio-management software. Blocker needs to know which tasks are associated with each individual so that progress against those tasks can be assessed and reported on. One benefit of this approach is that the generated status reports are consistent with the current version of the plan. An interesting side effect is that it motivates the project manager to keep the plan up-to-date, a time-consuming task keeping him out of the way of your development team. For the first release of Blocker, our priority is integration with Microsoft Project. Support for other tools will come in future releases.
Blocker must be tightly integrated with your VCS or SCM system to obtain the most recent versions of critical files, such as configuration files and project plans. Blocker will also scan the system for the latest changes to project artifacts, transmogrifying the change descriptions into management speak for inclusion in the status reports. For example, a change description such as "Aligned widgets on the page" would be translated to "Follow- ing existing user-interface guidelines, I aligned widgets on the page to improve the usability of the system and thereby helped to improve overall end-user productivity." To access these systems, Blocker supports both the WebDAV and Delta-V APIs for non-Microsoft VCS and SCM tools and Microsoft's IVSS API for Visual Source Safe.
Blocker also integrates with your defect-tracking system to obtain descriptions of any new or changed defect reports. You can configure Blocker to report only good news, such as fixing five defects this reporting period, and to give bad news a positive spin. For example, why report "117 priority one defects were discovered yesterday," when you could say, "Comprehensive acceptance testing continues to proceed successfully"? Because there isn't a standard API for defect tracking, we'll use existing APIs to products such as ClearQuest, Perforce, Bugzilla and DevTrack wherever possible.
Blocker will obtain the actual figures an individual has input against various project tasks from your time-management system (TMS). With this data, Blocker will determine if an individual is on time, behind or ahead of schedule and will report positively on your status. And because new tasks that haven't appeared on the project schedule occasionally sidetrack people, Blocker will correctly indicate to the project manager that he needs to update the schedule. The Blocker team has developed a standard TMS API and is currently looking for volunteers to wrap access to existing TMSs that conforms to this API.
Templates for the status reports will be stored in either MS Word or XML. These templates will enable Blocker users to tailor the reporting format to their organization's exact needs while supporting consistency between teams. Consistent reports enable management to interact with project teams in the exact same manner, thereby supporting management's holy grail of enforcing a repeatable process on software developers.
What People Are Saying
Surprisingly, many members of the Project Management Institute (PMI; www.pmi.org) are enthusiastic supporters of this effort. One such person, who wishes to remain anonymous because he doesn't want to dirty his hands by being closely involved with actual software development, recently told me: "Status reporting is by far the most important part of software development because it's the primary way that professional managers find out what's going on. With Blocker, we'll finally get the actual status reported, not works of fiction that invariably imply that the team is late or over budget. We want to hear the good news, not the trivial technical details."
Microsoft is also taking a hard look at Blocker, and from what insiders have told me, they are seriously considering developing a similar feature for the 2007 version of Microsoft Team Studio. My hope is that the Eclipse Blocker will not only prove to be popular, it will also help to improve overall developer productivity. If you're interested in getting involved, or just in using the product, please visit our project page at www.eclipse.org/april fools/blocker. I'd like to thank Brad Appleton and Steve Cohen for their input in helping me track down the applicable API standards for accessing the various tools.
Please Note ...
Blocker is not a real Eclipse project. This column is an April Fool's joke, so please don't contact the Eclipse team unless you intend to start this project yourself. -SWA
Scott W. Ambler is a Canada-based software process improvement (SPI) consultant, mentor and trainer with AmbySoft Inc. He has authored several books and is a regular speaker at software conferences worldwide.