Saturday, December 13, 2008

Support the Agile Fringe

There is a bit of a controversy over the organization of the Agile 2009 conference. The conference will be organized in a number of functional areas. Unfortunately this may exclude talks about  work on the agile fringe, work that pushes the limits of agile.

David Anderson has written an open letter to the Agile 2009 organizers. There has been a lot of support. If you believe there should be a space for topics that do not neatly fit any functional domain, please support David's initiative by adding a comment to his letter.

Here is the comment I attached to David Anderson's letter:
Hi,

I am not currently an Agile Alliance member, and though I would like to do so, I won't be able to attend the conference.

Nevertheless, I would like to throw in my support on this one, for the following reason:

Creativity is a necessary prerequisite for agility. The creative process consists of taking information from different domains, and recombining the information in new patterns.

Agile itself originated this way: People with experiences from different domains came together, combined what they knew, and thus created a new domain, a pattern of knowledge that did not exist before.

Sticking to a fixed set of agile sub-domains excludes creativity from the conference. It turns agile into a closed system, and closed systems stagnate. When the agile movement stagnates, ceases to move, it will become unable to adapt and improve. Faced with new challenges, agile will not be able to cope.

I do hope agile will remain open, vital, and continuously evolving. The key to that, I
believe, is to embrace creativity, not isolate oneself from it.

Kind Regards,

Henrik Mårtensson
If you believe creativity and progress are important to the agile movement, now is the time to show your support.

Thursday, December 11, 2008

A Beagle with Cream Cheese, Please!

I stood in line waiting for my turn to order at a cafe when the lady in front of me ordered "a beagle with cream cheese". She got a bagel with cream cheese, and went away happy.

If she had asked a software developer to provide a beagle with cream cheese, she would have got it. Our requirements processes are usually set up to give the customer what the customer asks for, not what the customer wants, or needs.

Note that these are three different things: asks for, wants, and needs.

Agile software development represents a shift of focus, from providing what the customer initially asks for, to what the customer wants.

Unfortunately, if we build what the customer needs, the customer probably would not want it. There is also a significant risk that the customer does not need new software.

For example, many agile teams use Kanban boards, and keep track of tasks with Post-It notes. Suppose a customer comes to such a team with a similar task-tracking problem. Would the team just show the customer how the team tracks tasks, or would they build the task tracking software the customer wants?