Dan zou je toch op zijn minst ook in dit soort methodes willen terugzien, welkew documentie er verwacht wordt.
Nee juist niet! Dat dient bij de professionaliteit van het team te liggen! Als ik jouw verhaal zo terug hoor (ook in de post hierboven van je), dan heeft jouw organisatie zo goed als niets van Agile / Scrum begrepen en acteren ze meer als een stel cowboys / hippe managers.
Zoals je het nu doet over komen, overkomt Agile/Scrum jou vooral en ben je gefrustreerd zoals het nu gaat. En als bovenstaande klopt, dan snap ik helemaal dat je gefrustreerd bent.
Ik neem aan dat je bekend bent met de termen die bij Scrum horen. Daarom de volgende tip: zorg dat je in de planningssessie een duidelijke Definition of Done aan de user story hangt, waar 1 item de documentatie is en waar deze aan moet voldoen. Op die manier borg je dat dit gedaan wordt en maak je inzichtelijk hoeveel werk hiermee gemoeid is.
Doe dit een keer of 10, 20 en het wordt een vanzelfsprekendheid die je vaak in 5 - 10 minuten kunt plannen.
Agile / Scrum is een methode die de kracht van het Developmentteam juist bij het Developmentteam legt en als het echt goed is ingericht, ook met de requirements en invloeden van Beheer, zoals goede documentatie, logging, gebruikersinstructies, etc.
Op de post hieronder, ik ben ook beheerder van applicaties, minder lang dan jij waarschijnlijk, maar ook voor niet de minste applicaties. En juist door mee te participeren bij Dev-teams kun je de focus leggen op risicobeheersing tijdens het live gaan. Door bijvoorbeeld bij de planning al eisen te stellen en niet pas vlak voor livegang, waardoor je stress creëert, wat fouten in de hand werkt. Of erger, dat je eisen genegeert worden, omdat een deadline gehaald moet worden.
Ik denk echt dat jij nog een hele mooie uitdaging in jouw organisatie hebt om zaken te verbeteren (en jezelf daarmee positief in het daglcht te zetten) als het er echt zo aan toe gaat zoals jij omschrijft