Agile in an auditing firm – documentation
The previous post was the first in a series about Agile project management in accountancy. Agile is a methodology that is often used in software development. The main principles behind the concept are the constant change in requirements, not every requirement has the same importance and the team is self-managing. In auditing projects there is also a team working in a self-managing way. The assignment consists of tasks (features in Agile terminology) that have documentation (specifications) that is sometimes more extensive than necessary. So this is the second blog about the Agile Manifesto. Het underlying statement is:
Working software over comprehensive documentation
At first I had my doubts about the practical application of this concept. How on earth are you going to support users on a platform without good documentation of the functionality and development process?
Agile is not a waver for bad or incomplete documentation. The principle behind this statement is that documentation will evolve during development and not beforehand. However extensive a user story is written, a developer will have questions and needs discussion. Therefore the documentation is limited at first and further detailed during development. This is called ‘refinement’. This saves a lot of time on describing features that are never completed, or completely different in the end.
Another reason for not over-documenting is that documentation isn’t poetic artwork but functional. The working software is far more important. Good software doesn’t need comprehensive documentation.
Focudis for good and to-the-point documentation
Auditors love ‘section memos’. In one large Word file all tasks, all outcomes and the illations are captured. The main disadvantage is that there is no link between a part of the memo and the underlying tasks. When something changes, tasks are added or dropped, it doesn’t affect the memo. It could be that a task is checked off without any mention in the memo.
In our tool Focudis tasks and outcomes are permanently linked. The manager doesn’t read a memo but watches the show called ‘ Story of the audit’. In the story the risks, tasks and outcomes are brought together.
Should a new task be added tot further mitigate a risk it is automatically captured in the concerning story. And if you don’t like our movie it is always possible to review the tasks manually
Budget overruns and additional work
I’m getting more and more excited about Agile project management. With some minor adjustments to legal requirements to my opinion Agile is very useful in accountancy. The next blog has a subject that most accountants hate: Budget overruns. That’s something common in software development as well. Therefore the third and last agile adage is: “Customer collaboration over contract negotiation”.