Pols Consulting

I wanted to vent about spring, iop, too much xml, framework hell…. making testing difficult…. Then I discovered this link. A picture paints a thousand rants…

Java call stack – from HTTP upto JDBC as a picture

At long last, Luke Hohmann’s book
‘Innovation Games’ has arrived. I became hooked on Innovation Games when I read an early draft of Luke’s book. That seems so long ago!

A software group is best measured by its customers’ success. Understanding what they really need is critical, but customers are human too which means that they’re fallible. Customers can’t always tell you what they want because sometimes they don’t know themselves, so asking them to rank requirements or write stories might not be the best place to start.

The book is a collection of games you can play with the customer to gain a better understanding of what they need. Although the book is really about product management (working out what product a customer wants), I think these games are useful for agile teams trying to get a better understanding of what their customer wants.

Steve Freeman and I ran a really success session at last year’s XP day on this very subject.

Organise the Fit Tests around your iteration’s stories

I like to take small baby steps when I write software. It makes life easy. I don’t have to merge very much code, I get regular closure on what I’m doing, I don’t have to carry too much around in my head, and I can discard mistakes without loosing too much work.

Automated acceptance tests, such as Fit, can throw a throw a spanner in the works. I like to explore the problem by writing the Fit test with a domain expert before I start writing any code. I treat the acceptance test(s) as a definition of success. Before I start work on a new feature I need to understand how I will know when the Customer/Domain Expert is happy with what I have done. I flesh out the answer in the fit test (I often have several Fit tests exploring different aspects of the story).

Great, but Fit tests are course grained in nature. I typically make at least 20 baby steps (source code commits) before a story is complete. I don’t want to commit the Fit test before I start writing code as the Fit test will fail and break the build. Not good. I don’t want to wait until the fit test is complete as that will loose all the advantages of developing in baby steps.

Some teams use different directories to distinguish between the Fit tests that have been completed and should pass, and those that are currently being worked on. The tests get moved around when they have been completed. I guess that solves the baby steps problem, but I’ve never liked moving files around to indicate completion and it’s still hard to see how the Fit tests relate to the originating Customer Stories.

William Jones has a much nicer solution with his Agilifier project.

There is not much documentation at the moment (well, it is opensource!), so I will give you a quick overview.

• You group the Fit tests around the stories they are associated with. All the tests associated with a story are contained in a directory. You place the original story in the story.txt file. You simply add your Fit test files to the directory.
• You use test suites to make the distinction between the previously completed tests (i.e. we have broken something if they don’t pass – and should fail the build!), the tests associated with the current iteration (i.e. these provide a progress bar of the current iteration) and those tests an individual (or pair) are currently working on. The suites are simple text files containing the tests to be included in the suite.
• Agilifier runs the test suites and glues the story and Fit tests together in a nice html report.

Download it and give it a try. You should be able to figure it out from it’s own acceptance tests!

Chris talks about his work on applying real options on agile projects http://agiletoolkit.libsyn.com/index.php?post_id=121123. He also talks about our work on Business Value.

I was explaining the ideas behind burndown charts today. Tim Mackinnon et al wrote a great paper for the Agile Development Conference that I wanted to show them. I really like their simple approach. Sadly the conference’s web site is not longer around.

Fortunately Tim has a copy on his web site
http://www.macta.f2s.com/Thoughts/planning.html

A more indepth look at burn down charts can be found on Alistair Cockburn’s site:
http://alistair.cockburn.us/index.php/Earned-value_and_burn_charts

I will have to see if I can recover the other great papers from this conference. It would be a real shame to loose them.

Alistair Cockburn’s blog is back. Yippie. It’s not a traditional blog, it’s actually using a wiki that he’s using as a blog! Still, it has lots of strange and interesting stuff.

http://alistair.cockburn.us/index.php/Blog

I spotted this on information aesthetics. It’s a disk drive that changes shape to show how insync a data backup is with it’s source. What a great idea.

Here is a nice podcast from Jason Fried from 37Signals.com

He had an interesting spin on co-location. I always thought distance hurts, and having everyone working together in the same location was critical. Jason argues that if you can’t explain a design or a business strategy using IM or Skipe then it’s too complicated and you should choose something simpler. This made me re-think my views on this.

It’s a really interesting point of view. I have been mulling this over in my mind for a few days now. I wonder what impact people’s learning style has on this? I’m very visual, I really like being able to jump up and draw pictures with collegues around a white board. I wonder if Jason is more of a words person?

Write the test so it reads like a requirement specification and not a test

I was trying to explain a FIT test to a new colleage. It soon became clear that it had been written as a test. It didn’t convey the intent of what was required. Nor did it communicate why it did what it did. There was a lot of tacit knowlege in my explanation of what was going on. It obvioulsy failed to communicate the requirements. It did, however, test that a particular feature of the system worked! So, what is the purpose of a FIT test?

Brian Marick makes the distinction between Business Facing tests and Technology Facing tests.

A business-facing test is one you could describe to a business expert in terms that would (or should) interest her. If you were talking on the phone and wanted to describe what questions the test answers, you would use words drawn from the business domain: “If you withdraw more money than you have in your account, does the system automatically extend you a loan for the difference?”

A technology-facing test is one you describe with words drawn from the domain of the programmers: “Different browsers implement Javascript differently, so we test whether our product works with the most important ones.” Or: “PersistentUser#delete should not complain if the user record doesn’t exist.”

The FIT tests should be business facing, they are a communication tool with the added benefit being executable. FIT tests should explain the requirements so that people know what the system does.  The collection of FIT tests forms an executable requirement specification. They should not really be called tests at all!

Our FIT test was clearly written from a developer’s point of view. It was technology facing. Fit is probably the wrong tool for technology facing tests. I would much rather write these in a more developer friendly tool such as Java or ruby.

Norm Kerth gave a great talk on retrospectives at SPA2006.

I’ve been a fan of retrospectives for a long time. The interesting thing for me was Norm’s description of Kick-Off Retrospectives.

I typically do this when teams are formed for a specific project (and don’t stay together once it has been completed). They basically run a retrospective to set the scene for how the team wants to operate.

The subtlety I had missed is that you can use the future perfect tense when asking the questions. You can ask people to imagine that this is the retrospective at the end of the project and ask them “What was so good about this project that you would like to repeat on future projects?” This sets the scene for how the team want to operate.

While on the subject of retrospectives, here is an interesting article by Ester Derby on keeping retrospectives fresh