Practical Process Improvement (Part 1)

So, its been a while since I regularly posted but starting every week or two weeks I’ll be posting a bit on the topic of Process Improvement. Not from a  high on the pulpit position but from the “how do I figure out what my problem is and, and more importantly, how do I solve it.” This will be a practical series of steps covering everything from handling bugs to managing change and will incorporate the why as well as the what. Any and all comments are appreciated – especially if you think I got something wrong. This part lays the groundwork for practical process improvement. At this point you’ve made one of two decisions – you are going to implement process for the first time (your current process is referred to as chaos) or you are going to improve your existing process. Process for process improvements sake is a poor reason to change or implement a process. So, what are you trying to improve (a.k.a. where are you now)? Before you know where you want to go you have to have some type of baseline to measure your progress against. Implementing a process is all about small, measured steps – try to do everything at once and you are guaranteed to fail. You want to work in small iterations in order to improve your process – even if you are working on a formal (or waterfall) based project. Why small iterations? Did I just tell you to change to an agile development process? Well, no, not exactly. Short iterations allow for rapid feedback and the ability to measure and introduce change quickly and at well defined points. This does not mean you have to start using XP or Crystal or Scrum or any of a dozen other agile methodologies. And these methodologies don’t work particularly well in every situation – especially if you are working on a much more structured project such as a life-critical system. The goal here is not so much to measure velocity (although that in itself is highly useful), unless that’s an area you want to improve on which I’ll talk about in a much later part of the series, as to be able to introduce a change and gauge its effectiveness. The other thing that is critical is metrics. If you’re making changes because you think you need to make a change (aka “the gut feeling reason”) then you aren’t going to be able to prove whether the change helped you or not except annecdotally. While we as developers don’t mind this, management really does. They don’t want to plow money into process changes without knowing the benefit they are getting for their dime. So let’s give them what they want and also help ourselves in the process. Don’t make any changes without having a baseline – ever. In addition, when you are doing a retrospective on whether the change worked or not, do it by comparing metrics (as well as gut feeling) to determine the effectiveness. Next, pick and choose what you want to change (aka get the low hanging fruit first). Choose items that are more simple to change and are easier to measure. In light of this, I’m going to start off this series with simple areas (or at least, in what our experiences with customers have taught us are simple areas) and move to more difficult areas later on. In preparation for the next part of this series, the first area I’m going to walk you through improving is the bug handling process. This doesn’t cover how to reduce the number of bugs you get initially (well, it does in part but that isn’t the focus) but how you handle the bugs in your process. As I mentioned before, you need baseline metrics to determine the effectiveness of the changes. To begin with, spend the next week or two and measure how long it takes from when you receive the bug (the date and time – to the hour) to when the bug fix is released into production. In the next part I’ll talk about how to reduce that time frame (obviously this fix will only be important if you feel that it takes a large period of time to implement the fix and that your customers are unhappy) and what you should be doing at each stage.