Posts

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.

Project management with Scrum (with Podcast)

/in


They can’t mix, can they?

Seems like a contradiction to talk about classical project management and the best agile software development methodology ?

But let me ask you this: ever feel like traditional project management is great for mapping out the big picture but falls short when it comes to the nitty-gritty of execution?

And conversely, while Scrum is fantastic for rapid iteration and delivering value quickly, it sometimes lacks that long-term strategic view?

If you feel this, then you’re not alone!

Yes, they can mix

Let’s talk about how to get the best of both worlds when managing projects: having a solid long-term plan and the flexibility to adapt and deliver quickly.

Sometimes it feels like traditional project management is great for the big picture but not so hot on the details, right?

And Scrum is awesome for getting stuff done in short bursts, but can sometimes lose sight of the overall direction.

Turns out, a lot of teams are finding a sweet spot by mixing these two. Think of it like having a good map for your road trip and a sturdy vehicle to handle any bumps along the way.

So, what does each approach bring to the party?

Classical Project Management: The Grand Plan

Imagine classical project management as your strategic guide. It’s all about figuring out the project’s scope, setting those long-term goals, marking important milestones, and creating a project plan.

We’re talking budget, resources, timeline – the whole thing.

It’s about answering the big questions:

  • What are we trying to do?
  • When does it need to be finished?
  • How much will it cost?
  • Who’s in charge of what?

This is great for having a clear vision and a roadmap. It helps everyone stay on the same page and lets you track progress.

The tricky part? Sometimes those detailed plans can go out of date pretty fast. Because things change, right?

 

Scrum: Getting Things Done

Now, Scrum is your agile friend. It’s built for doing things in short bursts, perfect for navigating the twists and turns of, well, pretty much any project.

You break the project into smaller chunks – sprints – usually 2 weeks long. Each sprint has specific goals, and the team works together to deliver something useful by the end.

Scrum is all about talking to each other a lot, having quick daily meetings, and checking in regularly. It’s about being flexible and delivering value bit by bit.

Scrum is great at handling feedback, adding new stuff, and showing real results quickly.

The thing is, on its own, Scrum might need that long-term direction that classical project management provides.

The Perfect Mix: Working Together, Delivering Fast

The magic happens when you put these two together:

  • You use classical project management to set the long-term vision, make the initial plan, and decide where you’re going. This gives you a good map.
  • Use Scrum to actually get there, one sprint at a time. Scrum becomes your engine for delivering value along the route laid out by classical project management.

Here’s a simple way to think about it:

  1. Big Picture: Classical project management sets the overall project scope, goals, and timeline. Everyone knows what the target is.

  2. Breaking it Down: The project gets broken down into smaller pieces, often using the classical project management approach. This makes the work manageable.

  3. Sprint Time: The Scrum team takes a chunk of work and plans it out for a sprint. They figure out what they can realistically do in that time.

  4. Daily Check-ins: The team has quick daily meetings to talk about progress, any problems, and adjust as needed. Keeps everyone in sync.

  5. Show and Tell: At the end of each sprint, the team shows what they’ve built and gets feedback. This feedback helps plan future sprints.

  6. Getting Better: Regular team meetings let everyone think about how they’re working and find ways to improve.

So, by mixing classical project management and Scrum, you get the best of both worlds. You have a clear long-term plan and the flexibility to adapt and deliver quickly. It’s a great way to work together, deliver fast, and make sure projects stay on track while being able to handle whatever comes up.

The post Project management with Scrum (with Podcast) first appeared on Sorin Mustaca on Cybersecurity.