Would you rather have working software or a bunch of documentation? If your software is having outages then by definition it is not working. If documentation is the root cause of that then you should fix that by creating enough documentation to allow your software to continue to work per “working software over comprehensive documentation”. Maybe I’m missing something but I don’t see the contradiction here.
This assumes front-end development. If I had somebody tell me to use their API or backend software and they handed me a tarball instead of proper documentation, I’d look very far away from their company.
In long term development, sensible and updated documentation is far more important than the software working constantly. You will have downtimes. You will have times before the PoC is ready.
But if your documentation sucks or is inexistent, you cannot fix any problems that arise and will commit a ton of debt the moment people change and knowledge leaves the company.
Fair enough, at my job the code working consistently is absolutely the number one priority at all times but I can imagine that there are some places where this is not true. If working software isn’t imporant then I agree agile is probably not the right choice
It’s worth pointing out though that having insufficient documentation is not a feature of agile. Sounds more like laziness or misplaced priorities to me as documentation is called out as being useful in the agile principles, just not as important as working software.
Would you rather have working software or a bunch of documentation? If your software is having outages then by definition it is not working. If documentation is the root cause of that then you should fix that by creating enough documentation to allow your software to continue to work per “working software over comprehensive documentation”. Maybe I’m missing something but I don’t see the contradiction here.
Or create a better UI that doesn’t require so much documentation.
This assumes front-end development. If I had somebody tell me to use their API or backend software and they handed me a tarball instead of proper documentation, I’d look very far away from their company.
Yeah, I almost added a clarification for that very point, and see now that I should have.
Sacrilege!! /s
This is the most accurate description of anything that’s ever been written.
If 2 and 3 happen the game is up. Management killed it.
That’s not agiles fault.
Surely you’re not gonna blame the manager… /s
In long term development, sensible and updated documentation is far more important than the software working constantly. You will have downtimes. You will have times before the PoC is ready.
But if your documentation sucks or is inexistent, you cannot fix any problems that arise and will commit a ton of debt the moment people change and knowledge leaves the company.
Fair enough, at my job the code working consistently is absolutely the number one priority at all times but I can imagine that there are some places where this is not true. If working software isn’t imporant then I agree agile is probably not the right choice
It’s worth pointing out though that having insufficient documentation is not a feature of agile. Sounds more like laziness or misplaced priorities to me as documentation is called out as being useful in the agile principles, just not as important as working software.
Definitely. Most often it’s people misunderstanding the “a over b” of agile as “never do b”.