Managing Product Development

If you haven’t read Joel Spolsky’s entry on office architecture stop and read that first. Finally, an office in which people can successfully work alone andwith other people — and who don’t have to worry about keeping their voices down. I’m amazed at the space per person (425 sq. ft if I understood). Most offices give people 80-100 sq. ft. My home office is 22×14, 308 sq. ft. I have room to spread out my various current projects, room to meet with one or two people, room for a flip chart and of course all the machinery I need. The offices must feel palatial to the people at Fog Creek.

What Joel describes is requirements starting with the users. Notice that he doesn’t separate functional requirements from non-functional requirements. What people call non-functional requirements are the attributes of the system that make it usable — or not. When you start with the users, and describe requirements holistically as Joel did, (well, ok, he has some design, such as “offices with doors”), you describe what makes the system (in this case, the offices) usable.

Esther and I are teaching consulting skills to architects this week. We have a variety of simulations as part of the workshop, and we’ve noticed that great architects act in certain ways:

• Great architects look for multiple alternatives to explore.
• Great architects look for how the user claims to want to use the system, and continue to probe on currently-visible extensions for how people may want to use the system in the future.
• Great architects discover the primary system attributes that will drive the system and build on that. One architect described this as building from the inside out.

The primary system attribute, what other people call a non-functional requirement, is often unclear. For our simulations, the attribute was the ability to support a physical load. For software systems, it can be some aspect of performance, reliability, security — or some combination. Here’s an example. Our telephone systems in the USA are build around a primary system attribute: the system will have uptime of greater than 99.999% over the course of a year. (The telco requirements are probably higher than that, but it’s a lot of 9s after the decimal.) That means that you can virtually always pick up a land-line phone and get a dial tone. That requirement drove the architecture of the telephone systems, both for each central office and all the interconnections.

If you find that primary attribute, or the combination of attributes, the system architecture alternatives appear — to me it looks as if they become clear to architects by magic.

The lesson I’m taking away this week is that if you want a coherent architecture, it’s more important to discover the primary system attributes rather than all the functional requirements. No matter how you approach requirements, make sure you take a holistic approach. Don’t use techniques that separate functional and non-functional requirements. If you do, you won’t see the architecture emerge.

Tweet This Post 

I’m a big fan of managers admitting their mistakes. (It’s one of the lessons I learned early as a manager.) I take that seriously, seriously enough that when someone found a glaring error in my last SD column, Future Fixes, I asked the editor let me publish a correction and I sent in replacement text for the article.

If you read the article and get to the part labeled “Critical Chain,” stop right there. Jump over that part and wait for the updated version to be posted online. (As of the time I published this post, the article was not updated.) The updated page will have a part called “Manage Your Buffers.” What I described originally has nothing to do with critical chain. If you’re looking for great information on critical chain, go to Frank Patrick’s site, a mother-lode of information.

I feel stupid and dismayed. On the other hand, I’m very glad I have a chance to fix the article and apologize to the readers. I would feel even more dismayed if I hadn’t discovered the error and had a chance to fix it.

Tweet This Post 

Last week at the Software Development conference, I met a software director. His group, a total of about 30-40 people (I’ve forgotten the exact number) is responsible for all the software his company produces. He has two managers managing those folks. He’s busy, so although he requests that his managers have one-on-ones with their staff, he doesn’t keep his one-on-ones with his two managers.

After my lessons learned presentation, he came up to me and told me I was right, that one-on-ones are necessary. And now that he’s canceled his one-on-ones with his managers so often, they ignore the times he thinks he’s set aside for their one-on-ones. Since this was Thursday, the last day of the conference, I asked him if he was going to have one-on-ones on Friday when he went back to work. He sighed and said that since he was off for a two-week trip to Asia, he’d wanted to stay home and take care of his life for a day. Can’t say I blame him.

However, he’s noticed a problem in his department. This director’s managers no longer trust him to have one-on-ones. They don’t even bother to come to his office when it is one-on-one time. The directors is allowing his managers to run open-loop, without feedback on their decisions or performance. The director doesn’t know anything about the value of his managers’ work. And when it comes time for performance evaluations, the director and the managers may all be surprised if the director is unhappy with some aspect of their work.

Managers leverage the work of other people. When managers make mistakes, the mistakes are magnified through the other people’s work. The answer isn’t to make fewer decisions, but to obtain more feedback on those decisions. If you manage managers, make sure you maintain your one-on-one schedule with your staff. They need feedback as much as the technical staff do. Maybe more.

In case you’re wondering, I suggested the director have a phone one-on-one with each of his managers and to ask them for help scheduling one-on-ones when he returns from his trip.

Tweet This Post 

First read Esther’s entry about the Secrets of Motivation for some great pointers on not demotivating people. If you’re having a cynical day or need a chuckle go to Despair.com.

At dinner last night, some friends were talking about motivational posters — and we all laughed. One colleague told me about these sarcastic motivational posters, and that he’d visited a company who bought them and used them as motivational posters. Their thinking was the posters would remind them what not to do. His favorite was Blame.

Laugh, and then determine if you slip into any of the attitudes. If you are, you’ll know what not to do.

Tweet This Post 

Hal asks a fascinating question in Variation is an Enemy Enabler of Project Success: How can we take advantage of serendipity rather than forcing an outcome in our projects? (paraphrased)

One technique is to observe and listen to the project. When PMs observe their projects, they look at and listen to:

• How people work together. Are they talking? Peer reviewing? Pair-working? Any other technique for informal communication and information sharing? We can take more advantage of serendipity when people collect the bits of information about other areas of the project.
• How project meetings flow. Do people want to attend? If not, what would make the meeting more useful? If people feel free to discuss their obstacles, other people might have techniques for overcoming those obstacles.
• Daily progress. Are people making some form of progress every day? Even if the progress is learning about the project, not deliverables, the project team needs to make progress every day.
• Effects of multi-tasking or long hours. Multi-tasking extends the project duration (if you don’t believe me, look at Frank Patrick’s blog), and long hours makes people stupid.

There’s more, but it’s eluding me now. I’ll add more when I can remember.

I take advantage of the serendipity with one-on-ones, project team meetings, MBWAL (management by walking around and listening), lunch with the project team (or others), anything that gets me out of my office to observe and listen to the project.

Tweet This Post 

I was reading David Anderson’s Working Smarter Not Harder and thought about managers. David’s right, a few small improvements can dramatically increase a team’s productivity and therefore lower the cost of development. But I contend that most of the productivity costs in software is the way we mismanage software projects. If managers worked smarter, they would:

• Assign people to only one #1 priority task at a time
• Assign people to only one project at a time
• Create opportunities for people to work together, to build review into the product development process
• Ask about obstacles
• Clear those obstacles

I’m convinced that the reasons outsourcing works is that it forces organizations to document requirements and the outsourcers work on only one project at a time. The outsourcers’ management can then choose any number of useful product development practices that increase the outsourcers’ productivity. Management can’t change their minds and refocus the outsourced project(s) in the same way they feel free to refocus the internal projects.

Tweet This Post