At InfoQ, reporter Amr Elssamadisy recently posted an article considering technical debt. Most teams—especially those who work with legacy systems—understand the dangers of technical debt. In short, when the quality of code suffers for the sake of expedited development, the team accrues what is called “technical debt.” Ideally, the team “repays” this debt by fixing sloppy coding and bugs before writing more code. So, to extend the budgeting metaphor, a development team should strive to “live within its means,” addressing technical debt when it accumulates, rather than moving forward and amassing more. In the InfoQ post, Elssamadisy considers whether technical debt is a technical problem or, as he asserts, a symptom of a larger organizational problem. That is, could technical debt be prevented by imposing more rigorous coding standards or utilizing agile development techniques, like test-driven design? Or is the fact that this debt is primarily visible to the development team the more formidable threat?

I’d love to hear what you think about this issue. Please share your thoughts in the comment section. If you’re looking for further reading on the topic, I’d highly recommend you download the whitepaper “Technical Debt and Design Death” by CSTs Michael James and Kane Mar.

I had heard that the latest release of ScrumWorks was being billed as the first enterprise-capable Scrum tool. (Since I’m unaware of any agile tool that can successfully scale without several modifications, it’s really the first enterprise-capable agile tool.) So I decided to watch a screencast to learn more. Now that I’ve seen what’s new in ScrumWorks Pro 4, I can say that it’s evident Danube is paying close attention to user feedback and working hard to resolve the impediments that have historically kept enterprises from successfully scaling.

One of the most important aspects of this release is “Epics,” which give users a powerful combination of deep functionality and tremendous flexibility that allows them to model shared components accurately, rather than conform to the limitations or idiosyncrasies of a tool. More specifically, the “Epics” feature gives organizations a way to pull back even farther and assess progress across multiple products and programs. Best of all, Danube achieved this functionality while remaining closely aligned to Scrum’s core principles. In fact, ScrumWorks Pro 4 and the “Epics” feature, in particular, were based on Scrum founder Ken Schwaber’s most recent book, The Enterprise and Scrum. If you think your development environment could benefit from such smart functionality, I highly recommend you take a look at this tool. You can read more about it here.