Managing Product Development

I’m on an around-the-world trip in March. I’m speaking at the Software Development conferences in Wellington on March 15, and in Sydney on March 17. Any bloggers interested in getting together for a dinner on March 15 or March 17? I’ll be in Perth for the weekend, and then travel on to Israel (Mar 23-31), teaching for Sela. Send me email — I’d love to meet you and put faces with people’s names.

Tweet This Post

Caveat: I just started thinking about this, so I don’t feel particularly articulate.

After reading Roy’s post of Kent Beck’s discussion “Invest in the design of the system every day”, I realized that’s what I do for project planning. Every day, I’ll adapt the work I’ve planned to do, to meet the needs of the project. That doesn’t mean I’ll necessarily change direction, but I’ll think about the current project state, and what else we need to do.

We’ve all see the phenomenon that as soon as you’ve scheduled the project, the schedule is out of date. If you plan to invest in replanning and rescheduling, that doesn’t matter.

This works for programs, product management, all the work that’s affiliated with product development, but may not be strictly considered product development. Adapting your work to the current state is investing in the design of your work every day.

Tweet This Post

I have several accounts with a credit card company: two cards and a merchant account. They don’t want the expense of printing monthly statements for the merchant account, so they sent me a letter to enroll my merchant account in online statements to avoid the paper charge.

In my default browser (Safari), I attempt to log in. I can’t (Problem #1). In fact, I end up in browser limbo, with some message about too many redirect (Problem #2). I try to log in in Explorer. I can’t. It tells the me password is wrong (Problem #3). I call the 800 number three times before I get someone who tells me I need a new user id. I ask why. The nice lady says, “We keep our businesses separate, so you need a user id.” I say, “But (and I’m starting to rave here), the web UI looks the same. I have tabs at the top of each page that allow me to move back and forth. If you’ve integrated the web page, why not integrate the user ids???” (I’m definitly speaking loudly, because I’m so angry with the stupidity, waste of my time, and lack of documentation.) Poor lady just keeps saying they keep their business separate (Problem #4).

These are serious problems. I’m not a UI designer — I’m a user. This makes me an expert — in using computer systems, not designing them. The problems:

1. If a user attempts to log in and can’t, catch the error. Safari shouldn’t have tried to deal with this error, the web site app should have. Catching an unable to log in error is basic programming. How could they have missed this?
2. Why do you care what browser your users use? The world is full of browsers. That’s why we have Java. Accomodate all the browsers. Sure it means that you have to write code more carefully and test on many platforms. Is it worth losing any customers because your developers were too lazy to write good code?
3. Make sure the error text matches the error. There was nothing wrong with my password; they wanted a new user id. The problem is the text on the page. The text says “New user? Create an id.” But I’m not a new user. I manage my credit cards online every month. I’m an experienced user. The instructions were inadequate, as well as the error text.
4. If you have a consistent look and feel to the site, and you’re trying to seel multiple services to one customer, don’t make the customer have multiple ids, one for each service. I’m sure that having multiple ids makes it easy for this company to track revenue by division. But it makes it much harder for me to manage my user ids and passwords. Who is the customer here?

To add insult to injury, I can’t write this in an email and send them feedback. (Problem #5) I can call (and spend more time on hold? No thank you), but I can’t write. So, I’ve now made a public example of a stupid website. Great. When I make mistakes, I want people to tell me, not write about it somewhere public. Gotta wonder why these people don’t care.

Ok, tirade about stupid UIs off. Back to work.

Tweet This Post

I’m working with Esther this week on the book. We’re editing (and continuing to pair-write and pair-edit). Today, one of the things we addressed were the comments dealing with the people we name in the book. We hadn’t done a good job drawing our readers in to care about the people. So we’re fixing that. One technique we’re using is to fill out a character sheet about each character.

I already had a picture in my head for each character. Esther may have, and her picture is different from mine. At one point today, I joked, “Can’t you just read my mind?” Esther replied (with a straight face), “No, your skull is too thick.”

Well, we lost about 5 minutes of work with that. I was almost rolling on the floor. Esther laughed almost as hard as I did.

Even when pairing, people can’t know what the other person is thinking. You can be headed in the same direction, but still veer off. And that’s ok. We don’t have to be clairvoyant to be effective working with each other. And I still think that pairs who laugh together are very effective.

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

I just received this in email:

Pledge

Our company is completely and absolutely committed to quality. *

* Except on time-critical projects and during adverse cash-flow situations.

When else would you need to be committed to quality? (Not to zero defects, but to an appropriate level of quality for the product you’re trying to build.) The higher the schedule risk (which turns into a money risk), the more need for building in quality. You certainly don’t have time to do it again.

Tweet This Post

I’m catching up with my blog reading, and discovered these two gems:

Staying Awake has links to comparing the lack of sleep with too much alcohol. Since I’m a one-drink-one-drunk person (well, ok, not drunk, but certainly not sober), this one resonated with me.

And via Steve Norrie’s blog, I discovered this oldie-but-goodie, Personal Chemistry and the Healthy Body.

I don’t do resolutions. I find that just deciding one day I’m going to change isn’t enough — I need to set up a system that allows me to change. But if you’re a resolution kind of person, maybe these articles will help.

Tweet This Post