Pols Consulting

These are fantastic.  See the full set on http://www.redbubble.com/people/Balakov

David Anderson gave a talk about kanban at XTC a few weeks ago (11th March 2008).  David’s pictures of  projects using kanban struck a chord with me.

My current project is split across multiple locations (well, countries!) and we keep track of what we are doing in Jira.  Jira is great for tracking and chunking work into releases, but it wasn’t highlighting our process bottlenecks.  We’d been caught out a couple of times by juggling multiple streams of work and having too much work building up in UAT.

I emailed David’s slides around the team and asked people if they thought the kanban view of the project would be helpful. The technical people thought it was a great idea, but the business people couldn’t see the point - they already had this information to hand and did not think it would be worth the effort.

One of the guys (Paul Allton)  did a little experiment using ruby to automatically create a kanban work-in-progress view of our existing jira data.  It’s gone through a few iterations, but this is what it looks like now:

Taking the kanban picture to the standup was fascinating.  The people who thought it was unnecessary suddenly became animated about the bottlenecks. This picture makes it very easy to see the state of the project and where people need to spend their energy. 

The poor man’s kanban (because we’re not really doing kanban, and it would be much better if we had a physical board) has proved very popular with the team.  

I enjoyed reading Keith Braithwaite’s post on tests and gauges. I like the way Keith uses the the metaphor of gauges in metalwork to describe Fit style tests:

You don’t work anything out from a gauge.  What you do is apply it to see if the workpiece is within tolerance or not.  And then you trim off, or build a bit up, or bend it a bit more, or whatever, a re-apply the gauge.  And repeat.

I agree with Keith.  The fit tests I write are business facing and for the benefit of the business customer.

On a recent project our customer got so enthusiastic about our fit tests he got extremely upset when I implemented a story without a fit test.  He refused to let the system go live until we had the fit test in place.

The story in question was very technical and involved sending a particular xml message to an external system. We just could not work out what a fit test would look like for this type of requirement.  Placing the expected xml message, with all it’s gory detail,  in the fit test would not have been helpful as this is a technical artefact and of no interest to the business.  We could not work out what to do.  The customer was not around to discuss this so I just went ahead and implemented the story (very naughty!).

What the Customer wanted was to be sure that we were sending the correct product information in the xml message.  To resolve the issue, I suggested that we have a Fit test that shows how the product attributes get mapped onto the xml message using xpath; although I still thought this was too technical for a business user.

We gave the Customer a couple of links to explain what xpath was so he could explore if this was a good solution for him.   To my amazement, he was delighted with xpath (I now know who to turn to when I have an problem with xpath) and filled in the fit test.

The interesting bit for me (and why I’m posting it on the blog) is that as soon as he knew what the message looked like and how it was structured, he realised that it did not really support the business - we were sending information that was outside our scope of our work and should have been supplied by another system.  He was also skeptical about the speed the external team could add new products due to the complex nature of the xml.

Most agile people I tell this story to think we have the “perfect customer”!

No one thought it was a bad idea to run acceptance tests on the live system.  What could possibly go wrong? Everyone knew that orders for “Mr Test Test” and “123 Test St were not real orders!

That is, everyone except the marketing department.

I though it was worth sharing some experience we are having speeding up our very slow build from 1 hour plus to around 10 minutes.

In the past we have spent a lot of time exploring why our tests are slow and have never really come up with a good solution. We’re continually extending the test suite, so any savings we make don’t last that long.

The unit tests are quick (~40 seconds), but it’s the acceptance tests that start up and run the application that are painfully slow.

We decided to group the acceptance tests into small logically grouped test suites that can run in 10 minutes or less. Then we added build agents (each running on a separate machine), so we can run as many of these small test suites in parallel as we can.

Every time the build gets too slow we break them down into smaller chunks and add another build agent. Hardware is cheap so it’s easy to sale this solution.

So far this is working really well.

Mike Hill and I are running a session at XPDay 7 on the subject of how Agile software development teams should collaborate and work with their customers.

When an agile team works with their customer, how do we ensure we speak the same language? How do we incorporate the business domain concepts into our code? How do we know we’ve got it right?

In this workshop we will explore how people approach these problems, what you’ve tried and how it worked out. We hope to reflect on our collective experiences and learn how we can improve.

It’s a great conference. Hope you see you there.

I know that journalists use pseudonyms on facebook to research a community,  but the BBC is reporting that busy people are paying someone to represent themselves online as they need a presence, but don’t have the time.

I met somebody the other day who told me that online networking was so important, and he didn’t have the time, he was paying somebody to be him online. To blog, network, post etc . £1,000 a month too.

“This guy is a busy entrepreneur and he says that wherever he goes, people marvel at the energy he still manages to put into blogging and networking - and he then tells them it is all being done by a guy he pays to do it.”

I feel an off shoring opportunity coming on!

Steve Freeman had an interesting post in which he wondered if there was a tendency for geeks to be B-people?

Well, I hate going to bed and hate getting up in the morning. So it must be true! It could also explain why there is so much bad software in the city (they tend to start really early in the morning!)

I have just discovered an old post by Jim Shore (http://www.jamesshore.com/Blog/How-I-Use-Fit.html) about how he started out using FIT. He started out by switching from a unit test driven approach to a more story driven development approach.

I encountered a big problem with this approach, though: I stopped doing good TDD. “Storytest-driven development” blurred the line between Fit and unit tests. The “STDD” cycle largely replaced the TDD cycle and, as a result, I had far fewer unit tests than normal.

That was a problem because Fit examples are not unit tests. Fit examples are just that: examples of a business rule in action, from a business perspective. In TDD, I write tests for every line of code that can possibly break. In my Fit examples, I try to talk about every possible business case. That’s a bigger net than TDD, and without TDD, my code wasn’t well tested.

I had the exact same experience. I also found that the design suffered due to the lack of tests (it did not force me to refactor as often as I should) and it had a detrimental impact on my productivity. Story tests are larger in scope and take longer to run. Unit tests provide a much faster feedback loop when you break something.

I wish I had read this before I started using FIT.