A survey does not take your context into account. Surveys about any practices without considering the industry, the products, and the management don’t tell you much. People lie to themselves about what they are really doing. And, they can harm efforts underway.

A senior manager saw a survey like this. He asked me what timeboxing was. I explained. Now he thought timeboxing was the best thing since sliced bread. He decreed that from now on, all projects would be timeboxed to no more than eight (8) weeks. The fact that some of the teams were using two week timeboxes and some were using straight kanban (not inside timeboxes) to finish valuable work was irrelevant to him. When I explained about the value of shorter timeboxes, he told me I was nuts. (I am, but not about that!) After all, he didn’t have any projects he could finish in 8 weeks, so how could anyone else? Not all senior managers are that clueless. But too many are.

How about the Scrum Master who, in response to a survey including questions about retrospectives, responded that they always did one. Their retrospectives lasted 20 minutes for a 4-week iteration, and consisted of a form: What went well (+), what wasn’t so hot (-), and what should change (Δ)? There were no action items, no adaptation based on reality. But he got a raise because he answered the survey in a way management wanted.

I don’t buy the survey or online assessments. You want to know what’s working for you? Learn how to lead a real retrospective. Then do one. (Or hire Esther or me :-) Get a real assessment.

These two examples are egregious examples of what can go wrong with surveys. They occur because there is no data to back them up. Does it matter if people exxagerate? Does it matter if management interprets something incorrectly and makes invalid assumptions? It doesn’t matter if you don’t care what everyone else does. But if you care, it matters. A lot.

As a very famous person said, What Do You Care What Other People Think? I would rather know what my context and reality are, what my particular constraints and issues are, and work in the best way I can to manage those constraints and issues.

rant off.

Jurgen, I may owe you, not the other way around!

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.

We’re getting ready for my parents’ 50th wedding anniversary, and my sister decided a scrapbook of family pictures would be a great present. She’s right, it will be wonderful. Mark and I were looking for pictures of us and our children, so we pulled out all of the pictures from the last 20 years. We have great pictures of us before we had children. We have great pictures of the girls with me. We have terrible pictures of Mark and the girls. Why? Because I took them. Some pictures are fuzzy. Some have heads, arms, feet cut off. My favorite is the one of Mark with one child – both people are so fuzzy I can’t tell which child it is and we can only see Mark from his glasses on down. I laughed so hard I cried. We found some pictures of Mark and the girls we can use, so we finished the necessary picture-finding task. But that got me thinking about my picture-taking ability. With film cameras, the feedback I receive on my picture-taking is significantly delayed, so I don’t yet know how to take good pictures. I’m better with an instant-film camera, but I’m hoping a digital camera will teach me to take better pictures. (When I told Mark this, he chortled and told me I was just competing with him for toys. :-)

So what does this amusing anecdote have to do with product development? Everything. The further delayed your feedback is from performing the work, the less you can change about the way you perform your work. If you’re a developer, and you discover problems in your code only once the product is in system test, you don’t have feedback on the design or the implementation early enough to change how you design or code. If you’re a project manager, your decisions at the beginning of the project have a tremendous impact on the end of the project, but unless you set up systems to obtain feedback, you can’t know which decisions had what kind of impact.

No matter what your role is on your project, think about ways you can obtain feedback on your work as quickly as possible.

• Ask for peer review.
• Offer walkthroughs.
• Use the rule of three: what three things can go wrong with this design/test/project plan/whatever it is that you’re working on.
• Look for unanticipated side effects of decisions. (Especially if you’ve started some new measurement to go along with the decisions.)

I’m sure there are more possibilities than these, but the key is to be open to feedback from other people about your work product. The more immediate the feedback, the more likely you are to improve your work product. The more delayed the feedback, the fewer alternatives you see and the more costly the changes are.

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.