Managing Product Development

Read “Everything You Need to Know About Writing Successfully - in Ten Minutes”, and when you’re done chuckling, note the necessary ideas:

• His point #5: throw away reference books. This works for all first drafts. I don’t care if you’re writing a novel, a spec, or code. It works. Interrupting flow and what do you have? Mistakes. Lots of them. Stay in flow and what do you have? Something that fits together — but is not necessarily done after the first draft. That’s fine. You don’t want something done after the first draft, because all writing requires
• His point # 3 and 4: being self-critical and remove every extraneous word. This is refactoring as you proceed, not waiting until you’ve already checked in the code, or asked for review. If you’ve done this and you’re stuck, fine, ask for help. But first read your own work and see what you can take out.

I highly recommend King’s On Writing if you’re thinking of writing anything. I have the hardcopy version, and it is one of the best investments I made in my writing.

Take a look at these links:

1. Tricks of the Trade, thanks to Dave Liebriech. When I was a tester, I read the code (this tip is far down on the list.) I’m not sure the developers appreciated my questions, but if I didn’t understand something, I asked.

Here’s a tip I learned for people who need to facilitate meetings:

Always take blue painter’s tape to a meeting. You can use it to hang flip charts on any wall, or to organize index cards or stickies together, without fear that the adhesive will stick to the walls. You have to be more careful with paper, but the glue on the back of painter’s tape is less sticky than other tape.

2. Outsourcing? Consider the Source. I was a “quacko” (tester) with Tom Parmenter a long time ago. I vividly remember telling one manager or team that they could choose to release software that couldn’t be installed, but I wasn’t going to sit on the phones explaining the magic required to make the install work. We used an incremental/iterative lifecycle, organized as phase-gates. It worked (unless someone tried to finesse the exit criteria for a phase), but only in our culture. Culture matters, as well as process if you’re going to consider outsourcing.

I had lunch with a friend-of-a-friend today. She’s considering moving to a process improvement position. I suggested she not move from a technical lead to a process improvement position — I don’t trust staff positions in this not-yet-robust economy. So I asked her why not do process improvement where she is, in her circle of influence? I suggested these possibilities:

• Start a web page (or a blog, but I think she wants to keep these issues private to the organization). Every time she and/or her team do something that improves the current state, note it on the web page.
• Offer the page to her colleagues, “This worked for me. If it works for you, let me know. If you improve it, let me know that too.”
• Note privately to her manager when something is broken, and the cost to her project. This isn’t whining, it’s explaining why it took three days to find the sources instead of three minutes.

I also suggested that she consider a management position. I firmly believe that it’s a manager’s job to understand his or her group’s process and to recognize when that process needs improvement. It’s not clear to me that a large initiative from the top down works — except to create process cynics. I’ve seen process improvement work when each manager (or in this case, technical lead) looks at his or her group’s work and starts to improve locally, offering those suggestions to the rest of the organization. Then, when the managers work together, process improvement happens as part of the organization’s business.

Managers have a responsibility to deliver results and to continually increase capacity. One technique for increasing capacity is to improve their group’s process. But process improvement doesn’t have to be (and often isn’t successful when it’s) initiated from the top of the organizaiton down. Start where you are and grab those low-hanging process improvement fruits. You’ll be miles ahead of the managers who aren’t paying attention to their group’s process.

Thanks to Brian Marick, I read Dave Thomas’s Weeding Out Bugs. Much of Bug-Weeding is developer turf. But here’s what managers can do to help:

• Look at defect counts by module. When you see a module that has more than it’s fair share of defects, start asking questions about what the developers are considering. You’ll all need to weigh the risks of wholesale tossing and rewriting, but the manager’s job is to start the conversation if the developers haven’t already.
• Make sure the developers fix builds before they go on to more coding. (I like to make sure the project team can build at least once every day. If your project team can’t already build frequently, consider a project to make it easy to build every day. And for those of you with humongous projects where you only build every week or so — continue at your peril. Break apart the builds so the project team can create a new build every day.) Developers have bad-code days. If you discover someone (or ones) had a bad-code day yesterday, you have an opportunity for very quick feedback to the developer(s) so he or she can fix his or her defects. If developers fix defects before they go on to more coding, you’ve reduced the overall defect counts. And you’ve really made a milestone, not just met a date where people claim they’ve met a milestone (”except for all those bugs we have to fix”).
• Monitor the cost to fix a defect. Clarke recently wrote about Quantify the cost of reworking bugs?, to see how long bug-fixing added to the schedule. Managers can monitor if the finding cost is higher than the fixing cost. The higher the finding cost, the more time people are spending in defect-prevention activities. The higher the fixing cost, the more time people spend in defect-fixing activities.
• Monitor the fault feedback ratio, the number of bad fixes to total fixes. My rule of thumb is a project can make progress with an FFR of 8% or less. More than 8% and developers are spinning their wheels.
• Monitor system size. Back when I was a developer working on a substantial system, I was amazed at how my end-of-the-release defect-fixing caused my code to vanish. I now know I was refactoring at the end. It’s better to refactor as you go along, but sometimes, you can’t see the simplicities until the end. (A good reason to make lots of little ends.) Software follows an “S” curve of creation: some code starts, there’s a fairly dramatic increase, and then a tailing off. When developers refactor their code (the tailing off), they lose up to about 1/3 of the total number of lines of code (my data, yours may vary). If developers tell you they’re done, but the total LOC count doesn’t go down, you can look for other ways to test that doneness.

Managers can’t just monitor the schedule. (I can always claim to be done. The real question is how good is my work product in a given amount of time.) It makes no sense to only monitor product creation and cost unless you also monitor defect creation and cost. Then you can avoid the weeds.

I was reading Hiring Great Hackers, and I realized what went wrong in the places I’ve worked who hired great hackers. (In this case, a hacker is not a derogatory term, it’s someone who lives and breathes producing great software — just not software that yet has a customer base.) The problem was the managers were not as good as managing as the hackers were at developing.

Great hackers deserve great managers. Great managers create an environment in which people can perform great work. They deliver results and increase capacity in their organization while doing developing and maintaining that work environment. In many companies with great hackers, managers need to organize the work to define and release a product, all while discussing the merits of doing the technically “right” thing.

This is hard work — very hard work. And since most of it happens behind closed doors, it’s harder to observe others, to see what you need to do to be a great manager. And, it’s hard to measure. Which means it’s hard to know if you’re doing a great job — being a great manager.

The more talented the people in your organization, the better your managers need to be.

Esther’s here this week (again), so we can finish the pre-review draft of the book. We’re telling the story of a great manager who’s just arrived to a new organization. We describe meetings ,where we wanted to say “Everyone nodded.” I wanted to add “like bobble-headed dolls.” While that’s humorous, it’s not very respectful to people caught in terrible meetings or in situations they can’t see their way out of — and they feel their only recourse is to nod like bobble-headed dolls. We changed the dialogue. (And, we’re trying to help people see alternatives.)

Well, that’s certainly a provocative title. Let’s see if I can back it up First, read Keith Ray’s Engineering post, where he says

“software development is a cooperative “game” in creating and deploying “knowledge” and various people-oriented practices help make that work”

Some of my recent posts about requirements show the problems when software people don’t refine their requirements with customers. See here and here.

I’ve also been reading Phillip Armour’s The Laws of Software Process: A New Model for the Production and Management of Software. Phillip says software isn’t a product or service; it’s knowledge. The more knowledge the developers don’t know and have to encapsulate in the software, the less you can define the requirements (I’m paraphrasing, I don’t think Phillip actually says that anywhere).

So, if I’m right — or even close to right, which is good enough (because I’m constantly refining my ideas) — then we can forget about defining requirements once and for all. Once and for all is never going to happen. Sure, we can start defining requirements. And we should spend as little time as possible, and make that definition as low fidelity as possible as long as the fidelity is appropriate for your project’s context. So if you’re developing a product that doesn’t have human life implication, timeboxing requirements, paper prototypes, storyboards, informal use cases and other fast and low fidelity techniques are suitable. If you’ll be auditing your product or product development process, and/or people’s lives depend on your software, you may want more requirements cycles which include more cycles of requirements refinements, including higher fidelity techniques, especially including use cases with non-happy paths (the paths where things go wrong).

I’ve seen many software products where people spent way too much time defining the requirements as perfectly as possible, and it wasn’t until they saw part of the product in use that they realized their definition was wrong and/or incomplete. I’ve also seen lots of projects waste time attempting to define requirements in depth when a breadth approach plus a promise to refine the requirements with the developers would have been a much more effective use of time. I can’t tell you where on the continuum of definition and conversation your needs fall, but I’m sure that time-consuming up-front definition without more conversation is wrong.

I’ve been traveling a lot this summer, and I saw bad requirements exposed while waiting for my turn at the kiosk. If you buy an e-ticket, you can walk up to a computer, called a kiosk, insert a major credit card, and check in. No one calls you. You have to know the computer is called a kiosk (which is not the same as a mall kiosk). You have to know that you’re limited to 2 bags, that you need an id (ok, I’m not sure how people missed this), and a whole bunch of other stuff. Lots of people travel in the summer who fly once every few months or every few years. They don’t know what they’re supposed to do.

While I was in line, the first people were happily waiting to be called to the people behind the counter. The people behind the counter were talking, waiting for people to come to the kiosks. I was too far away to be helpful — even I don’t think it’s helpful to yell across 20-30 feet, “Go use a machine!” Even if I’d yelled it, the people would not have known what to do. Finally, someone had pity on all of us in line, and explained that the people in line had to walk up to a machine.

Even when these folks moved to a machine, they didn’t look at the machine to see the terse instructions — instructions you can understand if you’ve use a kiosk before, but not if you haven’t. (Kiosks started about 6-9 months ago? and when the airlines started using them, they had helpful people standing around explaining how to use them.) These folks still thought they were going to be waited on — like the last time they flew.

I think the kiosks are too hard to use for a new traveler — they automate what a counter person does, not what a traveler does — but once you’ve used one, the rest are similar. But, here’s a perfect example of not thinking about the consequences of changing how travelers check in. Sure, the airlines had plenty of helpful people when they introduced the kiosks, but they don’t now. E-tickets don’t say how to use the machines. You already have to know how these things work to use them successfully. I’m allowing more time at the airport these days, to accomodate the people who just don’t know. (And to accomodate the people who refuse to take off their shoes in the security line.)

What have you changed in your product? If you have non-frequent users, do they know what to do? Do your users know how to use your product — especially now that it’s changed? Make it a conscious decision to change things, and then decide how you’ll educate your users.

Esther and I have been editing the management book this week. We’re pairing to edit also - one keyboard, one file, two heads. It’s exhausting and fun. Here are things I’ve learned this week:

• We don’t have the same default ways to write — and that’s ok. The manuscript is richer for us talking through how the words should be.
• When we’re laughing out loud, we’re synching. Not quite in flow, but close.
• When one snaps at the other, it’s time for a break.
• The product is much better than it would be if we did the standard one-person-write/other-person-edit pass back and forth. We tried that. The writing is crisper. The word choice is better. The manuscript flows.

If you haven’t tried pairing yet, to create some form of intellectual property, consider it. I’ve paired for programming and for writing now. It’s fun. Exhausting and trying sometimes, but absolutely worth it.

Martin Fowler recently posted PreferFunctionalOrganization. Here, his functional organization means “organize around the business functions,” what management would call a project-based organization and his technical organization means “organize around the technical functions,” what management would call a functional-based (development, test) organization. There’s another option, that I didn’t see on Martin’s site, the matrix organization. In a matrix organization, managers of technical functions assign their people to business-based initiatives (projects).

As Martin says, “Since the whole point of software development is to serve its customers, then the organization should reflect this - yielding teams that are focused on providing business value rather than delving deep into technical esoterica.” One key way to do that, no matter what your organization, is to implement by slice.

Here’s an example of implementing by slice: Say you’re a bank and you want to take in new customers. For you, speed of intake is important. If you can’t take in a customer (create an account) in 10 minutes, your customer will walk out the door and go down the street to your competitor. So, if you were to implement by slice, when you create-a-new-account, you would make sure that the GUI, the middleware, and all that database magic that happens in the back office all occurs in a specific time. Notice that implement by slice says pick one type of an account, implement all that, and then go on to a new account type. Now I’m not a banker, so I’m sure I’ve simplified this past the state of absurdity. But think about it. Create-a-new-account is a basic service offered by a bank. Just imagine if you had an organization (in Martin’s terms, a functional organization) built around the idea of creating new accounts. You could have a small team of GUI designers, middleware people, database experts, testers, writers for the necessary help, all of the necessary skills, only focused on making a particular type of create-a-new-account software valuable to the business.

In Martin’s “technical organization,” people focus on increasing their knowledge in their own area of expertise, and loaning that knowledge to the projects as they are assigned. In the create-a-new-account scenario, you’d have DB people organizing all the DB functions and creating just the right schema. But you may never realize the interactions between the different functions. What happens when you change the GUI so that a specific field is available earlier or later? What happens if you need to access a different database earlier or later than the original design specified? And, if you don’t implement by slice, if you implement by technical organization (first the GUI, then the middleware, etc), then you’re likely to encounter these problems:

• You stop the project because it’s time, and you haven’t finished something. Most often, the software closer to the customer/buyer (the GUI) is completed, but the back end is incomplete.
• You reinforce the barriers between the teams because you’ve built up technical debt in the product. People have to work harder to overcome the technical debt.
• You didn’t really deliver what the customer wanted.

Martin’s suggestion of a project-based organization is a great idea. But if you can’t organize that way, make sure you implement that way — implementing features as a slice. Don’t try to bunch up feature development (all the GUI, or all the network, or all the anything). Just implement what you need to do for a specific feature and let the design emerge. Since you’ll be delivering (even if it’s just to the rest of the project team) pieces that work, you won’t have a huge investment of time that you’ll feel is wasted if you have to redesign something.