Pols Consulting

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!

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?

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

Luke Hohmann has started blogging. Fantastic!

I like this observation:

One of the points that Don made in his presentation was that being a true visionary can, at times, be a curse. When a visionary holds too tightly to his or her vision, they are often overtaken by the world that is happening around them. Furthermore, a visionary can be a bit depressing, as no matter what someone else does, they claim that it is not good enough. And that is simply not true.

Ooooh, this year’s XPDay looks like it’s going to be a good one – it just keeps getting better and better.

Steve Freeman and I are running a session on various techniques for exploring customer requirements. It’s based on our experience in applying some of Dave Snowden’s and Luke Hohmann’s ideas on our recent projects.

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. This workshop presents techniques for working with customers and other stakeholders to help them understand the context and goals of a project or product. It describes a range of techniques such as “Speedboat”, “Product Box”, “Butterfly Stamping”, and “Give ‘em a jacuzzi” and runs two of them as exercises.

Nice phrase to descibe the way a team thinks for themselves (they take command). This is the opposite of some teams where the management what to control everything they do.

I stumbled across this the other day. Bill Strickland is amazing. All organisations need a Bill Strickland.  I recommend you give it a look.

http://stream.fuqua.duke.edu/Content/fuqua_events/2003/Strickland/Strickland.smil

You can find more about Bill at http://www.fastcompany.com/magazine/17/genius.html

I particularly like this observation:

“Artists are by nature entrepreneurs, they’re just not called that,” Strickland says. “They have the ability to visualize something that doesn’t exist, to look at a canvas and see a painting. Entrepreneurs do that. That’s what makes them different from businesspeople. Businesspeople are essentially administrators. Entrepreneurs are by definition visionaries. Entrepreneurs and artists are interchangeable in many ways. The hip companies know that.”

Some time ago Chris Stevenson and I wrote about our experience working on a legacy application.  Martin Fowler liked our approach and decided to call it a Strangler Application.

Brian Marick includes it in his recent blog discussion about the different approaches to dealing with legacy code.

I have been thinking about this a lot lately.  I have been working with a client where a strangler application would have been a good solution.  It was an almost repeat scenario from when we first applied the Strangler Application approach to a legacy financial trading system.

One of the key aspects of the original project is that we left the legacy application alone.  The legacy application was still maintained by the original team. A new team completed the replacement strangler application.  The rationale behind this was that the original team had repeatedly failed to address the legacy problems and was holding back the business.  A key problem was the team itself. The team appeared incapable of coming up with an alternative solution, but management did not want to change the team as they were the only people who knew how the legacy application worked.

The new client rejected the approach

We can’t do that! There is no way we can get the budget for two teams

Asking for more money in this way highlights the problems of the original team and the fact that the project management do not know how to fix the original team (and have not addressed it before).

I now realise a critical success factor of the original project was the way the Project Manager hid the cost of the strangler application by associating it against a different project that had spare cash available.

This is a real barrier to applying these ideas in this situation. I wish I knew an alternative way to make this happen (any thoughts on this would be welcome!).

Continuing on the theme of breaking the self imposed rules I heard a wonderful story about a team working in an environment that involved a customer requirement to provide an audit trail of all project design decisions.

This was a real rule.

Many teams would interpret this as a requirement to have lots of heavy documentation and associated traceability. This would have been a self imposed rule.

This team solved the requirement in a wonderfully low energy way. They simply attached a long roll of brown butcher’s paper around the room. Whenever people on the team made a decision, they made a note of it on the paper, dated it and signed it. This acted as a short term information radiator of team decisions. Once it was full, they rolled it up, marked it with the date range and filled in it the corner of the room.

The auditor loved it as it was quick and easy to see what was happening over time.

I had an interesting conversation while running an agile training course with Alistair Cockburn. He has a common theme running through his books – that agile is cheating legally to win.

When you explain Agile to people you often get the response, “but that’s cheating!”

Our conversation with the class was about which rules are real rules (i.e. those imposed by the customer, or legal bodies) and which rules are ones the teams have imposed on themselves without realising it? When you run a retrospective on your process, you are trying to find ways of making things better (which rules you can break legally!).

When you start thinking in terms of real rules and self imposed rules it really opens up opportunities. Try it as let me know how it goes.