"Deliver value daily" – A one-principle manifesto for agile software development
delivervaluedaily.devFor a while now some colleagues and I have been thinking about how to improve ways of working, and specifically around the limitations of Agile - especially how it's practiced. As has been suggested by others before us, Agile is all too often a cargo cult: surface level features - often ceremonies taken from Scrum - are prioritised over delivery and getting feedback. Our solution to this is a simplified manifesto with exactly one principle: "Deliver value daily", which we're hoping will reshape thinking, at least a little bit.
Full disclosure: I posted an earlier version here about a month ago, but have since refined it a bit, so hopefully it's appropriate to post it again.
It's actually pretty amazing that you extracted the very worst, most very destructive practices and ideologies of agile and put it into a package that would allow toxic managements to maximally hurt their developers.
I was actually thinking this is all from the developer point of view (or at the very least mine: a developer). I try to deliver some value every working day, and I have to say I pretty much love it. This principle really pushes me to make sure I understand the problems and engineer solutions to them appropriately. And from feedback I get, I am, apparently, very productive doing this. And I do encourage others to work this way (as I was myself encouraged), but I do emphasise the point made repeatedly in the manifesto: the increments can _really_ be extremely small. And to also emphasise another point in the manifesto here - it's not a concern if the aim isn't fulfilled every day. If most developers currently aim for value every 2 weeks say, and that's what they're used to, then of course every day won't always happen, certainly in the beginning of working this way. Or yes, there may be unexpected things along the way. And this is all completely fine.
(This last point was a late addition to the manifesto: but I _think_ made before your comment)
Can you give a bit more detail on the destructive aspects though? If you mean if an organisation follows this, then it ends up as a stick to beat developers with if they don't deliver value every day? I guess my counter to that is, if management is toxic, they will always find a stick to beat developers with, no matter what.
What the manifesto does, or at least tries to do, is encourage developers to think about how larger pieces of work are tackled - so they end up really understanding what the problems are, and so engineer solutions to them appropriately. Wherever possible getting feedback, and if possible on a cadence of at least daily, to me seems such a good way of doing this - but do you have a better suggestion?
Edit: I see https://github.com/rayfrankenstein/AITOW and have started to give it a read… and… wow. I certainly understand where you’re coming from, and I would hate to see “Deliver value daily” make all these situations worse.
I think I’ve been really lucky - only maybe experienced light versions of the worlds described, and in the past few years have worked in a very supportive environment and had a lot of autonomy. In this environment I/my team decide on a lot, including ways of working like how to tackle bigger pieces of work. And in such an environment, “Deliver value daily” I think can really work, and essentially has.
But I think I am sticking with my point - I suspect toxic management will find any excuse, and the three words “Deliver value daily”, will do little to change that.
Although - I am tempted to make it clearer up front that autonomy and a supportive environment (and maybe other things?) are crucial, to try to at least limit how it could be “misused”
Although a follow up… could “Deliver value daily” actually help push _away_ from toxic behaviours like micromanagement?
As long as there is some sort of visible/tangible progress most days, and in a justifiable direction, there could be less of a desire for tight control for example?
I've now added a section to https://delivervaluedaily.dev/ that is at least a starting point of trying to make sure it doesn't make bad environments worse.
This has been helpful - thank you. @RayFrankenstein if you would like a small acknowledgement at the bottom of https://delivervaluedaily.dev/, let me know