Managing Product Development

I received two questions this week about how well does agile allow you to do traceability matrix. Very well is the short answer. Here’s why.

If you commit to implementing features (not chunks of architecture)  based on user stories in an iteration, you know what you’re planning before the iteration starts. Because you’re working in a timeboxed iteration, and the testing is incorporated into the iteration, there’s no (ok, very little) time lag between the time you know what a requirement is supposed to be, and the time the requirement is implemented and tested. Now it’s a simple matter of paperwork (ok, maybe not trivial) to match the requirement with the code and the test. If you do test-driven development, and start with user-facing tests, it’s even easier.

The shorter your timebox, the easier traceability is. That’s because you have fewer features and fewer tests to manage.

Some of my clients keep their index cards and organize the traceability that way, with notes about where the tests are. They lock the index cards (post-iteration) in a fireproof safe. Other folks use a spreadsheet for the organizing. They use a source control system to manage the changes to the file.

Remember, the requirement is to trace the requirements through the code and tests and to be able to show you did that. The fewer artifacts, the better.

I’m an assertive, bold, blunt, and direct person. I try to live within the bureaucracies I encounter, but I don’t always succeed.

I’m at SD West this week, where I did a half-day tutorial Monday and am presenting two classes (really talks) today. Before I speak/teach/consult, I like to eat a real breakfast, so I don’t go for the quick continental breakfast; I need to eat in the restaurant.

The hotel has a small-ish restaurant. The tables are are either set in two’s or four’s. (Why do hotels do that, when most business people travel alone?) So Tuesday, the wait for a table at 7:30 (peak breakfast time) was 10-15 minutes.

I was sure I could find a friendly face to eat with, so I told the hostess I would look for one. She was shocked and dismayed–and quite unsure what I was going to do. I didn’t recognize anyone, so I asked a gentleman sitting at a table by himself if I could join him. I offered to not talk to him if he wasn’t a morning person.

He agreed to let me join him, and we had a lovely conversation. We each left with slightly new perspectives.

Having breakfast with a complete stranger is not normal–even for me. But when the hotel imposes a structure that says breakfast must take 45 minutes (yes, it does), and we must seat people with whomever they arrived with, and we must not hurry anyone up, I have no more patience. Hotel breakfasts are not for lingering, certainly not for conference attendees.

The hotel has no idea what business they are–what product they are selling, if you prefer. Yes, part of their product is hospitality. But for conferences, a bigger part of their product is moving people through the system quickly.

When the hotel doesn’t provide me part of their product, I’m bold enough (or crazy enough) to make it happen. Any of your customers beyond bold for your products?

Labels: customer, product, requirements

I have an all-in-one machine, a fax/copier/scanner/printer, that I use for copying, scanning and primarily faxing. It’s fine fax machine. And it’s a great copier. But when I hook it up to my computer for scanning to a file, it falls apart. Half the time (or more), my computer can’t establish a USB connection to the device. I was ready to throw the damn thing out the window when I thought, “Huh, I bet other people have this problem. I bet there’s new software. Go see.” I did. There was. I started to download.

I have a high speed connection, and it took me about 20 minutes to download the updated driver. OK. I can do other things while I’m downloading. And I did. 30 minutes later, I finally open the installer and try to install. It hangs about 3 minutes into it.

Since I have experience with crappy software from this vendor, I decide to quit a few applications. I do and the install proceeds a little farther. It stalls again. Ok, I quit all the applications and leave my computer alone to install. It does.

20 minutes later, I start up the scanning application, and wowie zowie, the entire UI has changed. Ok, I’m a smart person, I can figure this out. I was able to start scanning and save my files.

This should be a happy ending, right? Well, I’m only sort-of happy. That’s because my implicit requirements for the whole experience were not met. I expected:

• That the file download in about 10 minutes. I’m not sure why the download had to be that big. Why not zip it?
• To be able to install an application the way other Mac apps are installed–while I’m still working. Having to close all other apps is a very non-Mac approach. (Do you Windows users really have to do this? My goodness.)
• To specify a filename once. In order to save a file as an image, I had to specify a filename (that’s not used), start the scan, and then specify a filename again. To me, this is a defect.
• To use the Mac Finder to deal with my files in the application. Instead, I have to use the app’s view of the finder which doesn’t look much like my Mac.

I had a number of implicit requirements that were not met, mostly that the application look and feel like the other Mac apps on my machine. I’m not sure why that was so hard to do. Maybe the developers have never seen a Mac.

So imagine now that you’re a developer who’s just started to work in the banking domain. You have a lot of experience with selling online, so you know about transaction processing systems, but not about banking. How will you learn about the implicit requirements?

It’s worth thinking about this, no matter what your role is on the project. Those implicit requirements are still requirements. If your product doesn’t meet them, you will have unhappy customers. Even though I managed to accomplish the tasks I needed, the time it took me to accomplish them and the foreign approach to the UI made me not happy. Implicit requirements are still requirements. It’s worth thinking about how to make them more explicit. (One technique is to get early feedback from customers

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 iteration. “We can’t do that. Our users won’t let us.” Why not? “Because if they find it in this iteration, they want to add it to the next iteration, if not this iteration.”

The users/product owners/people in charge can certainly add stories to the next iteration–and they will push out what’s on tap for the next iteration. “But they don’t want to. They want us to do all that and all the new stuff.” I asked about their velocity charts and burndown charts. They have no data to explain what’s going on. And, they don’t have cross-functional meetings to re-rank the requirements between iterations. Oh boy.

Here’s what I suspect is what’s going on. The team doesn’t quite finish what they need to do for an iteration. They either have unfinished stories or accumulated technical debt. Maybe both. But instead of adjusting their velocity down, and finishing things for the next iteration, they attempt to do more. Since they can’t finish what they thought they could, they get even less done in the next iteration. And, because they’re not collecting and displaying data, they have no way to explain this to the organization. All the organization can see is that the project isn’t finishing anything.

Even those these folks are using iterations, because they’re not finishing work within an iteration, this project doesn’t look different to the other people in the organization. And they rest of the organization remembers how long it took to finish the last project. No wonder they’re putting pressure on the project team to do more in an iteration–they can’t tell when anything will be done.

I suggested they move to one-week iterations and to finish things within the iteration. Surely there was work they could do in a week. “Yeah, but it won’t be very much.” Bingo! That’s ok, as long as something is complete. Once people can see complete work out of the project team, they have some assurance the team will actually deliver something and can watch for more deliverables. (And, it will help the team estimate better.)

The problem isn’t actually requirements spawning more requirements. The problem is that the project team is not tracking any data that will give them feedback about their work. That data would help other people see what’s going on in the project, but because the data doesn’t exist, the other folks are too scared to trust the project team with any one iteration’s requirements; they want to see all the requirements done.

If you’re trying to move to an agile lifecycle, don’t forget that tracking the data is not just for you and the project team; it’s for the rest of the organization too. You may have a problem with spawning requirements. But you might have a problem where people are assigned to too many projects, so they can’t make progress on yours. Or you might have a problem of not enough automated tests, so the developers are getting feedback too late (outside the iteration) about work they thought was done. Or there’s maintenance work to do. Or people are underestimating what it will take to complete a story. Or any number of other potential problems.

The problem isn’t more requirements; it’s the team’s reaction to more requirements. In this case, they need to be gathering and showing some data. Without the data, people will still push on them to attempt more than what they can do.

I’m in the midst of writing the PM book (which is why I haven’t blogged much). One of my tips is that projects have both requirements and goals–and that the PM (at least) needs to know the difference.

A requirement can be a use case, user story, a shall statement, whatever. So can a goal. But a goal is something that if there is time (the effort is not on the critical path), the user or customer would want.

Let me be clear. Testing is not a goal. All too often, projects shortchange their testing efforts. The problem is: how much testing? I wish I had the answer. But if you find that your product’s technical debt is increasing with each release (or iteration), I would make more testing an explicit requirement for the next project.

When I discuss this topic in my PM workshop, some of the Agile folks say, “Well we have iterations and we don’t need to think about this–we only do what’s required in an iteration.” Yes, that’s true, especially for the first few iterations. And, at the end of the project, it’s possible that the team has a velocity of 15 user stories, but only has to complete 2 user stories in the iteration, as part of the requirements. That extra time can either be used to move people off the project onto another project (which has its own set of difficulties), or to add more stuff to the product–the goals.

It’s worth thinking about what’s necessary (requirements) for whom, and what’s a goal (and for whom). Sometimes increased performance or reliability is a goal, not just more features. Sometimes an earlier release date is a goal. Sometimes, paying down technical debt is a goal. But knowing what’s a goal and what’s a requirement helps the PM organize the project better (regardless of lifecycle) and helps focus the project team on the requirements.

Don has a great post on Single Point Requirements. You get one example of the requirements: “This product needs to do this. Just this.” Sure enough some months (or years) later, that single example is not sufficiently general to do everything you want the product to do.

That’s ok, as long as you plan to iterate the product development. If you really think that one example is all you’ll need, you will be bitten. But if you (and your customer) are smart enough to say, “Ok, we’ll get this for now, and see what happens over time,” you’ll be ready to iterate.

This happened to me when I was converting a database from one platform to another over 20 years ago. I’d received the spec for the database and assurances that the data was “clean.” I expected to spend up to a week on the script to convert the database and any cleaning by hand. Only the first 20 records in the database were clean. Ok, maybe the other 10,000 weren’t really out of spec, but over 1000 were, and all in different ways. What I expected to take a few tries (I was reading the database off a tape and writing to another tape–this is the olden days), took weeks of finding all the ways the data could be dirty.

I learned several things from that experience: to use a lab notebook to record what I was doing, including what had worked and what hadn’t worked; and to plan to iterate on anything that looked like it might be “the only way the data can look.”

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.

One of the questions I ask project teams is how they know what to do when. Most of the time, the developers look at me as if I’ve grown two heads and say, “Well, we look at the requirements. We do the high ones first, the medium ones next, and the low ones if we have a chance.” I then ask the next question, “Do you ever find that some of you implement different high requirements in a different order?”

If you have a system with multiple components to the architecture, such as a front-end, middleware, and a back-end, chances are good the developers are separated into functional teams of front, middle, and back. And, unless the teams talk to each other continuously, the teams will each approach the requirements in a different way, not a coherent effort. What that means is that the UI for data entry is complete, but the middleware isn’t done or the back end database work isn’t complete. Or the watchdog time is done to kick off events, but the event code isn’t complete. When pieces of a product are done, without making sure the entire feature is designed and written from end-to-end, problems ensue:

• The testers can’t test, because they can’t test one piece of the feature without the others in place. Even if you have testers who can write code, they can only perform unit testing, or perhaps module integration testing, not system-level testing.
• The probability of not-enough features being complete at release time is high, higher than I like.
• If you’re dealing with a long defect list, sometimes developers will fix defects they perceive to be easier to fix, rather than ones the customers need first (even if they’re taking defects in priority/severity order).

One of my clients complained about ranking, “We’ll have hundreds of requirements. It’s overwhelming.” If you’re still doing big releases, ranking requirements helps you create smaller releases. (Take the first 10 requirements and make that a smaller release. You don’t have to release to the external world, you can release to the test group.) You don’t have to have iterations if that bothers you. You can use staged delivery as a lifecycle. But people can’t deal with hundreds of things on their to-do lists. It’s too easy to not have a sense of urgency about the task list if it’s hundreds of tasks long. But if you rank requirements, you can then rank tasks. You can use rolling wave scheduling to schedule just the next month’s worth of deliverables, and now everyone has a manageable task list. The PM can work with people to make sure they’re keeping a steady pace, and if someone can’t complete their work when they thought they could, the PM can see the impact of that easily.

If you don’t rank the requirements, the developers will do so when they implement the requirements. I’d rather the project team make a conscious choice about when to implement which feature. Conscious choices lead me to better planning and monitoring of projects I manage.

In my last post, I argued that functional and non-functional requirements are unsuitable for the art of describing requirements. I prefer to discuss attributes of the system instead, and then talk about functionality. (Gause and Weinberg wrote Exploring Requirements, Quality Before Design describe how to do this.) But Laurent, in his Misfits, or there’s no such thing as a requirement”, says “A misfit occurs when some aspect of the form clashes with some aspect of the context.”

I like the idea that the form of what we’re trying to design and the context, how we’ll use the design, are in tension. Good design involves describing the tradeoffs and how those tradeoffs affect each other. This is why the agile techniques, where the index cards carrying the stories are more of a promise to discuss the requirements and the tradeoffs are so successful.

I get frustrated when I’m brought in to “save” a project, and I see reams of paper describing the requirements. Too often, the functional requirements (the description of what the system will do) are described in mind-numbing detail, with no attention paid to the non-functional requirements (system attributes, possibly Alexander’s notion of context). I can be sure when I see huge requirements docs that the project team thinks they’ve completed the requirements, but they haven’t had enough of the conversations to finish describing the requirements.

There are people who have successfully used huge requirements docs to make their project successful. In the cases I know of, they have used some sort of fit criteria (a la Robertson) and/or use cases in addition to the big functional requirements document. But if they don’t have some sort of context, or fit criteria, or use cases, I haven’t seen big requirements documents succeed.

I don’t really care how a project team describes the requirements, as long as the team thinks about more than just functional requirements. With requirements, it’s the thinking and discussing tradeoffs that is so important. With informed discussions, the requirements documentation is easy. As always, more to think about…

I’ve been thinking more about requirements. In the most recent two assessments I’ve done, both organizations have been stuck on thinking they could define their requirements before design and implementation.

IWBNI (It Would Be Nice If) users could know their requirements early. For small projects (a couple of people, maybe a couple of months) it might even be possible to fully know and define the requirements at the beginning of the project. But I contend it’s not possible for users to fully know their requirements early for any substantive effort.

The nature of software — ephemeral and malleable and not well understood by users until the users see the artifacts — guarantees that as soon as a user sees the system, the user will see the next step in the evolution of the requirements. (If any of you want to help me rewrite that sentence, please do.)

Here’s an example. Fifteen years ago, I bought a light timer for the lights outside the front door. We want the lights to come on when the sun goes down and go off when we’re all in for the evening. It was an electro-mechanical clock timer switch and worked for about ten years. About five years ago it started losing time and the ring around the outside was harder and harder to use, to set the time properly. Finally, I took Mark to Home Depot a couple of weekends ago and said, “Honey, it’s time for a new switch.” I used the don’t-argue-with-the-wife voice, and Mark decided to give in. He picked up a timer with an LCD display and put it in the cart. I picked it up and said, “Oh, no, this has software in it. We don’t need something this complicated.” We discussed it, and he used the don’t-argue-with-the-husband-who’s-going-to-install-it-for-you voice, and I acceded. Well, when he’s right, he’s right. I love the timer. It knows when sunset is, so the lights always come on at sunset. We don’t have to reprogram it every week, or risk the kids coming home to a dark entryway.

I didn’t think I needed the extra features. In fact I was sure I didn’t need them. It wasn’t until I saw how well the timer worked that I realized the extra features were exactly what I wanted. I don’t want to have to reprogram the timer every week during the winter. I don’t want to mess with it at all. But I was sure no product could do what this timer did. But the “extra” features are now part of what I require in a light timer.

I could have taken my own advice about requirements, and asked myself “What attributes of the timer are important to me, as a user?” I would have answered: ease of programming, fewer times of programming, programming override for those gray days. The first two in my list are system attributes, not functionality. Users are notoriously ambiguous about system attributes — not because they want to be, but because they literally don’t know how they want the system to work. The override is partly functionality, and partly an attribute of the system.

System attributes are the most important part of the requirements (some people call these non-functional requirements), and they are the hardest to determine in advance. One of the reasons agile methods work so well is that the user/customer sits with the team and discusses the system attributes constantly. If you’re not using agile methods, plan on iterating on requirements anyway. Especially plan on iterating through the system attributes, and the product cost for those attributes. You won’t know your requirements early, but you’ll learn them as you develop the system. And you’ll develop a product people want to buy.