You are currently browsing the tag archive for the ‘documentation’ tag.
Tag Archive
Cards Don’t Build Software, People Build Software
December 8, 2008 in Uncategorized | Tags: agile, bpmn, communication diagrams, documentation, domain models, scrum, UML, use cases, user stories | Leave a comment
I’ve been reading/listening to a lot of chatter lately about where the tactical elements of SCRUM stop, and something additional is needed. I’ve seen and heard a lot of feedback indicating that the (purportedly) prescriptive components of SCRUM (story cards, SCRUM meeting procedures, backlogs, burndowns, etc.) are all replacements for things the PM used to do.
Cards Don't Build Software, People Build Software
December 8, 2008 in Uncategorized | Tags: agile, bpmn, communication diagrams, documentation, domain models, scrum, UML, use cases, user stories | Leave a comment
I’ve been reading/listening to a lot of chatter lately about where the tactical elements of SCRUM stop, and something additional is needed. I’ve seen and heard a lot of feedback indicating that the (purportedly) prescriptive components of SCRUM (story cards, SCRUM meeting procedures, backlogs, burndowns, etc.) are all replacements for things the PM used to do.
Seven
October 31, 2008 in Uncategorized | Tags: agile, agile analysis, ba world, bpmn, communication diagrams, documentation, domain models, project summit, rule of seven plus or minus two, scrum, UML, use cases, user stories | 1 comment
On Tuesday at ProjectSummit/BA World, I was invited to be moderator of “Agile Analysis: Can it Work at My Organization?” During and after that session I had numerous discussions centered around this recurring question: “What Should I Document, and What Can I Document?” There’s a common perception that on an Agile project, the only thing I’m permitted to write down is a User Story – the remaining communication occurs through verbal interaction. If Agile is all about effective communication, is it presumptuous to assume that verbal communication is the most productive? In 1956, George Miller proposed a theory that the capacity of a human’s short-term memory is seven plus or minus two things. This was proved, and has been proved and re-proved many times. To free up short term memory to make room for the next batch of information, I have four choices: discard it, pass it to someone else and be done with it, encode it in long term memory (this takes time), or write it down. On a project aimed at building anything larger than small and trivial, chances are that if you don’t write things down they will be lost or forgotten. So, the remaining question related to project efficiency is, “If I write information down, what form works best, what do I do with it once it’s written, and what should I do with it after we are done using the information?”