Managing Product Development

About a month ago, I spoke with a project manager who’d inherited a project in chaos. No one was making progress. He was stumped–he’d never worked on a project where the developers couldn’t do anything, the testers couldn’t do anything, and time was just slipping away.

I suggested he try baby steps. What’s the first thing the project needs to deliver? Just focus on one small thing. He did have an answer, but the feature was large. He thought it would take 2-3 weeks to deliver it, coded as well as tested.

Since he knew what the team needed to do, he could use timeboxes to focus people’s attention on that work. I suggested he use one-week timeboxes, to make sure people figured out what they needed to do, just for the first week, and that the project team work together to make sure they were all working towards the same goal. Once he got the first week working, he could do the same thing for the second and third weeks.

The reason one-week timeboxes work to focus people is that when a project is in chaos, people tend to be in chaos too. They get easily distracted. A timebox, especially a short timebox is really good for helping people make progress and breathe.

He had never done week-by-week planning, so I suggested yellow sticky scheduling, focusing on the deliverables that would finish the feature. It’s not a hard concept, so he was able to do it.

I caught up with him last week, and sure enough the timeboxes along with focusing on one feature at a time worked. He and the team were able to show progress, which bought them a slight decrease in pressure from the their senior management team. Now, he and the team could choose how to proceed.

I suggested he continue with the timeboxes and incremental approach to the project, to make sure people stayed focused and didn’t drift into chaos.

“But timeboxes seem like such baby steps. Do I really need to stick with the baby steps?”

No, he doesn’t have to. But there’s no reason to think that the people won’t go back into chaos as soon as they remove the focus of the timeboxes. And if he stops implementing by feature, they will revert to no progress.

I’m sure there are other solutions to the not making progress problem. But if an entire project is stuck, try small baby steps to bring some focus and progress back to the project.

It’s winter here in Massachusetts, and we’ve had lots of snow, ice, rain, snow, ice, snow, ice, rain. All that freezing and melting plays havoc with the roads. We have lots of potholes, and the local and state governments are busy doing emergency repairs all over the place. (For those of you who don’t know how potholes are made, first the water seeps in through the cracks in the roads. When the temperature drops and the water under the road freezes, the cracks get bigger. Loop until the road surface breaks apart and creates a hole. When the holes are deeper than a few inches and longer than a few inches, it’s time for emergency repairs. We have some foot-long and foot-deep potholes right now. Yuck.)

Potholes are a fact of life in the northern climates when you have cycles of freeze and thaw. But I’ve been talking to some folks whose defects are like potholes. “We only have time for emergency fixes.” “We have time to fix and fix the same darn thing over again, but we don’t have time to do it right.” That’s when your defects are like potholes.

Potholes slow down traffic, because the cars need to drive slowly through them, or around them. Defects, especially big ones, slow down other development or fixes. So, what do you do?

If you have a ton of defects, I would choose a one-week timebox, and work on fixing them. For me, fixing means developing a fix along with a unit test (or two or three), getting some peer review, and then checking it in so the developer can do some around-the-area testing before system test. I don’t care if the developers write the unit test first, I just care that they write some unit tests. Although, if you’ve got defects, you’ve got the makings of a bunch of great unit tests. I would not allow any development in this timebox, just fixing and checking the fixes in a variety of ways.

After making some progress and getting the defect counts lower, decide if you want another one-week timebox. Is it more valuable to finish (fix defects) than write new stuff and have old stuff unfinished? I don’t know, but you do for your project.

For the rest of the project, I would make sure people are working by feature, developing and fixing and checking a whole feature in totality before moving on to the next one.

If you’ve got a bazillion defects, they are like potholes–they prevent you from moving smoothly onto the next piece in your project. Fix them! No emergency repairs either–real fixes.

I reported on my progress cleaning up my office previously . I hadn’t let it get that bad since that round of organizing, but I did ask for help from Daughter #2 in May, to buy some bins and drawers to continue my never-ending attempts to stay organized.

The past 8 months, I’ve traveled about half time and finished a book. Either of those events means my surface organization goes downhill, but my office was not a disaster. (Mark disagrees with my assessment. Wednesday, Daughter #2 and I attacked the part of my office I had not yet organized: my desk and a bookshelf of supplies I use frequently. (The bins and drawers for the travel and workshop material was working quite well. I’d updated and refined that over the last few months.)

I only had three bags of recycling. Once we bought some bins, I could organize the pens, stickies, and pads I use, so now everything has a place.

There is no way I could have done a BDUF to really know what I needed or how to organize. I had to evolve my organization, based on how I work. I was willing to change some of my workflow, but not all.

When you’re developing a system in which people work, such as an office, or a kitchen, or–gasp–a software system, make sure you build in feedback-from-the-customer time. I had to live with my office to see what was working and what wasn’t. So will your customers. The result will be worth it.

Labels: agile, BDUF, implement by feature

I’ve taught several workshops where people wanted to learn how to start adopting some agile approaches. They knew about timeboxing, but didn’t quite see how to make it work. The part they were missing was having working valuable product at the end of each timebox.

I explain that to the participants, and they nod sagely. Then I ask them to do a simulation. Practicing in a workshop is a safe place to practice. If they don’t do something quite right it’s still ok. Normally this part proceeds well. Some folks have a little trouble, but most people start changing how they work by the third iteration.

At a recent workshop, things didn’t go so well. One group took five iterations to complete the first part of the project when I’d expected three iterations (when designing the simulation). But take a look at a chart of their first project’s velocity.

They couldn’t predict what they could finish–or not–in an iteration. One of the reasons they had so much trouble is that they did not implement by feature. They attempted to build the architecture first. But as soon as they started attempting features, the architecture didn’t quite work. Instead of throwing away a not-quite-right architecture at the end of iteration 2, they decided to stick with it, because of all the time they’d invested.

They had a different experience in the second project. In their first iteration, they decided to do an architectural prototype, but not deliver anything. Ok, I could live with that. They had a working architecture, and if they’d put things together, they could have been halfway done with the project. They chose to leave the first iteration as a prototype.

In planning for the second iteration, they told me (senior management), they were going to work on the prototype more. I asked what they would have to show me. It wasn’t going to be product, so I told them that was unacceptable. They didn’t plan much for that iteration, but delivered plenty. Same thing with the next two iterations.

They never did have a predictable velocity, because they were caught in the trap of pre-planned architecture instead of seeing the architecture evolve as the product grew. I asked them if this ever happened in their organizations. Predictably, it did.

This may be the most difficult idea to help people see–that they make more progress implementing the most valuable features one at a time, and letting the architecture evolve. Big Design Up Front (BDUF) slows down the project. You can’t predict what the architecture needs to be.

Labels: architecture, BDUF, implement by feature, timebox

Joshua asked me to clarify what I meant by implementing by architecture. Here’s my picture-story.

When a team implements by architecture, they tend to be functionally-based teams implementing across the architecture. See .

When a team implements by feature, they are cross-functional teams. See .

When teams implement by feature, they do what’s needed in whatever part of the architecture is needed. To the outsider, it looks a little messy–sometimes incomplete. But to the team, the architecture is cohesive. And, most importantly, the team is not writing code they won’t use.

When teams implement by architecture, they are too likely to implement more than they need–ever.

I taught my project dashboard workshop today. One of the things most people want to measure is progress towards project completion. But you can’t measure project completion progress unless you have completed features: developed, integrated, and tested features. A completed feature is done enough for someone to use.

Implementing by architecture leaves all the feature integration up in the air until the end of the project, so if you must implement by architecture, you just can’t measure completion until the end. That’s too risky for me. But if you implement by feature, you can start measuring completion as soon as you’ve implemented one feature.

I’ve been working with some companies who do hardware/software systems. Most often, they have some embedded code too, just to make life interesting. To be honest, I don’t know how to do implementation by feature for a whole brand new system. Here’s what I’ve been suggesting:

• Prototype the software architecture as early as possible, even if it’s just one path through the architecture, even if everything isn’t set up into neat little components. Chances are good the hardware doesn’t exist yet, but if it does (even a prototype), proto the software onto the hardware and see what happens.
• Make as few components as possible. This is a variation on the KISS principle. Sometimes, it’s easy to break things down into a picture with a gazillion components, but that makes it harder to write and integrate the code.
• If you must implement by component, integrate by feature.
• Develop automated unit tests, preferably using test-driven techniques, so you really don’t write more code than you need.
• Be ready to integrate a few things at a time, so you move towards continuous integration. Whatever you do, arrange things so you’re not doing big-bang integration of the hardware, software, firmware, whatever at the end.

Do you have any suggestions/ideas? In my experience, once a system is built, it’s relatively easy to add pieces implementing by feature. But it’s much harder when defining and building a new system from scratch to implement by feature.

I taught a project management workshop earlier this week. I include a small project as part of the workshop, so participants can practice planning, organizing, and a little steering of a project in a safe setting. One of the project teams thought they were going to implement their project (a mobile), with an assembly line method. They would make all the pieces independently and then put it together.

It’s possible to do that. And the end product is not as interesting, and it’s harder to keep balanced when the project teams do that. For software projects, the results are more problems at the interfaces (the balance problem with mobiles), and too many customer responses “Well that’s what I asked for, but not what I want.” Does that ever happen to you on your projects?

Implementing by feature isn’t a panacea. It’s possible to implement several features and then realize when you try to implement the next that the architecture/design won’t allow you to add this feature. But in my experience, I’ve found that the project team determines ways to redesign and implement that seems to take less time than attempting to attempt complete architect/design at the beginning. And in my experience, teams that implement by feature are much less likely to have huge numbers of defects — especially at the interfaces.

I hope you decide to think about how to organize your implementation on your next project. There’s no right or wrong way — each project is unique and you’ll need to consider all the risks. I’m a fan of implementing by feature, to reduce the risks of defects at the interfaces and not-quite-right features. But as long as you think about it, you’ll do what you think is best for your project.

I’ve had several discussions about maintenance in the past few days. I’m beginning to think I have a different definition of maintenance than other people do :-). For me, maintenance is fixing problems in code. Maintenance is short, small, well-contained and code-based, and should be fixed by the developer(s) who created the problem.

So what happens if there’s a requirements problem that led to a design problem that led to a larger (greater than a couple of days worth of work) development problem? To me, that’s a short project. Once the problem is larger than just coding errors, it’s not maintenance, in the sense that I think about it. If you have to rewrite requirements or fix the design or involve more than just the one or two authors, it’s bigger than “maintenance”. And once it’s a small project, I can manage it with all the other small projects that are part of a release.

This means that when I work on projects, I see the work differently than others seem to. Because I believe everyone has to fix the problems they created, and because I see maintenance as just fixing those problems, I don’t have a problem with maintenance. I do have a problem with scope creep, but not in the sense of new requirements. I have a problem with trying to finish the work the project staff said was already done but isn’t.

That’s why I ask people to plan inch-pebbles, why I use milestone criteria, why I ask developers to implement by slice instead of by architecture, why I request that technical staff completely finish one thing before they go on to another. A by-product is that I don’t normally have to deal with maintenance, unless I’m coming into a project after it’s already started.

What’s your definition of maintenance?

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.