Spare the rod; spoil the child. It's an old statement that conveys the notion of accountability in raising a well-mannered kid. The concept of accountability is just as true for the software development process. Making the process and activities transparent to senior management means we can do more than just present work progression. We can also filter problem areas up the chain as well to help improve the lifecycle. In this article, we'll look at ways that encourage process improvement through the use of regular reporting.
It's no surprise that people consistently perform better when they are being scrutinized. We all strive to be professional but everyone has moments where focus wanes a tad. Likewise, in our lifecycles we have points where the attention is lacking and responsibilities blur a bit. Deliverables don't flow as smoothly as they should. In Configuration Management, we rarely have the power to make the changes necessary in other functional areas to improve time to market, quality, and efficiency so we need to get that information to the people who can. Here are some data points to present.
There are many ways to identify duration of incoming items. We may have a tool that keeps history through the lifecycle or it may be as simple as the folder or file creation dates on a network drive. It could even be some form of log. From that we can compare (in a limited way) one release against another. There are many reasons why something would sit parked, like items waiting for a code merge from an outside vendor or in conflict with code currently in a testing environment. While very simple, that information can still be very relevant. A long lag in processing for an oversized release may be no cause for concern but if the release is only a couple of stored procedures, there may be other issues that need to be addressed. Similarly, if the wait on that vendor is consistently long, then either we need to thump the vendor or, as an organization, we can manage code better to get more into a release before the merge.
And if you can identify the motion through the cycle, you can also start extracting secondary data. Changes in processes and tools can be reflected in the duration times. Or we can show that despite a decrease in work load, there is no decrease in hours billed for a given activity. If there is no accompanying increase in quality, then perhaps it reflects the excessive turnover of employees, so retention may become a glaring issue. It may reflect that QA is being asked to do too much with the resources on hand and they need to add and retain staff.
When passing activity metrics up the chain, we have the opportunity to point out areas of concern. In the reporting, though, be sure you are aggregating the data in a way that means something to senior management. If they only see Activity 1 = 100, it won't mean anything. Show them how that's changed over time or in relation to the other activities. If Activity 7 is up by 64% but nothing else is, it should be a flag to understand why there is such a hiccup in the cycle. And you might not do this kind of reporting every period. The reporting that reflects trending may only be done quarterly or even annually but it's a great way to raise issues without being belligerent. And few senior managers want to be caught with several quarter's worth of visible problem they didn't do anything about.
If we can accurately keep track of the activities being accomplished by our group or others, we can then push more effectively for better tools. When we can show that 80% of a given activity is manual but can be automated for a bit of