Post date: Feb 6, 2012 4:37:59 PM
Everyone likes a sale. I was reminded of this yesterday while grocery shopping. As I checked out, the clerk asked if I was going to get two of an item, as they were having a "Buy one; Get one free" sale on it - I hadn't noticed. I thanked him profusely as he rang up two of these items (the second free) and I ran back and got the other one.
Although I appreciate what the clerk did for me, this post is not about customer service - though it could have been, because this is a stellar example - but on the notion of the sale itself. "Two for the price of one" is a concept we can often find in our projects and these "two fer"s can drastically improve your product's quality and utility. Let's say that a customer has requested a change in code which (due to no fault of your own, of course) has not been refactored in a while. Opening up the code to add this enhancement provides a perfect opportunity to refactor the code and a good developer will do this while making the change. Similarly, combining similar user stories or required features impacting the same areas in your code often allows you to make changes more efficiently. Any story about UI changes can usually be combined with another item (or five) in your story list around the same area to make a combined story that might take less time to design and code than if you did all of them separately. The same is true in the construction of unit tests - usually, much of the infrastructure from one unit test can be reused and this is more likely to be done if tests for multiple functional items in the same area are written simultaneously.
There are also places in project management when you can use the "two fer" philosophy to gain additional efficiency. For instance, there are times when meetings must be held - a review of user stories, discussions of new designs or architecture changes, etc. By combining these meetings with others having the same attendees or similar purposes, you can minimize disruption of people's work (although beware combining unlike meetings, especially where there really are topics that half of the attendees are not involved in - more about this later). Personally, I find that grouping my one-on-one meetings with my employees minimizes the disruption to my daily routine. Preparation is simpler and I'm less likely to forget topics. The day of the week I choose for these may be booked pretty solid, but I'm not interrupting tasks on my other days the way I would if these meetings were done "onesy-twosey".
So look for opportunities to kill two birds with one stone in your projects - these chances come about more frequently than you think, and taking advantage of them can save you, your people, and your project both time and effort.