Creating and Retiring Process Debt at #bpmCamp 2010 @ Stanford
first go-round on Process Debt got quite a few reads and private emails and comments that motivated me to keep thinking about his topic and how to further clarify process debt so that we can use this concept to help manage our process development efforts. It also motivated me to run a small session at bpmCamp on Creating and Retiring Process Debt. We had a good discussion during the presentation and lots of examples from recent history to draw on in this room. A couple of folks from the same company were in the room and as a result they tell me that they now have a common, useful vocabulary for describing trade-off process decisions which are made *all* the time in BPM groups. Presentation embedded here, but also some rough notes below for those who prefer reading text…The
(Incidentally, I used a tool called “Prezi” for this which I find pretty useful for organizing thoughts about a topic that requires a lot of context or gets past a certain number of slides… Something about the spatial relationship of the elements helps maintain context in the discussion.) First, let’s agree that there is such a thing as Technical Debt, as defined by smarter folks than I. But also, that we can repackage it just a bit to more closely align with Process terminology and concerns. Why we incur Technical Debt (borrowing heavily from McConnell):
- Time to market – we want to get our process built quickly so that we can start to reap the ROI quickly – and time is money. If a process can save you $1M per month, each month of additional development effectively costs you $1M. Time to market matters.
- Preservation of budget (for startups, preservation of capital)- We have a limited budget, and we want to make sure we spend it on the things that give us the most leverage for getting ROI. These are likely the same things that will help justify budget for additional improvements going forward.
- Delaying development expense. As a system nears end of life, it takes a very high degree of return to justify anything but expedient fixes -because when a system is retired, its technical debt no longer matters and isn’t paid within that system – it is being paid by whatever is replacing it.
- Unintentional Debt – debt incurred due to poor technical choices, but not with forethought.
- Intentional Debt – debt incurred for strategic reasons, with explicit trade-offs.
- Short-term debt: sacrifices made to get a specific release out by a certain date.
- Long-term debt: typically architectural decisions (assuming only one database platform, for example) that can be good trade-offs measured in years.
- Unintentional debt
- Process Shift – this happens when performance of the process degrades over time.
- Requirements Shift – this happens when the external realities change but your process fails to adjust adequately.
- Squeezing the balloon – the local process gets optimized at the (greater) expense of other parts of the organization (or customers or vendors)
- Intentional debt
- Short-term trade-offs to get a release out – scope removed, etc.
- Experiments to find out which possible solution is the right one
- Manual work-arounds in place of system integration (SOA team can’t give you your webservice in time? will a manual work around work for the first few weeks or months?)
- Sub-optimal integrations (batch instead of real-time, etc. )
- Assumptions around geography or localization or product line support.
- Enter tasks into work tracking or defect tracking software to track both the items that need to be worked on and the effort required to retire the debt incurred.
- Measure the process for squeeze-the-balloon effects (can be difficult if the other parts of the balloon are not measured).
- Teach the team not to take short-cuts that “aren’t worth entering compensating tasks in the software tracking tool” – if they’re not worth it then the short cuts aren’t worth it either.
- Another suggestion (from James Shore) is to measure Source Lines of Code (SLOC) as an approximation for technical debt. It isn’t an exact measure, but since lines of code will affect cost of maintenance, it is a reasonable proxy.