A Business Technology Place

Tag Archives: process steps

Repeating software processes. To attract and repel.

Posted on Posted in Agile Organization, Business Process Management, eCommerce Leave a comment

Are we attracted to repetition?

Yes.  We all are. It touches every facet of our lives. As a few examples, we eat the same types of foods each week, we watch the same TV series, and we read books that belong to a series. A study and report from Alix Spiegel of NPR captures the power of repetition in music that attracts us. Spiegel reports that “90 percent of the music we listen to is music we’ve heard before. We return again and again to our favorite songs, listening over and over to the same musical riffs, which themselves repeat over and over inside the music..” She then gives the result of a study that shows how people preferred music with repetition over the same song without repetition.

Repetition in Software Development.

Software development has the same draw for repetition. Managers spend time and thought to create a software development lifecycle (SDLC) that fits their company culture and team skill sets. They want something repeatable to drive efficiencies of a process, consistency of work output, and reliability of estimates. These are the attractiven features of a SDLC.

There’s an entire business industry built on repetition in software development. Books, training, and consultants feed us new ideas and different ways to think. But the end game they seek is adoption to a standard method that works within the framework of our business culture. This is all for good reason. As a professional in the world of software development, I recognize that we must be disciplined. I recognize that we have to think and find more efficient ways to produce software so that we can stay competitive and drive results through the business.

But there is a repelling force to repetition as well.

There are two danger zones that software managers should consider with repetition in process. Both of these creep-in an organization silently. Ironically they destroy the very things that repetitive process can build.

  1. Repetition can stagnate creativity. When we follow a script, we don’t think much about the ‘why’. We don’t think about better ways to do things. We just follow the process because someone already did all that thinking. Worst of all is that we don’t see it. We think we are accomplishing our job because we followed the steps.
  2. Repetition can become the end goal. When checking the boxes on the process flow becomes more important than the final product then the process has become the master. If employees are consumed with following every detail of a process and only satisfied when they mark steps as complete then the process has become larger than the importance of the end result. You’ll recognize this in an organization when the meetings about the process outnumber the meetings about the solution, the who, and the why.

Watch for it!

Watch for it in your organization and life. It’s like two magnets with forces that attract and repel. We have to find a way to both pursue and guard against the powers of repetition in the workplace. This means constant examination. It means living with shades of gray within process. It means we need write with a pencil, allowing for a both a sharp and dull point. The eraser is nice to have also.  🙂

 

 

Urgency is a two-face

Posted on Posted in Agile Organization, Business Process Management Leave a comment

What’s the goal of your organization?
Do this. Ask executives in your business what the goal of the business is. Is it to make market leading products and services? Is it to make and serve customers? Or is it really to make money?

Eliyahu M. Goldratt writes in his book “The Goal” that the goal of the organization “is to increase net profit, while simultaneously increasing both ROI and cash flow, and that’s the equivalent of saying the goal is to make money.”

The business may be about making a particular product or service. But the root goal is to supply money to its stakeholders and employees.

Is there an urgency within the organization to make money?
The farther you go up in the organizational chart the more you’ll find an urgency for making money. It’s sensible, because the higher the position the more responsibility it has for delivering results. Delivering financial results is directly correlated to keeping a job.

Yet you won’t find this same urgency in the lowest ranking levels of the organization. Those at the bottom of the organization are tasked with following procedures, gaining approvals, and struggling against organizational entropy. The processes we make, though well intentioned, often become the focus and goal of the rank-and-file. Getting through the day is not about making money, but about getting an approval and checking a box.

Urgency and bloated processes clash.
Let’s face it. Processes, by nature, grow with the aim of filling something that is missing. When something goes wrong human nature is to insert a new step so it doesn’t happen again. The process grows to try to cover it’s own inadequacies. Before long processes become filled with redundant and unnecessary steps. The irony is the process grows to account for exceptions and errors, but not to achieve the original goal.

Workers are rewarded for following all the steps and they soon find comfort and protection in the process. So it makes sense that the focus of the workers is on the process, not making money for the organization.

There should be an urgency to streamlining processes.
I’m not saying to abandon process and created an unstructured environment of work output. All organizations need some type of process to help create consistent work output at regular time intervals. Process is necessary. But leaders all the way up to the C-suite need to develop an urgency in keeping processes lean and focused on the goal. Help workers deliver more consistent work by making sure they are empowered and enabled to do the work efficiently.

Urgency comes from the top.
If an organization is to change it’s mindset about processes, it needs to come from the top. Management expectations do cascade downward. But if upper management is only concerned about the urgency of making money and not looking at how the organization can make it through operations, then inevitably the organization won’t make the money fast enough.

So spend some time thinking about current processes. Remove steps that don’t directly move work towards output. Remove redundant steps. Identify system bottlenecks, whether people or process, and determine how to alleviate it.

Am I missing something here? I just see big business has a big appetite for making money. But it can’t move fast enough because it trips over itself. So where is the urgency in that?

Are you hiding behind the process?

Posted on Posted in Agile Organization, Business Process Management, Customer Focus 1 Comment

Some people depend on the process for making results.
I was involved in a situation recently where a software defect was found after the production release. A team member was quick to analyze the situation and indicated that the team had not followed all the steps in the process. They stated that this resulted in increased risk and was the root cause of the defect.

Don’t be afraid to fail.
It appeared to me that their behavior was driven from a fear of failure which often results in blame. If we work in environments that place blame for failures then how do we expect people to learn and correct mistakes? How do we expect them to operate at peak efficiency if they are focused more on the consequences of failure than they are on the results of succeeding?

I talked to the team member and their manager and explained that risk of defects and failures was part of the business of software development.  The particular change that our team implemented was low risk to begin with and the defect discovered was not disruptive to the financial aspects of the site. The decision to by-pass the full process was made based on reduced risk for the change and the potential financial return.

I had a similar conversation with my son about hitting a baseball.
If a baseball hitter has a batting average of .333 (one hit in every three at bats) it’s considered great. Think about that, that means the hitter fails two times every three at bats. Now, I understand trying to compare software development to baseball is like comparing apples to oranges. But it’s not the failure rate that I’m comparing; rather it’s the mindset of failure. A baseball hitter must approach batting with mindset of hitting the ball, not a mindset of swinging to prevent missing the ball. The same holds true for the software developers and testers. They should approach their profession with a mindset solving problems, not a mindset of being afraid of creating problems (defects).

It’s really all about focus.
Focus on the goal, the prize, and solving a problem. Don’t focus on not failing. The processes that organizations define exist to establish a consistent discipline to create a product or service. Problems arise when team members place more weight on following the process than on solving the problem. Don’t let the process becomes the focus and checking-off the steps the objective. That’s hiding behind the process.

A better way is to use the process as a guide for discipline. It helps to promote communication, consistency of purpose, and above all solving the real problem.

Beware Bloated Processes

Posted on Posted in Business Process Management Leave a comment

We’ve all been there. Something goes wrong and as a follow-up we look for the root cause and how to prevent it from happening again. More times than not, we solve this procedure by adding another step to an existing process. It’s almost automatic and we don’t think twice about amending a process because we are doing this in the name of quality.

STOP.

Let’s take a minute to think a little about this.

Adding process steps can have lasting consequences. Sometimes it ends up for the good and sometimes for the worse. Process designers, stakeholders, and managers should consider the full costs before taking action.

Potential Benefits of Adding a Process Step

1.       It solves a previous problem

If you’ve had a fault or failure in a procedure then it might be because you didn’t have the proper checks and balances in place. The questions to ask in this situation is if the new step still has the aim to solve the business problem, does it contribute to the process output and can other steps be removed if the new step is added?

2.       It adds more quality to the output

A new process step can add to the overall process quality if it prevents future faults, failures, or defects. Examples of this for software development include adding test steps to exercise a certain area of the code, designing before coding, or communicating with the user how to use the product.

3.       Provides a checkpoint for approvals

Some call this a “toll” gate.  Make sure approval checkpoints are not overused and don’t involve too many people.  This is a tricky area because the checkpoints deal with human egos and emotions.  We need certain checkpoints for oversight and guidance, yet we don’t want to overburden the process with too many steps that don’t produce actual work. A question to ask yourself here is how much total time in the process is spent waiting for approvals? Are you comfortable with the answer you find?

Potential Drawbacks of Adding a Process Step

1.       It adds more time to create process output

So much of today’s business is based on speed, agility, and being nimble.  Over time, adding required steps compounds and the process may become bloated with repetitive or unnecessary steps.

2.       It adds complexity

When processes become too complex or burdensome for people to understand, they will look for ways to circumvent steps. It’s a taboo subject in the business world because leaders often don’t want to take time to perform maintenance on their processes or admit that they are a burden for the organization. An easy check for this is to see if people try to get around steps by having executives given them green lights to just do it.

3.       It doesn’t address the real reason for the process

The real reason for a process is to solve a problem or a need. It’s not to provide a basis for making sure that people do their jobs. If we are creating processes to manage people then we may have the wrong people trying to complete the process.

In all cases, remember that processes exist to solve a need. At the end of the day a business need is a transaction that is conducted between two parties where a product or service is exchanged for some form of compensation. As such, processes need to be easy to use and produce the required rate of output. So before you add a step to an existing process, make sure it helps to solve for the original problem.

Process Steps – to add or not to add?