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.

Beyond “Move Fast and Fail Fast”: Balancing Speed, Security, and … Sanity in Software Development (with Podcast)

/in

Move fast and fail fast

In software development, the mantra “move fast and fail fast” has become both a rallying cry and a source of considerable debate.

It champions rapid iteration, prioritizing speed and output, often at the perceived expense of meticulous planning and architectural foresight. This approach, deeply intertwined with the principles of agile development, presents a stark contrast to the traditional model of lengthy planning cycles, rigorous architecture design, and a focus on minimizing risk through exhaustive preparation.

Fail fast

The allure of “fast” is undeniable. In today’s competitive market, speed to market can be the difference between success and failure. Rapid prototyping allows for early user feedback, facilitating continuous improvement and ensuring the product aligns with real-world needs. In essence, it’s about validating hypotheses quickly and pivoting when necessary. This iterative approach, inherent in agile methodologies, fosters a culture of adaptability and responsiveness, crucial in environments where change is the only constant.

So, “fail fast” refers mostly to a fast validation of the MVP (minimum viable product) and drop it if the results are unsatisfactory. This is, in general, very good because it is an optimal usage of resources.

Speed vs. Integrity

However, the emphasis on speed can raise legitimate concerns, particularly regarding security and long-term architectural integrity.

The fear is that a “move fast” mentality might lead to shortcuts, neglecting essential security considerations and creating a foundation prone to technical debt.

This is where the misconception often lies: “fast” in this context does not necessitate “insecure” or “bad.” Rather, it implies a prioritization of development output, which can, and should, be balanced with robust security practices and a forward-thinking architectural vision.

But, how can this forward-thinking be achieved, when the team is focused mostly on delivering value to validate with customers the assumptions made?

The key lies in understanding that agile development, when implemented effectively, incorporates security and architecture as an integral part of the process.

Concepts like “shift left security” emphasize integrating security considerations early in the development lifecycle, rather than as an afterthought.

Automated security testing, continuous integration/continuous deployment (CI/CD) pipelines with security gates, and regular security audits can be woven into the fabric of rapid development, ensuring that speed does not compromise security.

Validating early in the process means also that the not only the product is proven to meet the expectations, but also the architecture it is built upon.

The traditional approach

On the other hand, the traditional approach, with its emphasis on extensive planning and architecture, offers the perceived stability of a well-defined blueprint.

However, this approach carries its own risks. The extended planning phase can lead to delays, rendering the final product obsolete by the time it reaches the market. Moreover, the rigid nature of pre-defined architectures can hinder adaptability, making it difficult to respond to unexpected changes in user needs or market dynamics. The risk of “failing due to delays and lack of adaptation” is a real threat in fast-paced environments.

The modern software developer must navigate this tension, finding a balance between speed and stability. This involves adopting a pragmatic approach, leveraging the benefits of agile methodologies while mitigating the associated risks.

This can involve:

  • Establishing clear security guidelines and incorporating them into the development process. Having a SSDLC is mandatory when having to deliver fast.
  • Prioritizing a modular and adaptable architecture that can evolve with changing requirements. Modules should be possible to be implemented quickly and dropped without a lot of pain if they prove to be unsuccessful.
  • Implementing robust testing and monitoring to identify and address issues early on. A CI/CD pipeline will allow the team to focus more on delivering new features than testing and integrating all the time.
  • Fostering a culture of continuous learning and improvement, where developers are encouraged to experiment and innovate, while also being accountable for security and quality.
  • Utilizing threat modeling and risk assessment early in the design process. Threat modeling contains a risk assessment, which when done properly will prevent major issues later.

Instead of Conclusions:  my experience

Ultimately, the most effective approach is not about choosing between “fast” and “slow,” but about finding the right cadence of delivering value for each specific project .

The goal is to deliver constantly small pieces of code that bring value while avoiding failure altogether. If deliverables are constantly validated, a failure can only be of a small deliverable increment, which can be either quickly improved, completely removed or entirely replaced with something else.

Important is to learn from it quickly and adapt, ensuring that software development remains a dynamic and evolving process.

When I run a project, I define the goal and the high level path to achieve that goal. Sometimes this path is clear, sometimes many experiments are needed, and some will fail, some will succeed.

The post Beyond “Move Fast and Fail Fast”: Balancing Speed, Security, and … Sanity in Software Development (with Podcast) first appeared on Sorin Mustaca on Cybersecurity.