Monday, June 30, 2008

To document or not to document, that is the question.

What is worthy of committing to storage? Information? Speculation? Knowledge?

I believe that there's a continuum at play here, along the lines of :

{speculation->information->knowledge->...}, where speculation is raw, unverifiable postulates, information is speculation transformed by direct oberservation and/or experience, and knowledge is information so well understood that it has become the currency of wisdom.

So, what's the good agile minded person to do?

Documenting speculation is the basis for heavy-handed methods and is mostly waste.

Documenting knowledge seems a futile activity that seeks to transfer understanding from one mind the the next.

So, is information the answer, dear Occam?
Oh, and for a facinating read from which some of my opinion is based, see Josip Pajk’s article, here.

Thursday, June 26, 2008

Beware of hiding requirements as tests

User stories are beautiful things. Details concerning the user story, when expressed as tests, are precious gems adorning the beautiful thing.

But one must take care to not let the tests be a requirement in their own right. Those tests should circumscribe, limit, and clarify the story, just the story, and nothing but the story. If they do more than that then one runs the risk of hidden requirements, and that is evil. Remember, the Principle of Least Astonishment applies to all parties involved in the endeavor.

Edit:  It's 10/13/2011 now.  I've changed my mind.  Tests ARE requirements.  Requirements ARE tests.  They are the same thing.  If a test, especially the Acceptance Criteria alluded to above, describe requirements that would otherwise be missed, Rejoice!

The question is not one of hiding requirements, it is of size.  I've learned that Epic Stories are beautiful ways to manage large amounts of information.  Often the A/C for an epic are stories in their own right.  That isn't something to avoid, it is something to embrace.

Friday, June 20, 2008

The Principle of Denial of Pain, and when to suspend it

The best practitioners I know, both technologists and otherwise, wish to deny customers their pain. In the way that Eric the Phantom of the Opera was driven to make the Music of the Night, these Best Technologist are driven to make virtuous systems, small on pain, for users and fellow technologists. I call this the Principle of Denial of Pain.

But pain is often educational, even medicinal. When we become aware of this phenomenon of our craft, we immediately incur the responsibility of determining when to suspend this Principle for the educating and medicating of our charges.

It is often hard to do, especially if you are in a coaching role. My friend and mentor Ken Howard recently described this same concept like this:

Consulting tip of the week #27: Occasionally you just have to stand by and allow mediocrity to happen -- This can lead to opportunity. (Also see "It's more fun to build a whole house of cards, rather than trying to keep someone else's house of cards from falling.")

So true.

But, you must accept it when you sense it, and you must act upon it when it is time, or you are robbing your charges of valuable, and lasting, lessons.

When do you suspend it? When do you "let the pain flow" for the hope of a valuable and lasting lesson? Well, the times are manifest, but here are some I've personally experienced:

  • When you've skillfully made a case for something, but the Team or person is unwilling to accept it nonetheless. Example: Actuals are an important measurement.

  • When something is complicated to explain, and in doing so you may get some one's back up (anger, offend). Example: We need to use a tool like Fogbugz to track our defects, because index cards won't work.

  • When someone won't accept a Principle for the sake of comfort or a lack of courage. Example: We must provide this feature (support for Leave of Absence) or the customer won't use the system - violated Simplicity- the art of maximizing the work not done.

What are some of yours?