Managing Product Development

In one of the comments, for When is a Scrum Master (or a PM) Not?, Craig Brown said

Process, process, process.

What about people? At the end of the day the process is just one of several enabers (alongside culture, technology and tools, etc.)

Won’t an experienced and talented team just deliver regardless of the process? ANd doesn’t that indicate that the process is relatively unimportant?

Well, yes, if you have “experienced and talented” people, they will manage to deliver just about regardless of the process. My experiences over the last couple of months lead me to believe these folks don’t have the experience. They may well have the talent, but not the experience, or the self esteem to do what they know they need to do.

One of the reasons the XP folks are so adamant about their practices is because the practices create a system (a process, if you will) that helps people accomplish the work. We Tried Baseball and It Didn’t Work is a humorous take on what happens if you say you’re playing baseball, but don’t follow the process. Same thing with XP, Scrum, or cleanroom or anything else you choose to do. If you don’t follow the process, it doesn’t help. You can call it anything you want, but calling it Scrum (or something else) doesn’t make it so.

So what do you do with an inexperienced team? (Let’s assume they are talented.) I still think someone needs to help with the process, so the team gains experience and succeeds. Without the willingness of someone to stand up and say, “No, that’s not the way this is supposed to work. And, here’s why…” the team cannot be successful.

I’ve met process police, and no, I don’t want to work with them. But a little process does go a long way when organizing or managing a project. If I want to use timeboxes because otherwise people fall prey to Student Syndrome, I should have that option. It’s quite reasonable to want an iteration backlog before an iteration starts, so the team can estimate it and commit to it. It’s not reasonable for a person who’s not developing or estimating to lengthen the timeboxes and reject retrospectives because he doesn’t think it will help the team. The people who reject the agreed-upon process are not helping the team, even though they think they are.

Leaders, no matter what they are called, are the people who guide the team through it’s designated process. They are especially necessary when the team is inexperienced, whether that’s general inexperience or inexperience with a particular project organization.

I have an opportunity to review process documentation (actual and proposed) from many organizations. I admit, I have a prejudice for more Agile techniques (integrated into any lifecycle). But non-Agile techniques work too.

Here’s what I find doesn’t work: making the process dependent on the personalities of the people who have to carry out the process. One of the reasons a waterfall or phase-gate lifecycle more often fails than succeeds is because it’s dependent on the project manager policing the people on the project to perform all the paperwork deliverables. Now, these documents may well be valuable during the project. But as soon as the perceived schedule pressure becomes too great, the technical staff stops producing useful documentation. They may spend time on the docs, but they don’t serve the intent of the docs. Same thing with reviews (design reviews, code reviews, any review).

The process has to be independent of the people. Reasonable and capable people should be able to use the process to push back on unreasonable schedules–or explain why they won’t use the defined process. If the process pushes staff to stop using the process in the face of schedule pressure, depending on one person, the PM, to push back on management or the sponsor, the process is doomed. As soon as management pushes the crazy schedule button, the process goes out the window.

If you’re a process person, make sure the process you define is robust in the face of schedule pressure, and does not require one lone person to stand up for the project team, but allows the project team to stand up for itself.

Yesterday, I was talking to a colleague about a new job he’s considering. It’s in a regulated industry, and he had some assumptions: that regulated industry auditors assume a waterfall lifecycle and that organizations require process people to improve the process.

Regulated industries do not require a waterfall lifecycle. What they do require is that you show requirements traceability from the beginning of your work through the testing. They want to know you didn’t add anything more than what you said would be in the product, and they want to know you tested what you said was going to be in the product. You can do that with any lifecycle. Some of us would say you can do this better with an agile lifecycle (There’s more that regulated industries want, but requirements traceability is huge piece of their process issues.)

But I found his other question more disconcerting. The more I work with people who try to change things, the more I’m certain that process people who are divorced from the everyday stresses of product development is wrong. The managers have to be responsible for process improvement, or it’s just another management fad.

I’ve seen process people used effectively in organizations when they act as internal auditors, who can explain where the current process isn’t working, and as experts who can explain how to make the process better. But the people who own the process are the people who live and work the process — not the process experts. Assigning some percentage of the product development team as full-time process improvement specialists cheats the team out of the domain expertise these people have — domain expertise that would be helpful in product development. And, if you have full-time process people who don’t have domain expertise, why do you think they could help you in your product development?

I loaned out my copy, but Capers Jones in Software Assessments, Benchmarks, and Best Practices, (page 133), says that reuse, ability to manage, and ability understand the domain are the three most important factors in software product development. The factors are something like 300 for reuse, 85 for management and 75-80 for domain expertise. Process is down around 30-40 as a factor for successful product development.

If you want a process that will meet regulator’s needs, understand how you obtain requirements and how you use them all the way through your projects. Use experts and internal auditors to help you assess how well you do what you say you’re going to do. Measure what you do and see if that’s where you want to be. Make sure each manager has process improvement goals that benefit the entire organization, not local benefits. That’s the way to do real process improvement. Not with an army of process people.

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.

I was extremely fortunate in my choice of companies and work early in my career. I developed in assembly language and microcode and Fortran for a few years. Then, I moved to object oriented languages, primarily at Symbolics, using LISP.

At Symbolics (I left in 1990), we practiced incremental development, iterative planning, and some forms of pair programming. Why? Because the language, LISP, encourages this. It’s easy to make small changes. It’s easy to take what you have and try something. It’s easy to walk someone through small functions and then have that person explain what else you could do. It’s easy to grab someone and show them what you have already working, even if other parts don’t work yet.

I’m not a LISP expert, certainly not the way I was an assembly language or microcode or Fortran or MAGIC/L expert. I became sufficiently fluent in LISP to write pretty good tests. It took me a long time to get past linear thinking in LISP.

But once I figured out the basics of writing software in LISP, I became a much better project manager. I understood how easy it was to break things into small pieces and write products from the bottom up, rather than the top down. I understood how the engineers needed time to experiment. I could help them timebox their prototype activities. Even though I wasn’t a LISP expert, I could use my knowledge of the environment to help the engineers create a product development process that worked.

If you’re not happy with your projects, look at the language and environment you use. Maybe LISP isn’t the answer for you. But you can create an environment that creates a helpful process — one that allows the technical staff to create small pieces, test them, and build on them. We know that successful software development occurs when we build small pieces from the bottom up and check those pieces with the customers. Make your project environment help your technical staff create successful products.

I use the CMM in my work. The CMM/CMMI is a wonderful collection of key process areas. Every product development environment can use many of the key process areas to improve their work. The keyword in that sentence is *many*, not all.

When companies aim for a particular level of the CMM/CMMI, they do themselves a disservice. By aiming for a level, they say that all the key process areas at one level are equally important. But what’s most important is not the level, but the mastery of the appropriate key process areas.

For example, a key process area in Level 3 is risk management. As you know, risk management is necessary for successful project management. In fact, I could argue that many organizations at Level 1 have mastered a form risk management, albeit in a people- and company-destructive way.

Here’s hypothetical example: A company with great project management processes including risk management whose project managers and technical staff are savvy enough to recognize that their lifecycle and practices need to change on each project. They have an incredible test group. They don’t perform formal QA, their requirements are bullets in email (a step up from napkins), they don’t track anything other than defects. They’re somewhere between level 2 and 3.

Here’s what matters: they work. Their projects work. They ship product on time. The customers, the compay, and the technical staff are happy. Their customers don’t find egregious defects. Their process works. They have mastered the few process areas they need now. As they grow, especially as they bring more people into product development, they will need to reconsider how they define and manage requirements, what they measure, and how the developers review their work. They will increase their mastery of the next process areas that matter.

When you plan and perform process improvement, especially if you don’t have a contractual need to show a certain level, work for mastery. Define which key process areas are strategically important to you *now*, and master those.

Levels are like grades - they show some part of what you know. But what’s most important is how you apply the knowledge behind those grades - the mastery.