Welcome to the RES Software Blog!

Who we are

RES (Renewable Energy Systems Ltd) is one of the world’s leading renewable energy companies. We develop, construct and operate wind farms, solar PV farms and energy storage systems across the globe.

As a company we are proud of our reputation as leaders in renewable energy and for demonstrating that a low carbon future is possible, affordable and desirable. The software team is a key part of this, streamlining processes and crunching numbers. Our portfolio management software makes RES more efficient and agile, and allows us to provide competitive asset management services. Our analysis software helps us find and analyse the best sites for renewable energy and to drive down the cost of borrowing from investors.

We believe that small, empowered, self-motivated teams can do big things. We believe in ideas, in aspiring to be the best that we can be, work life balance and a blameless culture based on the trust of our developers.

Not only do we love experimenting with new technology, we also create and contribute to it. We have open sourced Nimrod (https://github.com/resgroup/nimrod), an ASP.NET MVC to TypeScript converter and we have plans to do more.

How we work

We’ve organised our software development into two product teams.

The TEC (Technical, Engineering, Commercial) systems team supports the project development business. The science of predicting how much electricity a wind farm is going to produce can get pretty complicated, so we’re lucky that many of our programmers have a background in physics and engineering.

The SMART (Site Monitoring And Reporting Tool) team builds applications for the renewable energy generation business. We need to be able to answer questions like “How did this solar farm’s production in the last month compare to the budget?” or “Are any of our wind turbines experiencing problems?”

Each team is led by a product manager who works with our global stakeholders to ensure we’re focusing our valuable programmer resource on the features that will benefit the business the most. The product manager essentially fulfils the role of the product owner in Scrum, but we’ve combined it with line management of the product team.

As a product manager, I love watching the team self-organize and come up with innovative solutions to problems. I’m not a software developer (albeit an enthusiastic python programmer), so the challenge for me is to have a high level understanding of how the team is implementing things and support the use of cool new technologies that will benefit our users.

We’ve successfully used agile software development techniques for many years, but…

What is this blog about?

Across RES, departments are using a Lean problem solving technique called A3 Thinking. It’s called an A3 because the idea is to distil the problem and the solution onto a single sheet of A3 paper, but really it’s more about the thought process than the actual A3 report.

In our team, we’re focusing on two problems, each with their own A3. The first is based around improving software robustness, the second around increasing the speed at which we develop software. If you’re involved in software development in any way at all, these two problems likely sound very familiar!

One of the core principles we use in our A3s is the Plan-Do-Check-Act (PDCA) cycle:

• Plan: Define the problem, identify root causes & propose solutions.
• Do: Implement solutions
• Check: See if the solutions have solved the problem
• Act: Make further improvements based on what we’ve learnt i.e. kick off another PDCA cycle so we keep getting better!

Here are a few more details…

PLAN

An A3 starts with a group of people coming together to solve a problem. First we define what the problem is, identify its root causes, and make a plan to get from the current state to our target state. We propose a number of specific actions, and ensure that we are able to measure the impact each of these actions has. This usually means defining the current and target state using one or more metrics that tell us how close we are to solving the problem.

For example, we’ve identified that one of the issues holding us back from developing software faster is the fact that our solutions are very large. We’ve therefore chosen the number of projects per solution as one of our A3 metrics.

We aim to target low-hanging fruit first and prioritise our actions accordingly. Pareto analysis is a useful tool for this — often, we can solve 80% of the problem with 20% of the effort. The chart below shows which issues are causing outage incidents across our software applications. Clearly, bugs that aren’t caught in pre-release testing and stay unresolved for a long time are the main culprit. As a result, we’ve decided to focus on reducing the number of existing active bugs and improving our user testing procedures as a top priority.

DO

Planning is easy. Actually taking the time to implement the proposed actions when users are hounding us for a new feature or a shinier UI is difficult. Luckily, we have product managers to field those conversations and convince the users that it’s worth spending time on improving the back end of our software. For the most part, the users are very understanding. Robust software and faster development are in everyone’s best interest, right?

CHECK

Checking that our actions have the desired impact on the current state is crucial. A3 thinking challenges us to objectively assess how close we are to solving the problem, rather than relying on our gut feeling (and wishful thinking). I’m a huge data nerd, so figuring out what the best metrics are for our problem as well as collecting and visualising the data is one of my favourite parts of the A3 process. Simply visualising a problem in this way can have a huge impact. The chart below shows our historic bug count. It’s not hard to figure out when we started making this chart and sticking it on the wall for everyone to see.

ACT

After we’ve checked the impact of our actions, so what? Do we need to take further actions to reach our target state? Have we already reached it, and how do we ensure we maintain the new status quo? Do we move on to the next biggest problem?

This is the first time we’re using the A3 process in the software team, so this blog is all about sharing our journey and experiences with you. You’ll hear from programmers about the great new code they’re writing, and from product managers about how our efforts fit in with the wider business context and how we’re communicating this to our user base. The next few posts will go into more detail about how we’re trying to achieve our target state by improving our code and working with new software technologies.