I think it really comes down to having a proactive mindset verses a reactive mindset. If the leaders in an organization are proactive, then the organization will likely be quality-driven and budgets will be approved for planning and upfront preventative costs. If the leaders are reactive, then the organization is fine with the status quo and would rather spend money later to fix things, with the mindset that the “fixing later” is not a guaranteed cost because it might be needed or might not be needed. Thus, saving money, in the reactive leader’s mindset. What I have a difficult time understanding is how these reactive leaders choose not to see, ignore, or just don’t notice the recurring pattern and cost to the products that are consistently delivered late, defective, and having poor quality.

Please subscribe to our RSS and comment on our next post! We’d love to hear your thoughts!

POSTED BY BEN KUEHLHORN:
Reading these comments seem to invalidate the premise of this topic. People do not run away form Process. Everybody has processes through out their lives. Some processes have rule of laws and commandments. Just try to violate Configuration Management processes, Oh, the screams you will hear when the next build fails. Try to skip the copyright heading. Legal will be on your butt in no time.

So, what is the actual point in the topic? It’s formal VS informal and internal VS external processes. We don’t run away from informal processes because we are allowed to adopt parts and reject the rest. We don’t run away from internal process that we develop for ourselves. We run away from external processes imposed on us.

This means “process guys” mess up by trying to impose process.

We need to document existing processes from teams with appropriate refinements to ensure consistency, repeatability and measurements. Staff need to understand and accept our documented process. Refinements need to be fully explained for Staff to understand and accept benefits. Measurements are most difficult for Staff to accept. Managers try to use measurements to punish individuals and teams. Before we let Managers access to new measurements, we should present results to Staff for them to connect with their activities and ensure measurement actually matches the activities

Fully defined internal processes are difficult for Managers to corrupt. Staff won’t turn tail and run. These processes come from the Staff and are owned by the Staff, not Management. Staff use process to prevent Management from asking for unacceptable risky activities.

People don’t run away from Process. They run away from poor Managers with “process guys” who try to impose processes.

Tacit knowledge. Yes, it can be difficult to properly convey or communicate this knowledge to others through written or even verbal communication (or procedures). But it’s not impossible. That’s how we have the assembly line in the automobile industry. And the list goes on and on.

I also like the example you tell of a “process guy” who states that you have no process. I find that guy humorous because I think that there’s a process for everything, whether it’s formal or informal, documented or not, repeatable or not. As you stated, if you didn’t follow a (pre)defined process, but achieved a goal, in retrospect, there was a process that was followed. But it was either unknown or not communicated prior to implementing the process. But there was a process nonetheless.

Putting procedures on paper, for some reason, “formalizes” a perceived process. And that scares people. Yet, at the same time, many people desire order. Order and organization are driven by refining steps taken to achieve a goal or complete a task to make the steps efficient. Once efficient, then further refinement is taken to make the steps repeatable. Everyone does this in his or her daily routine, let alone in a work environment. By having a procedure, I’m able to shower every morning when I’m half-asleep—I’ve already honed my steps and the order in which I do them to make them efficient and repeatable, thus creating a procedure. I haven’t formally written these steps down, but I do follow these every day in relatively the same way (that was a little Dr. Suessian with the rhyming. I couldn’t help it.). I also allow wiggle room in the procedure for some slight changes, depending on the situation (to condition or not to condition? That is the question.). Alternate paths, if you will. At the end of the shower, I’ve reached my goal: I’m clean. And I followed a process that consisted of a procedure that was flexible enough to give me the right amount of direction to reach my goal without being so constricting that I was unable to alter the process, the procedure, or the steps based on my tacit knowledge as the situation required.

My main viewpoint on the word “process”—as it pertains to overall application management and delivery, not just testing—is that it need not be heavy-handed, painstakingly detailed, or involve reams of documentation, or, as you stated, to control and dominate other people (I’m picturing Cylons now…). I think that as long as the people involved with the process agree on the definition of what that process is, then, well, it’s a process. Plain and simple. Now, do I think that just because we’ve said that something is a process means that it’s a GOOD process…? Well, that’s the start of an entirely new conversation… ☺

I’ve copy-pasted a couple of replies with the author’s permission.

POSTED BY JAMES BACH:

Some of us don’t run. Some of us attack.

…Well, maybe that’s a strong word. But I think you are mis-using the word “process”, as most people do. This abuse of the word by people who (consciously or unconsciously) wish to dominate and control other people is a major reason for its bad reputation.

Another major reason is that relatively few people are nerds who read about cognitive artifacts (see Things That Make Us Smart, by Don Norman) or Situated Action Theory (see Situated Action, by Barbara Suchman) or about making tacit knowledge explicit (the field of ethnometholodogy).

Process does NOT mean procedure. If it did, then we could not talk about how things happen that do not “follow procedures.” For instance, if you talk about the process of, say, a plant growing from a seed, what you would be talking about is how things happen. You would be making a causal explanation, but not specifying a procedure. A farmer might follow a procedure, but that procedure tells us nothing about the process of how a plant actually grows.

People who are serious about understanding cognitive work must appreciate the huge role of tacit knowledge and skill which will not and mostly CANNOT be expressed in terms of defined procedures. Whenever I hear a “process” guy tell me that I have no process, I reply “since I am able to do this thing, I must have a process. It’s apparently not a process that you understand, but please, don’t conflate process with explicitly specified procedure.”

It is meaningful to say that you “follow a process” if you have a description of a process and try to make that process happen. But if you didn’t follow a process, and still accomplished a goal, then that means, by definition, that there must have been a process by which that happened.

I find it useful to use these terms:

- Process: how things actually happen
- Practice: what people actually do
- Method/Procedure/Tool: what people attempt to use to get things done
- Defined Process: A normative story about how things happen

A morning routine includes several steps to get from bed to start the day. Many steps are taken. Some have sub-steps. Measurements provide information to identify optimal steps and order steps. Tools and techniques help compete the steps.

Individuals and teams get processes from two sources: internal and external. Individuals readily accept internally generated processes. After all, these processes come from the individuals and usually effective. Externally sourced processes cause problems. Even small discrepancies from current activities become major stumbling blocks.

Effective process start with understanding current activities, tools and techniques with appropriate measurements. Management needs to establish measurement policies to understand activities and not punish individuals. Individuals appreciate measurements that show performance. Measurements change to reflect changes in activities. Individuals take ownership of processes and measurements.

For example, measuring hot water usage in the morning routine would not help optimize starting the day. Hot water usage helps being Green, but that’s not this focus. Time for each activity and overlap between activities identify opportunities to improve the process. Imposing someone’s morning process would, generally, be poor. It’s unacceptable for someone to collect and analyze the data to give me improvements. I need to understand collection and analysis to select from various improvements.

Process fails when imposed. After some resistance, people might begin to understand and accept the change when it can be clearly communicated. Any suspicion of secondary motives significantly impede acceptance.

Process can be a shield from poor management decisions by starting with current activities most developers do or accept doing. Once Developers document their current process with activities, tools, techniques and measurements, Management is left with 3 alternatives: follow the process, allow Developers to improve the process or ignore the process. The first 2 options put Developers in control. They execute an optimal process, while Management tracks the results. The last option puts poor outcomes on the broad shoulders of management. They sign off on violating the optimal process and have to answer for failure. They are less able to pass the failure onto Developers.

A well defined process provides Developers with clearly defined activities, techniques, tools and measurements. Measurements are critical to prevent Management arbitrarily dropping activities and blame Developers for failures.