I saw a wonderful typo in a recent talk about Agile people being Barley Sufficient! That made me laugh.
Anyway, just in case you have not read Alistair’s paper describing Balancing Lightness with Sufficiency and being barely sufficient.
Alistair Cockburn has written an interesting article about the problems some people get into when they use agile techniques without focusing on delivering business value to the customer. I have also seen the exact same scenarios. I think this is a huge problem.
I’ve uploaded the slides from Steve Freeman’s and My talk at XPDay
http://www.pols.co.uk/papers/CustomerGamesV2.pdf
I really enjoyed the session. Here are some of the product boxes people created:
I particularly love the “official” Kent Beck endorsement!
Without any prompting everyone asked for free beer!
Bill Gaver gave an fabulous keynote at the recent XPDay conference. He talked about designing things for Ludic (playful) Engagement.
This included the Drift Table, a coffee table that enables people to slowly float over the British countryside from their own sitting room. The weight of objects left on the table control the slow drift of aerial photographs displayed in the table surface. This table suggests a ‘hole’ in the home connecting physical and virtual space. A display on the side of the table shows the location of the aerial image. See photos of the Drift table in use.
Check out this paper to find out more.
I bet you want one of those tables as much as I do!
I’ll be at xpday in London next week. It’s a great place to trade ideas and drink beer. Perfect really.
I’ve been running several two week “challenge” assignments recently and really enjoyed them.
This week I’m trying to prove to a company that they can automate lots of their 3rd party vendor acceptance tests. They’re spending vast sums of money on manual testing - any reduction in this would be a godsend.
The first application is a java web app. That should be easy. It turns out that it’s using lots of really strange javascript.
For example, the login form looks like this:
1 2 3 4 5 6 7 8 9 | <form id="login" name="login" method="POST"
action="security_check">
<input name="username"/>
<input name="password" type="password"/>
< !click this to submit! -->
<a href="#" onclick="submitForm('login',1,{'event':'login'});return false">
<img src="/some/image/path/login.gif" .../>
</a>
</form> |
The post action “security_check” simply returns an error saying you can’t post! Why would anyone subvert the standard web form process like that? They have some javascript called from an image link that submits the form. If you don’t do things in a standard way you can’t test your application using standard tools.
Httpunit could not parse the javascript. If I clicked the link it simply returned to the same page (due to the href=”#”). JWebUnit uses Httpunit under the hood, so was not really an option (although I did give it a spin). Selenium did not work as I could not change the deployed webapp (the selenium javascript needs to be served up from the same server).
Then I discovered the lovely JExplorer library from MIIK. It basically wraps the IE components so you can embed Internet Explorer in a Swing application.
It worked a treat! I can now automate all my acceptance tests using JExplorer.
I have always been frustrated at how slow ant is at running my tests. If I run my tests in Intellij it takes around 4 minutes to run 1300 tests. The same tests in ant take over 12 minutes.
This is not such a big deal when I’m developing as I run them all in Intellij. The problem is that the Continuous Integration server runs ant. If the automatic build takes too long following a commit, I will have started working on something else.
I was telling people this as a recent Agile Summer School that Duncan Pierce and I ran. Justin Forder did some digging around and found the magic forkmode attribute…
You normally fork a new JVM to run the tests since it isolates your tests from Ant’s environment (which places a lot of libraries on the classloader). The reason it’s slow is that the default behavior is to fork a new JVM for each test case class. That’s a lot of forking.
It turns out that Ant 1.6.2 introduced a new junit task attribute called “forkmode“. If you set it to “once“, Ant will fork a single Java VM for all your tests classes.
Fantastic, the build server is now running all the tests in 6 minutes (it’s not as fast as my development machine).
Thanks to Justin Forder for pointing this out to me. See Stefan Bodewig’s Weblog for more info
Rachel Davies, Steve Freeman, Duncan Pierce and I are running an Agile Summer school on the 18-12 august.
Each day is run using XP cycles with Planning Games, Stand-ups and Pair Programming. Workshops are followed by a clinic session that you can bring your coding problems along to for advice on resolving them.
More information can be found at http://www.AgileAcademy.net/summer/
I keep bumping into agile teams that do the popular techniques (such as TDD, pair and programming) but don’t get feedback from the real end users. In most cases they fail and the proverbial shit hits the fan.
They simply rely on their one on-site Customer. For commercial software (or companies that do not like developers and business customers talking to one another), a customer proxy (usually the product manager) is used instead.
The person playing the Customer role is one of the most critical. The fact that most teams only use one person means they a single point of failure. It does not matter how good the development team are, if they don’t build the correct software, the project will fail.
This can go on for months. When the end customers eventually do see the finished product, they rebel and complain that it does not address their needs.
I have been thinking how to improve this. I do not have any concrete answers…
I think the developers should spend time doing the work of real end users, or at least watching them where this is not possible (for a Pilot, Trader…)
They should socialiase together - it’s amazing how many issues can be resolved in a bar over a beer.
You want frequent releases to real users to get get early feeback. In may view, teams who say they are doing agile, but fail to ship early releases to end users are missing the point.
Preston Smith has written a pragmatic overview from of why Agile works. I particularly liked the reference to Donald Reinertsen’s research that showed:
If requirements are going to change, wouldn’t we be better off acknowledging this and building our processes to accommodate it.
