Agile in het accountantskantoor – niet te veel documenteren
In het vorige blog heb ik Agile project management voor het accountantskantoor geïntroduceerd. Agile is een methodiek die vaak bij software ontwikkeling wordt toegepast. De gedachte achter agile is dat gaandeweg specificaties veranderen, niet iedere feature even noodzakelijk is en het team zelfsturend de ontwikkeling tot stand brengt. In de accountancy wordt ook gewerkt in teams. Deze teams zijn in zekere zin zelfsturend en een opdracht bestaat uit taken (features) waarvan de specificaties veranderen en niet allemaal even noodzakelijk zijn. Deze serie blogs is gebaseerd op het Agile Manifest. Het tweede adagium is:
Working software over comprehensive documentation
Toen ik de eerste keer deze zin las, had ik mijn bedenkingen over de praktische toepassing van deze gedachte. Je moet toch goede documentatie hebben om een werkend product op te leveren en gebruikers te kunnen ondersteunen?
Agile is geen vrijbrief om slechte of onvolledige documentatie te schrijven. De gedachte achter de stelling is dat enerzijds de documentatie pas goed tot stand komt tijdens de ontwikkeling en niet vooraf. Hoe uitgebreid een ‘userstory’ ook beschreven is, een ontwikkelaar zal vragen hebben en moeten kunnen stellen over de gewenste functionaliteit. Daarom wordt de documentatie eerst heel algemeen gehouden en verder gedetailleerd tijdens de ontwikkeling (‘refinement’). Hiermee voorkom je dat je aan de voorkant allerlei werk doet terwijl de feature uiteindelijk heel anders of helemaal nooit gebouwd wordt.
Anderzijds wordt de documentatie niet geschreven om mooi te zijn, maar functioneel. Er wordt meer aandacht besteed aan goede werking. Goede software behoeft geen uitgebreide documentatie.
Focudis voor goede beknopte documentatie
Accountants zijn dol op sectiememo’s. In één Word document staan alle verrichte werkzaamheden, uitkomsten en conclusies vermeld. Het nadeel van die sectiememo’s is dat ze vaak niet gerelateerd zijn aan specifieke taken en er daardoor geen relatie is tussen het uitgevoerde werkprogramma en het document. Het zou ook kunnen dat de beschreven taak in het memo anders is dan is afgevinkt in het werkprogramma.
Binnen Focudis worden uitkomsten en conclusies rechtstreeks gekoppeld aan taken. In de ‘story of the audit’ kunnen de risico’s met bijbehorende taken en uitkomsten worden afgespeeld.
Mocht je bepaalde taken willen toevoegen om het risico’s beter te mitigeren dan worden die automatisch in de betreffende story meegenomen. Overigens, als jij niet dol bent op sectiememo’s kun je er natuurlijk ook voor kiezen gewoon de uitkomsten van de taken te reviewen.
Budgetoverschrijdingen en meerwerk
Ik begin steeds enthousiaster te worden over Agile. En met wat aanpassing aan de wet- en regelgeving is Agile naar mijn mening zeker bruikbaar in een accountantskantoor. Het volgende blog gaat over een onderwerp waaraan accountants een hekel hebben: Budgetoverschrijdingen. Dat komt ook voor in softwareontwikkeling en daarom is het derde uitgangspunt van Agile: “Customer collaboration over contract negotiation”.