The book seems to make the assumption that everything is development work and only the minimal documentation required to develop should be built. I would argue that this approach will be disastrous for maintenance. I’ve seen groups have to totally rewrite a new system because it wasn’t maintainable. Some documentation isn’t for the team. It is for the next team.
You are right. As I said, the problem with many organizations' attempts at Agile is that they religiously follow the books. In turn, the books simplify the approach so that it is easily understandable and easily implementable, though if you want to scale it, you must understand how Agile works at a deeper level (understand agile). Then, you must be able to abstract it up a level or two and if you don’t have an experienced coach, you must be willing to accept some trial and error in your path to effectiveness.
This being said, agile is all about doing the least amount of work necessary to achieve the acceptance criteria. If documentation needs to be done, regardless as to whether it is end-user, regulatory, or interim step documentation, it needs to be incorporated into the stories as acceptance criteria and no story will then be considered done if its requisite documentation is not complete.
No comments:
Post a Comment