I’m not a fan of ROI (Return on Investment) measures for software, except in the case where you have waste. Several of my clients have huge technical debt which creates waste for the development staff (not just developers, anyone involved with the development of the product). When you’re dealing with waste, user stories just might […]
I’m editing the project portfolio book. Yes, I’m trying to get ready for beta. No, I have no idea when I will be ready. I’ll have more information before Wednesday, if you want to know. I realized that when managers don’t make ranking decisions about the project portfolio, when they don’t fully commit to a
Via Jack Vinson, I found this gem: Stop doing half-actions. All of you who are separating your developers from your testers? You are doing half-actions. Separating the writers from the developers and testers? Half actions there, too. Even when you define architecture and implement across the architecture, instead of by feature, that’s a half-action. A
Some folks have told me in their agile projects that they are able to deal with technical debt as they find it. They are a lucky few. But more have been stumped: “I find something. I really can’t fix it now. But I don’t know what to do with it.” I’ve suggested putting it on
One of the problems I see in projects is that there is not a sufficient definition of done. For agile teams, it’s not clear what done means for a timebox. For non-agile projects, the team may not agree on what done means for a milestone or for a release. For an agile team, do you
Tristan, the senior manager in charge of all projects, strides into Ilene’s office and plunks himself down in her visitor’s chair. “Ilene, you are the project manager in charge of the project to save the company, right?” Ilene nods. “I really need you to fit this other feature into this release,” Tristran says. “We’re toast
A colleague asked me what to do when you’re in an iteration and you realize that the story you’re working on spawns other requirements. I suggested that the person add them to the product backlog (the backlog of everything you want to do for the product) and re-rank the requirements in preparation for the next
I’ve had technical debt on my mind recently, so I’ve been writing about it. This week, the good folks at Stickyminds published my column, An Incremental Technique to Pay Off Testing Technical Debt. Enjoy!
Technical debt is the unfinished work the product development team accumulated from previous releases. This debt includes: design debt, where the design is insufficiently robust in some areas; development debt, where pieces of the code are missing; and testing debt, where tests were not developed or run against the code. Technical debt is common, but
Technical debt is the unfinished work the product development team accumulated from previous releases. This debt includes: design debt, where the design is insufficiently robust in some areas; development debt, where pieces of the code are missing; and testing debt, where tests were not developed or run against the code. Technical debt is common, but