"Deliver value daily" – A one-principle manifesto for agile software development

A one-principle manifesto for agile software development

Why?

By delivering value daily:

• ✅ You will maintain understanding of what value means for your users and organisation
• ✅ You will put things into place to deliver that value
• ✅ You will receive daily feedback validating your assumptions

And of course:

• 🏆 You will deliver value daily

How?

• 🔬 Continually extract smaller features

The single most important technique is to repeatedly choose features smaller than what are assumed to be needed, and make them useable by real users by the end of each day. Ideally they will be much smaller, so you limit the risk of not completing them within a day, and so you increase the chance of delivering value multiple times each day.

To make this choice, you often need to be close to users - for example in direct contact with them. It also requires a certain level of confidence - do what it takes to develop this if you think you're low.

But... what about https://agilemanifesto.org/?

• 🧩 Delivering value daily is compatible with the original 12 principles (mostly)

Following this one principle will result in following the 12 principles of the original Agile Manifesto - at least the ones that help deliver value in your case. A definite exception is the apparent lower bound of a "couple of weeks" on how frequently working software can be delivered - we can do better!

But... what about refactoring or developer experience?

• ⚖️ Balance delivery with improving developer experience

If refactoring allows you to deliver identified value: absolutely do it.

But on tasks that are more about improving pace or experience of delivering value in the future, also do them, but just not whole days at a time - at least some of each day should result in value that day. By following the principle you will balance delivering immediate value with investing for delivering more value tomorrow.

Never refactor or address "tech debt" without a clear idea of how it will lead to value.

But... does this risk reducing quality?

• 💯 Maintain standards by including time for quality

No! This is not about cutting corners, this is choosing the smallest pieces of work you can complete in a day that provide value at the quality level you decide is appropriate.

But... we have a fixed release cycle and I can't change that?

• 🫵🏻 Do what you can to get close to value

Do what you can to split out the smallest valuable parts of remaining tasks, and get them as close as possible to releasable that you have the power to do every single day. In many cases this still results in valuable feedback that informs next steps.

But... I won't be able to keep up delivering every day?

• 🐌 Maintain a sustainable pace by aiming to complete only thin slices of features

Do not set out to complete features as envisaged each day - this is impossible. Instead, set out to complete thin slices of them, and don't be afraid of shrinking things even further as each day progresses.

This is effectively the opposite of Scrum's commitment to achieving fixed sprint goals.

But... how can I also achieve strategic goals?

• 🧭 Only take steps that result in value and align with longer term goals

This isn't waking up each day and just firefighting or deciding what to do on a whim. There are often many things you could do, but you should choose the ones that not only result in value by the end of the day, but the ones that also get you closer to longer term goals.

This requires that you keep up to date with the longer term goals for both your immediate team and wider organisation. This is a good thing!

But... surely this is impossible in complex landscapes?

• 👣 Take even smaller steps in complex landscapes

When faced with complexity take what might seem to be ridiculously small steps. Solve a single subset of a problem for a single user. Or perform some steps manually. Or consider solutions that don't involve code. Do the absolute smallest thing that provides a tiny sliver of value. Small steps are exactly the ones that are possible in complex situations.

If you feel silly because you think they're too small, remember it's the complex situations that need this - there are many unknowns and so early and frequent feedback is crucial. It's much sillier to spend weeks going down the wrong path than a day.

But... don't I need AI to do this?

• 🤖 Use AI only if appropriate in your case

This absolutely does not require AI to generate code. This is not about outputting more code every day, it's about choosing what you do every day in a very particular way - to provide value, to get feedback, to understand that feedback and be able to respond to it. If AI helps you do this, if it's appropriate and allowed in your field, and if you understand and can accept the short and long term risks, then use AI. If not, don't.

But... everything that's valuable will take more than a day?

• ⏭️ If you really can't deliver value today, set yourself up for value tomorrow

If you really can't extract a small enough amount of work that's valuable today, is there anything that you can complete today that can set you up for delivering value tomorrow? Tasks that reduce the scope of the remaining problem or get feedback on your riskiest assumptions from users or technology are often good choices.

But... what if I thought I could deliver, but in fact I couldn't?

• 🌅 Don't worry if there are days you don't manage to deliver value

"Deliver value daily" is a principle, not a contract. There are benefits of just aiming to achieve it, so if there are days where you don't manage to deliver value, then the only consequence is... you don't manage to deliver value. The next day, have a quick think on the best next steps to take based on what you've learnt, and then take them.

What other techniques can help deliver value every single day?

You will probably build up your own project-specific suites of techniques to help you deliver value, but here's some to start off with:

• 🗣 Speak to users every day
• 👠 Put yourself in their shoes
• ↕️ Vertically slice larger pieces of work
• 👥 Work in mobs or pairs
• 🙋🏼‍♀️ Take ownership of your changes
• 🕵🏾 Continually learn how things work
• 🚛 Maintain CI/CD pipelines
• 📝 Maintain good ranges of tests
• 🚦 Initially limit features to specific users
• ⚙️ Automate, but gradually
• 🎯 Make features for very specific cases
• 🏁 Deploy to production on day one
• 🔀 Adapt plans in order to deliver value
• ⚛️ Extract and deploy atomic commits
• 🪞 Regularly reflect on practices
• 🌱 Refactor incrementally
• 🤷🏻‍♂️ Candidly admit your ignorance
• 🤔 Self-review code before asking others
• 🫱🏽‍🫲🏻 Be confident, but not arrogant
• 📣 Write and share day notes
• 🎨 Develop your creativity
• 🛡 Encourage psychological safety
• 👩🏻‍💻 Read the docs and the source
• ❤️‍🩹 Explore user pain points
• 🌟 Be a bit ambitious
• ⏳️ Treat each day as the last of the project
• 🔋 Monitor infrastructure utilisation
• 🧪 Experiment (safely)
• 📖 Write (light) docs before the code
• 🧰 Recognise and apply your existing skills
• ↔️ Horizontally scale only when needed
• ♻️ Leverage existing resources
• 🆘 Seek help quickly and frequently
• 🧠 Remember: some value beats no value