Posts

Guide for delivering frequently software features that matter (series) #2/2: Challenges and the path forward

/in

Click below for the podcast version (AI generated):


Challenges that stop teams to deliver and how to solve them

Objection 1: “Our features are too complex for short sprints”

This is the most common objection I hear, and it reveals a fundamental misunderstanding. The solution isn’t longer sprints or more sprints — it’s better feature decomposition.

Take an e-commerce checkout flow. Instead of trying to build the entire process in one Sprint, break it down: first, just shopping cart management; next, shipping information; then payment processing; finally, order confirmation.

Each piece provides immediate value and teaches you something about user behavior.

The key insight? Users will happily use a partial feature if it solves a real problem for them. Of course, some things can be used, some others don’t.

In the above example, it makes no sense to allow ordering without being able to pay or to enter a delivery address.

It’s important to apply common sense and decompose features in such a way that they provide some value to the user or stakeholder.

Another aspect here is that sometimes you maybe don’t deliver the feature to the users, but you accumulate a few deliverables and then you ship them together, when it makes sense.

The key take out is: there is no receipt for how small or big the features should be in order to allow delivery. Try to decompose them and use common sense when to deliver them: individually or in sets.

 

Objection 2: “We can’t maintain quality at this pace”

Quality isn’t something you add at the end—it’s built into every step. The teams with the highest delivery frequency actually have the fewest quality issues because they’ve automated their quality checks and made them part of their daily workflow.

But this has a mandatory requirement the fact that automation is there.

If you postpone automation you run eventually in technical debt, which is more expensive to implement later.

 

Objection 3: “Our stakeholders don’t understand this approach” or “they don’t know what they want”

Stakeholder education is crucial. They need to understand that their active participation is what makes frequent delivery valuable. Regular “show and tell” sessions where stakeholders can actually use the software create enthusiasm and provide immediate feedback.

One technique that works well: frame frequent delivery as risk reduction. Instead of betting everything on a big release, you’re placing smaller, safer bets that can be adjusted based on market response.

Ask for feedback about you delivered and what you plan to deliver. You will see that even if the stakeholders don’t know exactly what they want, they will find it easier to provide feedback or corrections to your plans.

 

Advanced strategies for teams

Release planning without rigidity

While Scrum focuses on Sprint-level planning, successful teams also think several Sprints ahead. I use story mapping to visualize how features relate to user workflows, which helps identify what should be delivered together versus what can stand alone.

Think of it as planning a road trip—you know your major destinations but remain flexible about the exact route based on what you discover along the way.

Manage dependencies

Dependencies kill delivery predictability. The best teams minimize them through smart architecture choices (like microservices) and careful Sprint planning. When dependencies exist, make them visible through dependency boards that show how different teams’ work interconnects.

Define and collect metrics that actually matter

Velocity is useful for Sprint planning, but business metrics tell the real story.

  • Did you receive any feedback or complains from customers/users/stakeholders?
  • How quickly can you respond to customer requests?
  • How often do users engage with new features?
  • How many bugs did you have in the last delivery?
  • Were the features delivered used?

These metrics ensure frequent delivery, which translates to business success.

Building the culture that makes it work

Creating psychological safety

Frequent delivery requires teams to take risks and experiment. This only works when people feel safe to voice concerns, make and admit mistakes.

The goal is not to make mistakes, but to be aware that they might occur and react accordingly.

In my retrospectives, I focus on systems and processes, not individual performance.

When problems arise, we ask “how do we prevent this?” not “who caused this?”

Yes, sometimes it is needed to get direct feedback, but in general, I try to focus this feedback on me and less on other team members.

 

Real customer collaboration

The Agile Manifesto’s emphasis on customer collaboration isn’t just philosophy—it’s practical necessity.

Whenever possible and feasible, try to involve actual end users in sprint reviews, not just business stakeholders. Their feedback often reveals usability issues that internal teams miss.

Implement user analytics directly in your application to provide continuous insight into how people actually use your software.

 

Instead of conclusions

Mastering frequent delivery is a journey, not a destination.

The teams I’ve worked with who succeed share three characteristics:

  • They embrace change as opportunity,
  • They prioritize working software over comprehensive documentation (who doesn’t ?), and
  • They value collaboration over rigid processes.

Start with the fundamentals—reliable Sprint execution and solid engineering practices—then layer on advanced techniques as your team matures.

The goal isn’t perfection; it’s continuous progress toward more effective value delivery.

Organizations that master frequent delivery gain significant competitive advantage. They respond quickly to market changes, incorporate user feedback rapidly, and create more engaging work environments where team members see the immediate impact of their efforts.

Your journey starts with the next Sprint. Focus on delivering something valuable to users, measure their response, and use that learning to make the next Sprint even better.

That’s the path to software that actually matters.

The post Guide for delivering frequently software features that matter (series) #2/2: Challenges and the path forward first appeared on Sorin Mustaca on Cybersecurity.

Guide for delivering frequently software features that matter (series) #1/2: the Pillars of successful frequent delivery

/in

Click below for the podcast version (AI generated):

Guide for delivering frequently software features that matter: the three Pillars of successful frequent delivery

If you’re a software engineer older than 30 years, then you definitely have worked following a non-agile methodology.

Those methodologies are based on a fixed structure, a lot of planning, and hope that everything will go as planned. And they never worked 🙂

 

Small bets, less risk

After helping many teams transform their delivery approach over the past 2 decades, I’ve learned that the most successful software projects share one trait: they deliver working software early and often. Think of it like learning to cook—you taste as you go rather than waiting until the entire meal is prepared to discover it needs salt – or to discover that it has too much salt.

Scrum’s power lies in its ability to turn software development from a high-stakes gamble into a series of small, manageable bets.  It basically lowers the risk of creating something that is a failure before it is even released.

Instead of spending months building features that might miss the mark, you deliver value every 2 weeks and course-correct based on real user/stakeholder feedback.

 

The Three Pillars of successful frequent delivery

1. Sprint Planning that actually delivers value

Here’s where most teams go wrong: they focus on completing tasks instead of delivering outcomes.

In my experience, the magic question that transforms Sprint planning is: “What could we deliver to users at the end of this Sprint that would make them say ‘this is useful’?”

Or maybe, if you’re not that far, think in terms of: what do we have to do in order to be able to have something to show to customers/users/stakeholders?

This shift in thinking leads to what I call “vertical slicing”—delivering complete, end-to-end functionality rather than building in horizontal layers.

Think of instead of spending a sprint on “database framework,” you deliver a complete feature like “user login” that touches database, business logic, and user interface.

Or, instead of having a “GUI framework”, implement a GUI element and make it testable. You will still need to put the base of the GUI framework, but you will likely (or hopefully) implement only those elements needed to deliver that one element.

 

2. Your Definition of Done (DoD) is your safety net

The Definition of Done isn’t bureaucracy—it’s your insurance policy against the dreaded “90% complete” syndrome. I’ve seen too many teams rush to demo features that weren’t actually ready for users, creating technical debt that haunts them for months.

A solid Definition of Done includes peer reviews, automated tests, security checks, performance validation, and sometimes stakeholder approval.

Think of it as your quality gateway: nothing passes through unless it meets production standards.

 

3. What enables speed

CI/CD

Continuous Integration isn’t just a nice-to-have—it’s the foundation that makes frequent delivery possible. When code is integrated and tested multiple times, you eliminate the integration nightmares that plague traditional development.

Anything that is manual, especially testing, takes more time on the long run. And in software development you are running a multi stage marathon. Invest in automated End-To-End testing and you invest the time once, not every release cycle.

 

Main branch development

The teams who excel at frequent delivery have embraced “trunk-based development” where everyone works from the main branch. This forces smaller, more frequent commits and prevents the merge conflicts that can derail Sprint goals.

You might say that this is not always possible – and I even agree. Sometimes you need to branch in order to allow parallel development of larger features, which you don’t want to deliver step-by-step. While I don’t like this approach, I understand that sometimes it makes sense.

But, even in such cases, you can apply the same strategy on the parallel branch: make many small commits so that you can release often and test often.

 

I’ll stop here for now, but as you can see, there are many challenges that stop teams from releasing often.

I’ll address this in the next article from this series.

The post Guide for delivering frequently software features that matter (series) #1/2: the Pillars of successful frequent delivery first appeared on Sorin Mustaca on Cybersecurity.

Guide for delivering frequently software features that matter (series)

/in

If you’re a software engineer older than 30 years, then you definitely have worked following a non-agile methodology.

Those methodologies are based on a fixed structure, a lot of planning, and hope that everything will go as planned. And they never worked 🙂

 

Small bets, less risk

After helping many teams transform their delivery approach over the past 2 decades, I’ve learned that the most successful software projects share one trait: they deliver working software early and often. Think of it like learning to cook—you taste as you go rather than waiting until the entire meal is prepared to discover it needs salt – or to discover that it has too much salt.

Scrum’s power lies in its ability to turn software development from a high-stakes gamble into a series of small, manageable bets.  It basically lowers the risk of creating something that is a failure before it is even released.

Instead of spending months building features that might miss the mark, you deliver value every 2 weeks and course-correct based on real user/stakeholder feedback.

 

The Three Pillars of successful frequent delivery

1. Sprint Planning that actually delivers value

Here’s where most teams go wrong: they focus on completing tasks instead of delivering outcomes.

In my experience, the magic question that transforms Sprint planning is: “What could we deliver to users at the end of this Sprint that would make them say ‘this is useful’?”

Or maybe, if you’re not that far, think in terms of: what do we have to do in order to be able to have something to show to customers/users/stakeholders?

This shift in thinking leads to what I call “vertical slicing”—delivering complete, end-to-end functionality rather than building in horizontal layers.

Think of instead of spending a sprint on “database framework,” you deliver a complete feature like “user login” that touches database, business logic, and user interface.

Or, instead of having a “GUI framework”, implement a GUI element and make it testable. You will still need to put the base of the GUI framework, but you will likely (or hopefully) implement only those elements needed to deliver that one element.

 

2. Your Definition of Done (DoD) is your safety net

The Definition of Done isn’t bureaucracy—it’s your insurance policy against the dreaded “90% complete” syndrome. I’ve seen too many teams rush to demo features that weren’t actually ready for users, creating technical debt that haunts them for months.

A solid Definition of Done includes peer reviews, automated tests, security checks, performance validation, and sometimes stakeholder approval.

Think of it as your quality gateway: nothing passes through unless it meets production standards.

 

3. What enables speed

CI/CD

Continuous Integration isn’t just a nice-to-have—it’s the foundation that makes frequent delivery possible. When code is integrated and tested multiple times, you eliminate the integration nightmares that plague traditional development.

Anything that is manual, especially testing, takes more time on the long run. And in software development you are running a multi stage marathon. Invest in automated End-To-End testing and you invest the time once, not every release cycle.

 

Main branch development

The teams who excel at frequent delivery have embraced “trunk-based development” where everyone works from the main branch. This forces smaller, more frequent commits and prevents the merge conflicts that can derail Sprint goals.

You might say that this is not always possible – and I even agree. Sometimes you need to branch in order to allow parallel development of larger features, which you don’t want to deliver step-by-step. While I don’t like this approach, I understand that sometimes it makes sense.

But, even in such cases, you can apply the same strategy on the parallel branch: make many small commits so that you can release often and test often.

 

I’ll stop here for now, but as you can see, there are many challenges that stop teams from releasing often.

I’ll address this in the next article from this series.

The post Guide for delivering frequently software features that matter (series) first appeared on Sorin Mustaca on Cybersecurity.