Image source: https://flic.kr/p/9TJPp3, Creative Commons License

Technical optimization projects are part of our daily business in software development. Additionally, with time cockpit we are often involved in projects for optimizing team performance and productivity. In this blog article I would like to summarize my learnings about what differentiates successful optimization projects from failures.

Content

• Technical vs. Organizational Optimization
• Optimization Anti-Patterns
• Blueprint for Successful Optimization Projects

Technical vs. Organizational Optimization

As a software company, we regularly optimize our products. We try to optimize resource usage (e.g. CPU, memory) so that existing functionality performs better or new functions become possible without the needs of a faster computer. As we offer consulting too, customers often hire us to take a look at their software products performancewise. Over the years we have developed a process and toolset for such projects.

In the last few years, a side effect from selling and implementing time cockpit was that I have been doing lots of organizational work with companies. I helped introducing the agile approach and Scrum, I worked with customers who wanted to streamline their support processes, I tried to help development teams become more productive, etc.

Over time, I recognized that the basic principles, best, and worst practices of optimization projects are quite similar in technical and organizational projects.

Let's start by looking at typical anti-patterns for optimization projects. Avoid them if you want your optimization project to succeed. Next, I will describe the foundations of our process for optimization.

Eight Typical Optimization Anti-Patterns

1. Optimize During Initial Development

In software development, people often try to write the most optimal code from the beginning. They write some fancy multi-threaded or async algorithms instead of the simple, sequential alternative. I have seen similar things for business processes, too. Instead of starting with a simple, straight-forward version of a business process, teams are coming up with complex, seemingly optimized versions of the process that covers every tiny exception they can think of.

My advice: Implement the obvious process first. Performance problems are likely where you don't expect them so optimization should come afterwards.

Don't get me wrong. I am not arguing for naïve implementations. Of course you should add obvious optimizations immediately. However, everything else should be optimized later.

2. Optimize Without Measuring

Measuring is super important in optimization projects. In technical and in organizational projects, it is common that people assume inefficiencies at the wrong places. They simply follow their gut feelings or their HiPPO. Expensive changes to processes or programs puff out without positive effects or make the inefficiencies even worse.

My advice: Quantify your process first (e.g. how often is something executed, how long do process steps really take). Based on that, identify the aspects where optimizations will have the greatest effect.

In software development, we use profilers (we use for example redgate ANTS profiler for .NET) for measuring our software. They tell us execution counts, executing times, waiting times, memory usage, etc. For business processes you will probably also need software products (e.g. workflow engines like Prologics FireStart), time tracking systems like time cockpit, customer service software like Zendesk, etc.) for gaining deeper understanding of inefficiencies. They can collect data about processes in databases. You can then define suitable performance KPIs and calculate them based on the collected data.

3. Non-Representative Environments

This one is related to the previous pattern. Many people measure in non-representative environments (e.g. workflow that is seldom executed in practice, data from a team that has a unique way of working, etc.). The results are expensive enhancement projects with little or no practical relevance.

My advice: Use real-world data to identify frequent use cases and workflows. Measure and optimize them first to get the most for business value from your optimization projects.

This advice seems obvious but in reality I have seen many teams that do not know what the typical cases are from their customers' perspective. Like in the previous pattern: Replace gut feeling and HiPPO with data.

4. Optimize Without a Baseline

In practice, we often make things worse when trying to optimize something. We regularly underestimate the things we don't know and we overestimate our expertise. So how do you know if a certain change that you did to a business process or a software program was a good idea? You need to know the baseline from where you were coming from.

My advice: Gather performance data from a customer's point of view before you change something. Repeat the measurement after the change. Value the change based on the quantifiable enhancements you made.

I want to emphasize the advice to measure from a customer's point of view. If your optimization made things better internally but customer experience got worse, you should rethink your changes. Sometimes it is hard to come up with a setting that allows you to get comparable measurements before and after process changes. Nevertheless, spend time to think of a setting that enables this comparison. It is an important feedback mechanism for performance optimization.

5. Optimize Without Concrete, Quantifiable Goals

Customers and stakeholders are often quite vague when complaining about inefficiencies or performance problems. Let's look at examples:

• "Your software feels sluggish"
  
• "Your support process sucks, it takes forever until I get answers"
  
• "We don't like to work with your software, it is too slow"
• "We have to wait forever until we get fixes for bugs we report. Your bug fixing process has to become faster."

These are very generic statements. Don't start a performance optimization project based just on such a complaint. You have to find out what specifically upsets the customers and quantify the inefficiency (e.g. how many people are affected, how severe is the problem, etc.).

My advice: Don't start to optimize before you have not defined a quantifiable goal. Define a timebox for your optimization project. If you reach the goal within the timebox, stop. If you don't reach your goal until the end of the timebox, also stop and rethink.

A quantifiable goal is also important for knowing when to stop. Otherwise you spend too much time for optimization. Over-optimization has opportunity cost. Time and money might be better invested in other areas providing value to your customers.

6. Optimize Without Knowing the Basics

As a software engineer, I really have to know the platform I am working on otherwise I will not be able to perform a successful optimization project. In my opinion the same is true for business process optimization. If you do not know the domain, understand the basic parameters, know the typical gotchas, etc. you are not the right person for the optimization job.

My advice: Make sure you have done your homework and you know the basics before you start an optimization project. If you don't, get (internal or external) help.

7. Optimize Everything at Once

First, remember the pareto principle: 80% of the effects come from 20% of the causes. If you have never done an optimization project in a certain area before, it is likely that you will celebrate big success in a short time. However, the more you optimized, the harder and more expensive it will be to achieve impressive results.

My advice: Make positive use of the pareto principle and catch the quick wins by optimizing at least a bit. Question the tendency to reach perfection in terms of performance. This would be very expensive.

Second, don't make too many changes at the same time before measuring again. If you change five things, how do you know if four worked great and one made the entire project seem to have not caused any effect?

My advice: Make small changes, assess you change by measuring, introduce the next change.

8. Confuse Performance with User Experience

We often try to make things faster and faster while we forget about user experience. Sometimes customers are perfectly fine with waiting a reasonable amount of time if they know that their request is being worked on and they get feedback.

My advice: Sometimes improving user experience can provide more short-term value than long-term optimization of a process.

Blueprint for Successful Optimization Projects

Now we have seen some anti-patterns to avoid. But how would a good optimization project look like? Optimization projects that we do follow an eight-step process:

1. Plan for it
   

   Speaking in Scrum terminology: Put it on your project backlog. Get a (time) budget for it (time-boxing) by working out a business case for your optimization project. Don't forget to make yourself familiar with the necessary (software) tools.

2. Prepare a defined, reproducible test scenario/environment
   In a technical optimization project this would contain things like hardware/software environment, test data, application scenarios, etc. In organizational optimization projects this would be the selection or definition of the process/scenario that you want to optimize.

3. Measure performance baseline
   Do this before you change anything. Examples: CPU%, memory footprint, throughput, response times, etc.

4. Define quantifiable performance goals
   Don't forget to involve stakeholders (e.g. product owners, customers, partners, etc.).

5. Start a repetitive cycle of optimizing, measuring, and analyzing
   Avoid the anti-patterns mentioned above. After each change, compare the measurement results to your baseline. If you decide to keep the change, the latest measurement results become the new benchmark.

6. Ask for feedback in real-world environments
   Your measurements might be correct but your changes have to pass the reality check (e.g. friendly customers, testing team, external testers, etc.).

7. Document and present your work
   Make sure you share your findings and changes with colleagues, partners, etc. so they can avoid inefficiencies right from the beginning. You might change internal checklists, system requirements, guidelines, etc.

8. Put it into action
   If you have only done changes in a more or less isolated test environment, make sure they make it into real life. Try to put your changes into production as soon as possible so customers benefit from optimization results.

What is Your Opinion and Experience?

I would love to hear your opinions and experiences. Please use the discussion area below so that everybody can participate in the discussion. Looking forward to hearing from you.

comments powered by Disqus