We handle more than 15 issues every sprint! A scrum master was bragging to a colleague by the coffee machine the other day.

I call this artifact-based delivery, meaning we spend a lot of time measuring artifacts. Probably because it is the easiest. It is easy to tick checkboxes for what is done.

The problem is that it does not measure outcome. The evidence of outcomes are circumstantial at best.

Instead, we need teams that can act on input and create valuable output, and they need the skills necessary to do it. In this article, we discuss how to avoid being stuck in a factory.

The Software Factory Problem

• We measure the activity, not the outcome.
• We shield the development team from the complex nature of what we try to do as a business.

This is not all bad as it allows your developers to focus, as mentioned above. However, it is not ideal either considering it impedes the potential of building smart teams.

We need smart teams

Instead, we need teams that can act on input and create output of real and measurable value. To be able to do this they need certain skills, they need to know about the outside world, and they need to understand what drives your business forward.

The more autonomous your team can be, the less you will have to manage it.

Define value and create feedback loops

A prerequisite to succeed in building autonomous teams is to define how your team deliver value. In this article, a colleague of mine, Daniel, describes a good starting point.

Another way to allow the team to be more autonomous is to let it create its own feedback system.

The team can have internal feedbacks to make sure they deliver the quality that our business expects.

This could be things like

• Compile the code – The compiler tells us a list of errors and warnings to check.
• Run unit tests before you commit your changes – The test suite tells us if we broke anything.
• Do code reviews – We learn together and make sure that everyone understands the changes

We also need to have external loops to be able to understand what happens when we deliver the code.

• Feature demo – to get feedback from real users
• Do a live test with a client in their system

Do you know what your feedback loops look like?

Wrapping up

In order to deliver value, you must first define what value you try to create. Then you can install a set of feedback loops in order to check that what you do is actually creating value.

This article was also published on Transforming Embedded here.