A Business Technology Place

Attacking process waste

I don’t like process waste.

Who does? But how many of us really try to change processes to eliminate or reduce waste? In my experience this is a tough topic, and I dare say an unwelcome one, most of the time. The problem is that in an organization processes are tied to job existence and security. So the people in charge of setting the processes and administering them really don’t see the incentive to make adjustments.

I’m nearing my 20th year of software development experience, so I’ve observed and talked to many practitioners about software development process philosophies and techniques. Process waste starts to build when the people within the organizations place more importance on the process steps (requirements, estimates, and schedules) instead of the process output. The ultimate goal of software development is to make money by producing output. Waste takes away from the output.

Business case modeling and estimates are a common area for waste.

Let me start by saying that business case modeling and estimates are a necessary part of software development. The problem arises when the business case and estimates begin to consume a large percentage of the organizations time and a large percentage of the work is rejected. All of the work becomes throw-away because it has not created a return. Ironically the entire point of the business case is to prevent waste. We don’t want our organizations to produce product that does not yield a financial return.

Think about it. If the software development team is constantly estimating and scoping projects that are not approved then it reduces the amount of usable output created for the business.

The theory of constraints is a critical teaching to understand.

The Wikipedia entry for the Theory of constraints quotes Eliyahu Goldratt.

The underlying premise of theory of constraints is that organizations can be measured and controlled by variations on three measures: throughput, operational expense, and inventory. Throughput is the rate at which the system generates money through sales. Inventory is all the money that the system has invested in purchasing things which it intends to sell. Operational expense is all the money the system spends in order to turn inventory into throughput.

In a perfect world, everything the software development team touches is processed into work output that generates money. We don’t live in a perfect world, but we do want the throughput of the system to be optimized. So it should produce money making output as quickly as possible. Work that is started and later thrown out is like throwing away inventory and only increases the overall operational expense of what it takes to get good output.

You have to work the constraint.

I’m a strong advocate that software development needs to focus on features, not projects. Projects are by definition unequal in size and length. Features are smaller in size, easier to understand, quicker to estimate and assist with providing more consistent system output. Bloated projects tend to have large price tags, take weeks to estimate, and are more likely to be rejected by management.

Think about the project approach. A team may spend two weeks creating a business case to review with management. Then the development team spends another two weeks estimating umpteen features. If the project is rejected then there is four weeks of effort that creates $0 of sellable output. The exercise devolves into a discussion about a single cost to build and the the time required to do so. It’s all or nothing and the focus on the goal of making sellable output is lost.

So if we want to work this particular constraint in the system then we need to evaluate each feature on its ability to achieve the end goal. Everything else is really just noise waste.  I hate waste.

Software Release Management. It’s more than an IT thing.

This is about IT and Business alignment.
I’m fortunate enough to have worked in two different functional areas of a business: IT and Marketing. I can say with 100% confidence that business owners and stakeholders of software releases should be more concerned and involved in the IT release management process. The typical release process covers areas such as requirements specification, feature prioritization, business case modeling, and go-live deployment communication. It’s a set of tasks intended to oversee the requirements, development, testing, and deployment of software releases. Sounds very IT, but it should be a shared business process.

Release management is about adding value.
Release Management is also about how IT and business owners engage in communication that benefits the stakeholders and customers of the business. A business owner could be the CFO, CMO, product manager, finance manager, procurement agent, etc. It’s someone who champions and justifies the contents of a release. An engaged business owner has a chance to more positively influence the results of the release.

I’m not saying they need to know all the details of the software development cycle. I am saying they need to help with defining the process such that it maximizes the potential of the organization. One of the key traits of a successful leader is making success achievable by others. They can do this in the software development cycle by making sure that the process is free of unnecessary work and is efficient in how often work is output.

Mike Sutton and Tym Moore provide a great list of practical ways to improve software release management for CIO.com One key point of Sutton and Moore is that establishing a regular release cycle is vital because:

  • It creates a predictable timetable for when stakeholders can expect to receive functionality. This creates confidence and allows the team to focus more on the content of the release.
  • It creates a routine for all functional teams to align their efforts.
  • It gives clients confidence that your business is regularly delivering new value to the marketplace.

Think features, not projects.
Here’s the rub. To get to regular release cycles (such as every six weeks), your software development process needs to focus on delivering features of work rather than projects of work. Projects by definition have a variable level of scope which means that delivery dates will also be variable. Content for regulatory requirements, compliance issues, new features, or defect fixes are easier to deliver when they split into several smaller units of work effort. It’s a similar the concept of memorizing larger lists by “chunking” the list into smaller groups.

That’s a paradigm shift for many traditional project organizations. But it’s a way to encourage lightweight processes and focus more on delivering value to the client quicker. Salesforce.com discusses release cycles that were becoming longer and delivering less before they turned to a process focused on smaller and regular releases. They saw an immediate increase in the number of features delivered per team and a reduction in the days between releases. Amazon.com, the largest online retailer, also uses regular release cycles.

At then end of the day it’s about efficiency and work output.
Automated machinery is installed on plant production floors for this very reason. The machines produce units of output at predefined intervals. This maximizes value to the business and clients. Our software release output should aim to be the same way. It’s definitely more than an IT thing. It’s just good business.

Urgency is a two-face

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?

Process: friend and foe

In my reading this week I came across a blog post from Tom Peters entitled Strategy: War on Systems. Tom talks about “systems” within an organization and while they are developed with good intentions, they often become inhibitors to achieving the organizational mission. I talk about this very subject quite a bit on my blog also. In fact while reviewing my notes for blog post ideas I found this entry:

“Software Development lessons learned (process is both friend and foe) – Software development friend and foe”.

This thought matches exactly with Tom’s thought about war on systems. Your software development process has steps that exist to produce output and serve customers. Over time, the process becomes more elaborate. Steps are added to prevent faults that happened in the past, to satisfy regulatory requirements, to satisfy best practices, or even recommendations from a consultant. As Tom put it, this type of system or process can “strangle” the organization. It becomes a priority just to follow the process and team members lose site of the original mission. Team members become process engineers as they navigate the process from end-to-end and feel accomplished when they can check-off each step completed.

It’s a safe bet to say that end customer rarely has influence into the design of the process. Ultimately, the customer has to buy the output and no one else.  So make sure your people have the ability to call-out and question process steps that don’t provide value for the customer. This is a big step for an organization that wants to increase its customer focus.

Beware Bloated Processes

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.


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?