The nice metaphor of technical debt introduced some 18 years ago by Ward Cunningham has slowly taken roots in our collective conceptual toolbox, as a nice way to express some of the pains that software projects suffer from. Most software developers who have had some experience with significant, long-lived projects can feel it, sometimes point to it, but more than often can’t do much about it. In most cases, technical debt is seen as something very negative, burdening projects forever under increasing amount of interests. But some technical debt can be deliberate, more akin to borrowing to make an strategic investment, and this is especially the case for architectural-level debt.
As Agile approaches are gaining acceptance in software development organization, this article discusses how Agile could impact the support and maintenance processes of existing mature products.
A lot of things can go wrong during a Scrum sprint. In his blog post, Ilan Goldstein makes a list of some common issues in Scrum sprints and how you should deal with them. He recommends to gather as much data about these speed humps as possible so that you can inspect and adapt your processes and start bridging the gap between theoretical planning and reality.
Sometimes, user documentation is not a nice to have but a legal requirement or a requirement to meet a standard like the FDA. But more important, quality user documentation improves the usability of the product and enhances the credibility of the company.
The adoption of Agile approaches has introduced new ways of thinking about Project Management, which impact Project Management Organizations in various ways. This paper divides the range of practices commonly found in Project Management Office (PMO) into Project Management, Program Management and Portfolio Management. It identifies how the introduction of Agile processes such as Scrum impacts the PMO.
Burn charts are a simple method to monitor work progress in Scrum. This article discusses the details of burn down and burn up charts: which units to measure, how to adapt to scope variations. He gives some guidelines on how to interpret burndown charts. He reminds that the chart should be objective and visible.
Pair programming is sometimes the norm, and some developers really enjoy the collaboration, experiencing enhanced productivity. In other teams, pairing is shunned, avoided, or… faked. Angela Harms did a short survey about pairing attitudes and compared successful and unsuccessful pairing experiences.