Managing Product Development

Dave and Bob have great comments on my post, Might Three Backlogs Be Better Than One?. Dave is describing situations where management is making reasonable decisions, not incurring management debt, and by extension, technical debt. Bob and I have experience with significant management debt. (Take a look at Musings About Management Debt for more information about what I mean by management debt.)

Let me provide a little more perspective on these situations. The clients range from large systems of up to a million lines of code (but still software-in-the-small) to software-in-the-large systems of 14, 15, 16 million lines of code. These systems have been in existence for more than 5 or 6 years. They are the flagship, and sometimes only, product that creates revenue. In each case, management is fairly new. The product owner players are new. Many of the technical people are new.

No one knows enough to make good decisions. Yes, they should have one backlog, and they don’t know how to prune the defect list. When you’re talking about more than a few thousand defects, the number is just too big. When your builds take longer than one day, when you have no automated tests, when you’re using a configuration management system from the ’70s (ok, not quite that bad, but close), and you don’t know how to break down the work into small chunks, it’s all overwhelming. Oh, and don’t forget the customers breathing down your neck for not just the defects you need to fix yesterday, but the features the sales people promised tomorrow.

One VP told me he could not make the decisions. He was concerned about who he needed (“do I need all of Engineering??”) and the time to rank into one backlog (“We’ll be here all day and we won’t be able to trade off against features and defects”).

He’s inherited a situation not of his making. He knows that if he can get people to start working in an agile way, they could make progress and finish some work. That would make their decision-making easier. But he has no roadmaps for feature sets for the product to see into the short-term or long-term future. He doesn’t know how many of the 1000’s of defects are still valid. (He thinks more than he wants.) Everybody is nervous. No one feels as if he or she can make a decision alone. The notion of a product owner as a “single, wringable neck” (do I credit Mike Dwyer or someone else with that phrase?) is not something they are ready for. They wanted a committee. I did manage to talk them into a committee of 2: one technical person and one marketing person. That technical person is the erstwhile project manager and the marketing person is talking himself into being a product owner.

I don’t claim these folks are agile. I don’t think they would either. They are working in timeboxed iterations. They are trying to finish valuable chunks of work in those timeboxes. They are struggling with how to make their decisions.

One thing I know about decisions is that the smaller the decision, the easier it is to make it. When you have to make tons of decisions that last forever, it’s really difficult, especially if you think you don’t know enough. At first, they all thought their technical debt was too huge to make inroads. But when I explained how to break down their technical debt into user stories, and that they didn’t have to tackle everything at once, that if they could just get the build to take less than a day they would already be ahead of the game. They didn’t need to stop developing features or fixing problems to address their technical debt.

As we see more people who have used a phased approach to development for years, and have not had tremendous success move to agile approaches, we will see people who may not be ready for real agile, but are ready (desperate?) to try something else that will provide value. We need to help them move from their previous insufficient decision-making to decision-making that will work. I do like baby steps. (See  Small Steps Are Good; Be Careful What You Call Those Steps).

I do worry about the issue of three backlogs. In the face of no decisions, I still think it’s better to make some decisions even if the outcome of those decisions is not one backog. Maybe other people have had better results nudging decision-free organizations to decisions faster than I have. I do think that the visibility of the different kinds of work can help people out of their defeatist attitude of “We have so much to do, we can never finish it.” One of these clients is actually pruning their defect list this week. The reason they can do that is because they took one story off the technical debt list, finished it, made so much more progress in just two weeks that the person-who-might-be-called-the-product-owner-but-is-resisting-the-role asked if they could finish a few defects in the next iteration, and how many did they really have anyway? They have bought themselves room to breathe.

Agile–real agile–is about making decisions based on business value, and delivering valuable chunks of work in a small timebox. If you have an organization that can’t decide on business value, you are in trouble. If you have better ideas, I’d love to hear them.

Tweet This Post

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 be the thing to help discuss how much waste now and later, when you fix the technical debt.

Here’s an example. Say the full build currently takes three days to complete. An incremental build takes at least 6 hours. You might create these user stories:

• As a developer, I want to be able to build the full system from my machine in under 30  minutes so I can see what the effects of my changes are to the whole system. (Yes, I know, you might want it shorter, but to go from 3 days to 30 minutes sounds impossible to these folks.)
• As a developer, I want to be able to do an incremental build from my machine in under 5 minutes so I can see the effects of some of my changes without having to do a full build. This will allow me to make progress faster on small chunks of work.

One senior manager asked, “How many full builds do you do per day now?” “We can only do one every three days, so none.” “How much will this save?”

The real key to savings is how long does it take for a developer to find and fix a defect. In this organization, it takes 3-7 days for a developer to find and fix defects, before the code is tested by anyone else. That means there is no such thing as a one-day task. The minimum duration task is 3 days.

Well, when the senior manager heard that, he said, “How long will it take to fix the build system?” “We think it’s 4-5 weeks of these 3 people.” That’s 12-15 person weeks to fix a problem that prevents 65 developers from finishing anything quickly. As the manager said, “No brainer. Fix the build system first, and tell me how did it get this way after you fix it. We want to prevent it from getting there again.”

If you’re having trouble getting your technical debt work into an iteration, consider using user stories and explaining the cost of the user story for each type of user vs. the cost of continuing to work the way you are. You might be pleasantly surprised.

Tweet This Post

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 project, when they don’t collaborate across the organization to make sure everyone is working for the good of the organization, the managers incur management debt. And, these actions all create technical debt.

I suspect that these managers don’t know they are supposed to do these things–they’ve never seen good management before.

You can see management debt in these ways:

• Managers revisit decisions again and again and again and again…
• People stay blocked on problems because they need management input
• No one removes obstacles for the team
• Many emergency projects
• Everyone feels as if they are slogging through the day, even though managers are rushing around like crazy, using their smart phones and pagers and email.

What do you think? Do you like the term management debt? Did I miss any other symptoms of management debt (I’m sure I did!)?

Tweet This Post

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 half-action means you have technical debt and will have to get back to that area of the product.

Silos encourage half-actions (or third-actions or sixth-actions). Defining the architecture and implementing across it encourages half-actions. Create a cross-functional product development team. Have them finish one feature at a time. That’s a full action.

Tweet This Post

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 the backlog, which of course, incurs a context switch when you’re finally ready to deal with it. But, the debt is visible. And you can size it. And schedule it.

Arnon thinks the backlog is the right place to deal with technical debt, too. In Make technical debt explicit, he says

• It will not be forgotten
• It will not be hidden
• It will be managed

The transparency the backlog provides is critical for making good decisions about the product and the project. Technical debt needs to be as visible as everything else. Maybe more so, because the more debt you have, the slower any future development will be.

Tweet This Post

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!

Tweet This Post

A reader sent me email with this question: “We have a group of four people (3 developers and a tester). We work on 4 products, releasing one about once a month (each product is released once a quarter). The developers are devoted to one product when they’re developing, but have to fix problems immediately if someone finds a problem and reports it. How do I manage the multi-tasking?”

I’ve asked the reader a few questions. I still don’t know everything about the environment, but here’s what I suspect is happening, based on my questions:

Each product has technical debt, from insufficient testing (all the way through development) from previous releases.

There are a ton of ways to deal with insufficient testing. I would first start with peer review of fixes. If someone is interrupted from new development to deal with an already-existing, but newly discovered problem, have the developer ask a peer to review the fix. Part of the peer review would be to create automated tests for this fix. (Yes, I realize this now interrupts two people. I find that if there’s a Big Problem in one product, there are frequently other related Big Problems in the related products.)

After peer review and automated tests, I would (gently) ask the tester how the tester missed this problem. This is for root cause analysis, not to assign blame. The tester doesn’t read or write code, so the tester can only perform black box testing. Black box testing, by its very nature, is unlikely to find most of the gotcha’s in a product. After a short root cause analysis, I would add some form of automated test development activity to each project.

I can see some heads shaking from here. “If we take time to add tests, we can’t add as many features.” You’re absolutely right. But here’s the problem. You’re not adding the features now. You’re adding broken almost-features. That’s not helping the customers. The customers deserve to have features that work.

So, to deal with multi-tasking from defects in a small group, I recommend changing the way you work. If you keep the same lifecycle you have now, add the practice of peer review of all code and all fixes. Add in automated testing for all defects that have to be fixed from the field. Change the testing, because it’s not exposing the Big Problems before you release. If you choose to change lifecycles, I suggest an agile lifecycle with test-driven development.

Whatever you do, don’t assume that wishing away the problem will make it go away. Some practices need to change. Maybe not the ones I’ve suggested, but some of them do. The change will take time, depending on how much technical debt you have. Otherwise, you’re left with the quality pledge and no muscle behind it.

Tweet This Post