How to release your best potential features more often?

Digital products usually hit this plateau phase, where we don't know what to release next? Most business usually have their core features, which they use to drive most of the business revenue, but in order to stay in shape, you need to challenge your processes and learn from them. In the following lines, I'm talking more about 'Learning' activity in an Agile environment, and how to evaluate this core activity? 

Learning as a job in software development

Software is a set of complex and creative processes that being maintained by creative human individuals. That being said, the process of creating new software is extremely tricky when it comes to predicting the market needs, or in a more Agile terms, what users are after in order to use your software product.

To predict, you need knowledge. In order to be knowledgeable, you need to understand your users, hence, you need to learn about them. Your ability to lean specifies to what degree you’ll hit your target.

Learning in an Agile-friendly environment is one of the core values you should embrace with your team, as it’s not just expanding the horizon and gives you more visibility about what truly your software need to provide, but it also gives your team the chance to adjust their thinking in a way that takes market in consideration.

Narratives as the building blocks

In its core, Agile is more about humanize the process of making software, by making it similar to what humans are familiar with. And we communicate our problems by narrating them. We’re skilled at doing that, but, when it comes to software, many people think: Oh! It’s software, we should know and specify every spec out there, and the more we specify, the more we’ll get higher quality! Unfortunately, no! And I’m going to explain why below.

You’ll never code alone

Building software is mostly about communication, different levels of communication determine different levels of software quality. First level would be: problems scenarios, or what we’re trying to solve? Problem scenarios aren’t necessarily “Logical Problems”, it can be habit, desire, or even a common pattern that some user group (AKA personas) is adapting in order to get their jobs done. Narratives are the building blocks when it comes to such level of communication. Narratives are also known as “User Stories”, you can find more about them: Brief history of user stories.

You cannot develop something you don’t understand

Narratives help us understanding why we’re doing things. We’re adding this feature in this way, because we have some habits that some user groups are adapting to get things done in a similar pattern.

Weak inputs creates weak user experience

If you don’t rely on narratives, or the inputs are weak in your team (i.e. people often don’t understand why they’re doing stuff in specific way) then you’ll end up with overall weak process. Your team won’t be confident enough to deliver and push new releases. Because nobody understands the point.

Evaluate your narratives and make them better

Symptoms of weak narratives

Shaky discussions: Your team’s discussion are often shaky, and you cannot draw a concrete base from. Everyone is trying to describe it in a different way.

No one is sure about what to deliver: So, to what extent should we release? God only knows! This is another indication that people in your team don’t quite understand the scope of what they’re working on.

Estimation problems: You often end up with too large or too small estimations that creates unrealistic deadlines and releases.

Evaluate iteratively

You can learn from your releases and improve your productivity cycle, by taking in consideration some aspects:

Being not wrong isn't enough: Be sure you’re right rather than checking that you’re not wrong about features. Meaning that, if you always ask yourself: Did we delivered the right thing? It’s an indication you didn’t. And your next goal of releasing should be focused on learning from users and improving your next release deliverables.

Evaluate your output iteratively: always ask yourself: were we precisely right when we release this feature X? And try to evaluate your answer and make your evaluation more data-driven. That way, you’ll hit that 1-million feature more often!