โžก๏ธ "Deliver value daily" โฌ…๏ธ

A one-principle manifesto for agile software development

Why?

By delivering value daily:

And of course:

How?

The single most important technique is to repeatedly choose features smaller than what are assumed to be needed, and make them usable 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/?

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?

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 rarely 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 being sure the changes lead to value.

But... does this reduce 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.

Remember, the reduction of risk and other "non functional requirements" are often valuable. And while users's views are of course vital, your own judgement is too.

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

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 useful feedback that informs next steps.

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

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?

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?

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?

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... does this mean we can't have R&D or planning phases?

Some situations do warrant spending time doing R&D or planning up front. But in many cases they should also be done using a "deliver value daily" approach, and should focus on derisking later phases and empowering them to act on feedback.

Put another way: a value chain is acceptable if value can move through the chain frequently and it enables flexibility within subsequent steps.

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

If you really can't extract a small enough amount of work that's externally 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.

You can think of this as an ephemeral value chain where you deliver value to yourself.

But... what if I try to deliver, but in fact I can't?

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

But... isn't this another stick to beat developers with?

"Deliver value daily" encourages you to tackle work in a way so you end up understanding the real problems and solve them appropriately. While it can certainly help with reporting progress, it needs autonomy, trust, and a psychologically safe environment.

Things like working in sprints, estimating, and repeatedly answering "What did you do yesterday?" should only be done if your team finds them useful, and never be dictated from above.

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: