Guild Blogs

My co-worker Dustin pointed this post out to me with the following addition.

Axiom VI: Testing? What testing?

See
http://www.icspi.com/
http://www.icspi.com/conferencepresentations.htm#MAGWayne

http://www.agilitas.com/products_netinspire.aspx

Scott Hanselman has started a podcast called HanselMinutes to talk tools and utilities. Episode #4 on Continuous Integration caught my attention because of 2 names mentioned during the discussion of the Ruby Watir library. Both Dustin Woodhouse and Travis Illig got mentioned because of tools they have written to integrate the Watir functionality at development or test time. Travis wrote RubyTestExecutor which hooks Ruby/Watir scripts up with NUnit. Dustin wrote WatirNUt which is a utility that creates a portable, testable NUnit binary wrapper around Watir test scripts and supporting files.

These two individuals and their tools are interesting to me because they both work on teams I manage and I'm excited to see my guys pushing the envelope.

Scott was also kind enough to mention me as one of the local XP experts (my 30 seconds of podcast fame).

http://db.sao.org/calendar2/event_description.htm?eventID=11/30/05

Agile software development is a conceptual framework for undertaking software engineering projects. There are a number of agile software development methodologies, such as those espoused by the Agile Alliance, a non-profit organization.

Most agile methods attempt to minimize risk by developing software in short timeboxes, called iterations, which typically last one to four weeks. Each iteration is like a miniature software project of its own, and includes all the tasks necessary to release the mini-increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an agile software project intends to be capable of releasing new software at the end of every iteration. At the end of each iteration, the team reevaluates project priorities.

Join us as two experts from the developer’s world and one from university will present their findings on agile development. The goal is to raise awareness of some issues not widely known by the systems development community. Speakers at this event include Ward Cunningham of Cunningham & Cunningham, who is one of the Agile Alliance founders, Wayne Allen of Corillian and Gregory Rose of Washington State University – Vancouver.

For those of you in the Portland, OR metro area you might be interested in attending the SAO Developers SIG on Wednesday Nov 30, 2005 at 7:30am. The topic will be Agile Development - The Academic and Industry Perspectives. I will be sharing the stage with Ward Cunningham and Greg Rose. My topic will be "The Agile Customer".
Hope to see you there.

Recently I have run into a number of people, both employees and consultants who can’t seem to separate themselves from their work while on vacation. This behavior is extremely mystifying to me. A related phenomenon is people who won’t/don’t use their vacation. I’ve identified 4 personalities that exhibit these tendencies.

• William the Worker doesn’t have a separate identity from his work identity and feels lost doing something different than work tasks.
• Essential Ellen believes that without her things will fall apart.
• Charlie the Consultant feels the need to work wherever he is because of the financial pressures of hours not worked being hours not billed.
• Hacker Helen loves her work so much she’d rather do it that anything else and typically works at home after work for "fun" regularly and vacations are no different.

Are you William, Ellen, Charlie or Helen? How do you justify working on vacation or not taking your vacation?

Hosted by Pete Behrens the Agile Executive. Go check it out.

One of the things that often happens when the product owner is technically savvy is that they start writing solution stories. That is they specify how something should be done technically rather than what should be done.

For example here is a story that states specifically how the task should be completed (solution):

Partition the customer history table horizontally

This story has been written by a customer who either knows a lot about physical database performance tuning or has talked to someone who does (or a least someone who tossed out a possible solution).

A better story that gets to the real business need (performance) is:

Ensure that saving updated customer information takes no more than 2 seconds on average

By knowing what the need is the developers can look at the whole system to see why saving the customer is taking longer than 2 seconds. This gives the developers latitude on how to solve the problem rather than boxing them in. In this particular case the real solution was fixing some logic in the trigger and adding an index.

What Make a Good Story?

Bill Wake has an article on the characteristics of a good story. He uses the acronym INVEST:

I	Independent	Stories are easiest to work with if they are independent. If they are independent we can schedule and build them in any order. This allows us to select stories with the highest value without worrying about all the expensive, low value dependent stories.
N	Negotiable	Negotiation is a key ingredient of agile development. Remember that agile methods are typically scope variable. That is the time line is fixed (iteration length) and the quality and scope are varied. A story is a placeholder for discussion. We need to be able to split, combine, tweak, clarify, etc stories at any time.
V	Valuable	Stories need to have real business value to the stakeholders. Typically this is the customer although there are other stakeholders (including the development organization). I like to see all stories expressed in ways that the primary stakeholder can understand the value provided by the story. The definition of "value" can vary somewhat from project to project and organization to organization.
E	Estimable	If a story can't be estimated then the customer can't derive value or assign a priority to it. We don't need a precise estimate or a guarantee that the estimate will never change. But we do need a good enough estimate that is as accurate as current information allows.
S	Small	Having small stories is a result of estimable and negotiable. The larger the story the harder it is to estimate, the less flexibility in negotiation. Each team has a "right size" story which tends to be in the several hours to several days ranges (in ideal time). Stories larger than this tend to fall into the "I don't really know" category.
T	Testable	Stories need to be testable, otherwise how do you know the story is complete?

For more info on how to write better stories see Mike Cohn's book User Stories Applied or look at the sample chapter.

Aren't there Any Exceptions?

Of course there are. Most projects have constrains of some kind which are technical in nature. I.e. "Must support Oracle and MySQL" or "all logging will use our custom Log4Net appender". These are definitely solutions, but generally apply to all (or most) stories so I track them separately. I've heard of others using different colored cards to visually indicate the difference between feature stories and constraint stories. I also like to make a note on my feature stories if there is some particular reason to pay attention to a constraint, at least until the team gets a feel for where the constraints apply.

Solution Stories in the Wild?

What are the best examples of solution stories from your experience and how would you rewrite them to be "real" stories?

Agile principles at work
So which agile principles are at work in correcting this smell?

• Developers create & estimate tasks
• Developers self select tasks
• Customers write good stories