Creating value and reducing waste in software development

How can you create more value with software?

Any good recipe probably includes salt and pepper, but in software development, creating value for the end user and thus reducing waste is essential.

Let’s start by looking at how you can create more value with software. Before you start building a feature, be clear about its purpose or the problem it solves. Then use a prototype to validate whether the build is worth the investment. Teams that constantly ask themselves what they can best do to help the customer or user, or what will deliver the most, make better decisions than teams that only do what the product owner or (internal) customer wants.

What is waste in software development?

I often notice that at the start of a new project, many more requirements are defined than are necessary to add value. Often this happens because you want to develop the perfect product or the perfect functionality. But is perfect really perfect? We also call this feature creep or scope creep. It’s not always clear what these requirements will ultimately deliver to the end user, and whether there is any need for them at all.

When this happens, waste is created. Waste is any activity that provides no value to the customer or end user. There are seven forms of waste:

• Unfinished work
• Unnecessary functionality
• Handover between colleagues
• Detecting errors too late
• Switching between tasks
• Disappearing knowledge

The good news: if you manage to reduce waste, then:

• software teams become more productive
• you will avoid building features or complete products that are of no use to the end user
• the built product will be less complex
• your project will cost less time and money
• and more important: you reduce the chance that your IT project will fail.

For more about waste and how to reduce it, I recommend you read the book Lean Software Development: An Agile Toolkit.

Characteristics of a high-performance software team

Are agile teams high-performance teams?

An agile team can often make the difference in an organisation. These cross-functional, self-managing and flexible teams make it possible to develop and implement software more quickly. However, an agile team is no guarantee of value creation. But a high-performing team is a team that can deliver value quickly. They ensure higher conversion, a better online journey and fewer questions to customer service.

Of course, that doesn’t happen from day one. It’s only possible if your team:

• is motivated
• clearly understands why and for what purpose the software is being developed
• works in an environment where there is sufficient space, time and resources
• has the experience to deliver high quality in an efficient way
• has all the roles and skills on board to make an impact, such as analysts, tech leads, UX designers, engineers and delivery managers

High-performing teams are full of energy, genuinely enjoy the assignment and have a clear goal in mind. They work independently and learn every day. They know how to communicate clearly – to colleagues outside the team, the client and management – about what they are working on and what they want to achieve.

What are the five steps to developing a high-performance software team?

Step 1: Create a T-shaped team

T-shaped employees have their own expertise but can also effectively perform other tasks. Besides technical skills such as programming or design, these colleagues also possess emotional intelligence and creativity. At full strength, a high-performance software team includes expertise in UX and Design, Engineering, Infrastructure, Testing and Security. A T-shaped team also ensures better collaboration because employees can help each other.

Want to know if your team has all the necessary competences? Then the DASA DevOps Competence Model is a good tool for you. This model looks at your team members’ skills and knowledge. Ideally, your whole team should be at level 3 and a few team members should reach the expert or master level in the different sub-areas shown in the picture.

Source: https://www.devopsagileskills.org/dasa-competence-model/

Step 2: Start with a clear goal

Begin each project with a problem analysis. That means you don’t need all the roles identified in Step 1 immediately. It’s important to realise that things are always changing: your understanding of ‘what’ exactly you will build changes through the process of designing, validating, building, testing and releasing. At each step, you learn more as a team and you want to adjust. However, the ‘why’ and ‘for whom’ remain fairly stable. You can establish this well in advance with a smaller team, so you can save other team members’ valuable time.

Make sure your team does a good job of carrying out the problem analysis in the beginning, but don’t get bogged down in it for too long.

• Who are we serving?
• Who are the key stakeholders?
• When will we be successful?

You have to know the answers before you can brief your team properly. In my experience, even the most successful teams become restless if the ‘why’ isn’t clear. A tip is to build in a sprint 0 between the problem analysis and the start of a team. By doing so, you ensure that all preconditions have been arranged: think of the infrastructure, the release pipeline, the initial software architecture and the plan for the backlog. You can then start sprinting super-efficiently, which builds momentum and inspires confidence among all those involved. What could be better than seeing results quickly at the beginning of a project?

Step 3: Develop and release software in short cycles

Releasing software shouldn’t be particularly exciting for the teams; just a push of a button. The approach by which teams can produce software in short cycles and release it in an automated manner without problems is called Continuous Delivery. With Continuous Delivery, the focus is on building, testing and releasing software faster and more frequently. It also allows the software to be updated without inconveniencing users.

For many organisations and management, working in short cycles means that the end product is often not entirely clear at the start of a project. This requires something from your leadership: you must give the development team autonomy and trust and, above all, not want to determine the exact outcome in advance. Trust that the team with all the expertise on board will make the right choices based on the problem analysis and a clear ‘why’. In my experience, the most successful projects are those in which a high-quality team is given clear direction and then the freedom and trust to do the work for which they were brought together.

Step 4: Measure performance to optimise the process

You can optimise the process by measuring your team’s performance based on elements that lie entirely within their sphere of influence. High-performance teams will demonstrate value sooner, but until then you need a methodology to see where you stand as a team. We do this by measuring software delivery performance using the four key metrics.

The four key metrics are:

• Deployment Frequency: frequency with which new releases go live
• Lead Time for Changes: time needed to make a feature go live
• Mean Time to Restore: time required to resolve a problem in a live application or website
• Change Fail Rate: ratio of successful implementations to unsuccessful implementations that lead to problems.

Measuring and monitoring these metrics will give you insight into possible improvements in the process over time, and the team can adjust based on these insights.

Step 5: Bring agility and speed into the teams

Often, the challenge for management is twofold: can I let go of the notion that I can determine the exact outcome of a project, and is it enough if we launch something that is not yet perfect?

It’s natural to want to launch something that impresses others. But what if you can impress them with the speed with which your team can launch? How quickly you can improve the product? Or the way you incorporate feedback? That might just get you more from colleagues and customers. Try to look beyond the launch, and you’ll save yourself a lot of risk by going live earlier. Even if the reaction is ‘Is that all?’ A few releases and weeks or days later, you have achieved your goal – while other teams who want to launch big, might miss theirs.

At Worth, we have been building teams for 20 years and we know what a great and high-performing software team looks like. We know what it means to launch as early as possible, even in larger development projects. We sometimes work with several teams in parallel – with 50 people in total – on projects and programmes for commercial companies and government authorities. And now we know very well how to organise continuous delivery for them. We combine software and technology with the business to determine together what value can be created for your organisation. We bring strategy and pragmatism together in one team.