Does Agile mean less documents and meetings?

[Qunfeng Wang]

Create Document--->Review--->Revise--->Review--->Revise.....

Actualy I've implemented the function. But I need to obey the Process called "SOP100". Will this situation be changed in Agile Process?

Thanks.

[Stan James]

The combined values in the Agile Manifesto point to a preference to other forms of communication. A face to face meeting is a more effective way to answer questions and resolve issues than an exchange of documents. Frequent feedback and course adjustments are a more effective way to get high value software than rigid contractual agreements. And so on.

Agile and XP never say "no documentation". If somebody wants a document and is willing to pay for it, make it. But if you can find a better way to communicate, do that instead. Stop to think about the cost and value of the doc before making it.

One phrase I like from the agile crowd is "barely sufficient." If you do produce a doc, focus on what it is meant to do (____ reads this to learn ____ so they can ____), make it do that, and no more. I see lots of docs with a cover page with a logo, a table of contents page, a revisions page, sometimes 5 or 6 pages of stuff before anything of any value. The sheer number of wasted electrons and pixels overwhelms me.

[Pradeep bhatt]

Yes Agile means less documents. It means more testing and also more communication among team members, so meetings are not reduced. Meetings are daily standup are kept short because participants will stand and not sit.

[Frank Carver]

Adopting an agile approach may mean fewer documents, but really that depends on what documents you have now, and what documents you need!

As pointed out above. Agility is about making sure that the things which give the most business value get done first, and things which give no business value don't get done at all.

A document is just an artefact, like a java source file, or a configuration file, or a build script, or whatever. If it needs to be written, then write it. Just like the other artefacts, though: keep it under version control, test it to ensure it does its job, and be prepared to refactor it or eliminate it as soon as it is no longer useful.

[Qunfeng Wang]

Originally posted by Stan James:

......

I see lots of docs with a cover page with a logo, a table of contents page, a revisions page, sometimes 5 or 6 pages of stuff before anything of any value. The sheer number of wasted electrons and pixels overwhelms me.

That's absolutely what I am asked to do now! Everyone in the team should prepare such a document which is about 20 pages. It's quite interesting that everyone copys & pastes the documents created before to make up the 20 pages.

I've written a document about 2 pages to describe the how my module works. And I've written an email to tell everyone the steps I need to do to implemnt this module. Then I implement and test it. Do you think it's enough? I just think the "SOP100" process pushes me into a wrong way. But as an employee, I need to obey the policy.

[Stan James]

See if you can replace any of your docs with tests. Unit tests and acceptance tests can make great documentation of requirements and usage demonstrations. If somebody insists on a document, print the tests. Of course the document will soon be out of date and you can't run the document to see if it's true, but you have to keep the folks who write the paychecks happy some days.

[Scott Ambler]

You might find my article on Agile Documentation to be of value.

Agilists write documentation, it's just that we try to be as smart about it as possible. When we do write documentation we tend to be concise. We also tend to have "executable documentation" such as tests instead of static documentation such as Word documents. Big difference.

- Scott

[Jeanne Boyarsky]

Originally posted by Stan James:
If somebody insists on a document, print the tests.

I did this in grad school. We were supposed to hand in a list of test cases that we used. So I handed in the names of all my JUnit tests.

[Qunfeng Wang]

Hi Scott, I've read your article. It's great! Thank you very much.

I want to be an agile developer!

[Darya Akbari]

Hi Louis,

I searched the web for SOP100 with no success. Do you have a link for this ominous documentation standard

Regards,
Darya

[Peer Reynders]

Originally posted by Darya Akbari:
I searched the web for SOP100 with no success.

Smiley aside - I read it as a euphemism for a general, non-descript, process-heavy way of conducting business:

SOP - Standard Operating Procedure
100 (level) - Fundamental

[Darya Akbari]

Originally posted by Peer Reynders:
SOP - Standard Operating Procedure
100 (level) - Fundamental

Interesting, I never heard of that procedure. Who stands behind SOP? Is there a spec?

Searching for it leads to different explanations. The term SOP seems to be overloaded .

Aside of whether SOP is somehow mapping to Agile or not, I don't get what SOP is exactly .

Regards,
Darya

[Peer Reynders]

Originally posted by Darya Akbari:
Who stands behind SOP? Is there a spec?

That was my point - it doesn't have to stand for anything. It could be entirely made up or something that is only used internally in a team, department, or institution.

Quite often the term Standing Operating Procedure (SOP) is simply used to refer to "the way things are done around here" as it is known by the people who do the work - sometimes it may even refer to an internal memo or document - and it is often used in a denigrating manner.

Standing operating procedure

[Stan James]

Sometimes also known as S.O.B.

[Darya Akbari]

Originally posted by Peer Reynders:
Standing operating procedure

I read that link before but couldn't get lot out of it.

Originally posted by Stan James:
Sometimes also known as S.O.B.

Do you mean it stands for Standard Operational Bullshit .

After all, I can somehow understand Louis to get around this ominous SOP100 process.

Regards,
Darya

[Qunfeng Wang]

In fact, I know little about SOP(Standard Operating Procedure)100 too. There are SOP1,2,25.., and SOP100 is for Product Creation and Delivery Process.

It seems like the traditional waterfall process. In every step, some standard documents need to be created and appoved. The test cases and drawings on the whiteboard are impossible to be treated as documents.

[Peer Reynders]

Originally posted by Louis Wang:
drawings on the whiteboard are impossible to be treated as documents.

A digital camera and if you want to enhance the drawing use Whiteboard Photo- that usually does the trick.
Start talking about the opportunity cost of making nice clean drawings on expensive drawing software AFTER the meeting when the meeting clearly demonstrated that the artifact on the whiteboard was clearly good enough to communicate the intent - then somebody may start to get the message.

[Ilja Preuss]

Originally posted by Louis Wang:
The test cases and drawings on the whiteboard are impossible to be treated as documents.

Why?

[Qunfeng Wang]

Originally posted by Ilja Preuss:


Why?

Because we have standard document template. The sections are fixed:Scope, Overview,......

And we don't write unit test code now.

[Peer Reynders]

Originally posted by Louis Wang:

Because we have standard document template. The sections are fixed:Scope, Overview,......

Once you start using unit tests you can always add a comment header to each test that includes relevant JavaDoc information. Use that info to generate input files that are referenced in the documentation through documentation automation.

Of course this is not ideal because you are repeating information that can go out of sync - i.e. comments are always in the danger of going stale, though less so than other forms of documentation.