technojunk.net

Scaling Agile in Norway

admin — Mon, 28 Apr 2008 20:30:37 +0000

Our friend Lars invited us to Oslo this weekend to run a session for Miles on “Scaling Agile”. It is generally accepted now that agile methods work very well in these sorts of circumstances:

Small project
Co-located team
On-site customer
T&M or internally funded
Greenfield systems development

Unfortunately, we rarely get to work on projects like that! Most of our projects are more like this:

Big project
Distributed project
Multiple projects in the same company
Off-site customer
Fixed price contract
Product Development

The point of the talk was to discuss the challenges involved in scaling agile to work on these sorts of projects. The guys were mostly interested in distributed and fixed-price projects, so we focussed on that. Afterwards, I ran an Open Space session where the discussion centred around agile enterprise adoption, integration projects and tools. Miles are a really talented and enthusiastic group of people, so spending a weekend with them was a lot of fun. Thanks guys!

We’ll probably work on our session a bit and run it at a conference later in the year.

The most useful tool of 2006

manish — Wed, 27 Dec 2006 15:39:57 +0000

A colleague Rob discovered Google Coop - those clever folks at Google now let you create your own private search engine, restricted to search your own set of sites.

We created a search engine for our project, and loaded it up with all the Javadocs, HowTos, reference documentation and examples from all of the open-source libraries we use on a daily basis. It’s become a real time-saver, as you have exactly the right versions of all your framework and tool docs in one handy place, linked to off our project wiki. Nice!

xpday2006: Are we done yet?

manish — Wed, 27 Dec 2006 15:32:06 +0000

Ivan Moore’s session on agile estimation and tracking had some interesting discussion centred around the idea of using real-day estimates for iteration planning in conjunction with ideal-day estimates for release planning.

For me, this is one of the areas of agile that needs simplification. I always have problems getting people to understand the difference between release planning, iteration planning, ideal days, velocity, story points, gummy bears….

I’d like to explore the idea of using real days a bit more. I think they have something going for them - people actually understand what they are!

xpday2006: The Selling Game

manish — Wed, 27 Dec 2006 15:15:33 +0000

Joshua Kerievsky’s Keynote was all about selling, namely selling the benefits of agile to large organisations. He made some interesting points, which I’ve captured here:

Coaching can be repetitive and exhausing when you try to scale it up to multiple teams. There’s also issues with inconsistency and quality as different coaches issue different advice. CelecoxibRelax. Lowest Prices and Great Service. Online Celecoxib Compare Celecoxib prices from every licensed pharmacy & save big. Here’s how I cured my acid reflux. As a solution to this Industrial Logic have started using eLearning on topics such as TDD, to help scale agile learning to large organisations. An interesting idea to get people started, although of course you can’t learn everything from a screencast!
Metrics are a good way of answering objections to agile practices. Larry Putnam’s work has been at the forefront of this area for some tim Free shipping on all orders. Accredited Canadian Pharmacy with savings up to 80% on medications like Cozaar. Online Mevacor Free shipping. Find a better price and we’ll beat it. e.
Rather than selling the benefits of an agile practice, try selling the risks of not doing CAVERTA - generic viagra; What is Caverta. Generic viagra caverta. Online Caverta cavertaGeneric Vigara, Kamagra, Cheap Generic Viagra Online at your Fingure Tips. How is Caverta generic Viagra different than Pfizer’s Viagra. it.
Try filiming the XP team at work and then showing it to the rest of the organisation to help dispel any myths and objections about XP.

xpday2006: Resistance as a Resource

manish — Wed, 27 Dec 2006 14:58:58 +0000

In Lasse Koskela’s workshop entitled Resistance as a Resource, we played a game which explored the concept of effectively dealing with resistance. You need a group of people, four sets of coloured cards and some markers. The coloured cards each represent one of:

A move consists of taking an appropriate colour card and writing on it either a form of Change, a form of Resistance to that Change, a possible Reason for the Resistance or finally a possible Response to that Resistance. Moves can be played in any order by anyone. Here’s a picture of one of the areas we explored - Fixed Price Contracts:

So, what was this all about? As a consultant, you often come across resistance to new ways of working. For example, introducing Pair Programming is often met with resistance from managers who don’t understand why we are doing it. I sometimes find myself trotting out the same responses to this sort of resistance, without really thinking about it.

I thought the game was interesting because it made me focus on exactly what is the reason behind resistance, rather than making assumptions about it. I think you could adapt this game to get some interesting results in Retrospectives.

xpday2006: Awesome Acceptance Testing

manish — Tue, 05 Dec 2006 21:33:41 +0000

I had fun at XPDay this year. It felt less “extreme” than in previous years, as people seemed to focus on pragmatic advice and techniques rather than evangelism.

One of my favourite sessions was Dan and Joe’s Awesome Acceptance Testing. They identified 5 aspects to any acceptance testing regime:

Automation - the tools and frameworks you use to automate bits of your application and tests
Vocabulary - the ubiquitous language you try and create in your tests
Syntax - how you express the vocabularly in a test
Intent - what is the behaviour you are actually trying to test
Harness - the tools and framework you use to run your tests and report on them

In addition, they identified four roles (or hats) that people involved in the development can play (or wear):

Customer - Identifies requirements
Analyst - Works with Customer to understand requirements
Tester - Works with Analyst to nail down the scope of requirements and decide what “done” means for the requirement
Developer - Works with the Tester to break the requirements down into simple steps that can be written as an acceptance test (monkeyfication)

For me, the most interesting (and therefore hardest to get right) aspects are the vocabulary and intent. A good suggestion that is easy to implement was the “Given, When, Then” vocabulary for expressing acceptance criteria. It works like this:

Given some preconditions
When some event happens
Then some outcome occurs

For example, a test that a bank overdraft fee is charged might be expressed as:

Given an account with $100
When I withdraw $120
Then the account balance is $-122 because an overdraft fee is charged

It’s no co-incidence that JBehave uses exactly this syntax for expressing tests. Despite the really out of date website, it looks like JBehave is close to being a 1.0 release, so I’d like to have another go at using it on a real project. Lift looks like another interesting framework that could be useful for writing acceptance tests for a web application.

The message I came away with was that acceptance tests are all about having a shared understanding between developers, testers, analysts and customers of what “Done” means. This is why expressing the vocabulary in a way that makes the intent clear is so important. Of slightly less importance is whether the tests are automated. As always, you need to be pragmatic about what tests you can automate and when is the right time to do so.

Depth Of Field

manish — Sun, 19 Nov 2006 21:20:46 +0000

On a recent trip to Rhodes, I finally got a chance to experiment with the Depth of Field settings on the 350D.

Here’s a shot of Rhodes Old Town (a world-heritage site) with a reasonably high depth of field, so that as much of the image as possible is in focus. To increase the depth of field, the aperture had to be reduced by increasing the lens’ f-number. This reduces the amount of light entering the camera, but still gives a clear shot on a bright day like this.

In contrast here’s a a shot of the old fortifications by the marina, taken through a crevice. I’ve opened up the aperture to decrease the depth of field, so that the fortifications are in focus but not the crevice.

And here’s a dog that looked bored…

Presenting at XPDay

manish — Sun, 19 Nov 2006 20:30:46 +0000

Thomas and I will be presenting our session “Against All Odds” at XP Day 2006 on November 28th. It’s an experience report on Agile Transition, where we will mainly be talking about:

Legacy Technology
Fixed Price Contracts
Offsite-customers
Product Development

If we ever figure out how to cram that lot into our 30 minute slot, that is!

Winking excellent

manish — Sun, 19 Nov 2006 20:20:56 +0000

A good practice in any project is to showcase working software to your stakeholders every iteration. It’s even more important when developing a product, as the feedback and discussion on the features you have implemented really does drive out what to implement next.

Recently we were looking around for a tool that we could use to record one of our showcases as a Flash demo. Not only does it give stakeholders who missed the meeting an opportunity to see what was demoed, it also gives us a record of how our software evolved every iteration. Nice for posterity.

We used Wink, a freeware tutorial and presentation creation program. It’s a truly superb piece of software that allows you to capture a windows session, annotate it with labels and back/next buttons and then render the whole lot as a Flash movie. It’s extremely easy to use - we put together several Flash demos that showcased different features of our product in just a few hours. Excellent!

Automated Testing for Ajax Applications - Part I

manish — Wed, 01 Nov 2006 09:19:20 +0000

As my project has been doing some Ajax work recently, we’ve been looking around for a good way of acceptance testing our Ajax components. Being an agile project, we break our requirements up into stories and write an acceptance test for each story. The acceptance test verifies that the acceptance criteria in the story are met, i.e. that we’ve built what we thought we would. They provide feedback on the external quality of the system, as opposed to unit tests which provide feedback on the internal quality.

In the past I’ve written acceptance tests that test an application by interacting with it’s user interface and making assertions on the data that gets displayed. However, this kind of acceptance testing can be quite brittle. Tests break as a result of UI tweaks and the team has to spend time fixing these so-called failures. For me, the cost of maintaining these types of tests is too high to justify writing them.

So I was pleased when we found that the excellent Stripes web framework we are using has a built-in mechanism for writing acceptance tests that don’t go through the UI. Instead, they test the layer directly underneath - this is the action layer that is common to any action-oriented web framework.

Our acceptance tests simply instantiate and use a set of action beans to simulate a user interacting with the application. They pass parameters into the action beans and make assertions against the data that gets returned from the action beans. Typically, an Action Bean returns a POJO to encapsulate the data that needs to be displayed on a web page. The POJO is used by a JSP to render the data for the page. So, this architecture is very simple to test.

We’ve gradually been building up a set of acceptance tests for our actions that have so far been fairly traditional - each action bean has been responsible for rendering all of the data on a web page.

Now we’re looking at doing the same for action beans that are used by Ajax requests. As Ajax requests are asynchronous, they aren’t typically used to render an entire web page, but rather a portion of a page. The request is initiated by some JavaScript in the browswer, which handles the response and dynamically updates the page content accordingly.

This presents a challenge for our acceptance tests. Rather than our actions being able to forward to a JSP to render their data, they now have to stream their data directly back to the browser.

There’s a few options for what format to use for this data.

JSON is a great choice as it is can be evaluated natively by the JavaScript engine running in the browser. We use json-lib to convert Java objects to and from JSON. The result is a clean approach to Ajax that is easily testable. Here’s an example.

Say we have want to use an Ajax request to lookup an address given a house number and a post code. There’s various back-end services that can be used to do the lookup, but here I’m going to focus on the corresponding web action and Ajax integration. My action bean takes two request parameters - house number and post code. It uses the back-end service to lookup a matching Address POJO and then uses json-lib to convert this to a JSON response to stream back to the browser.

public class AddressLookupActionBean {
    // Request Parameters
    private String houseNumber;
    private String postCode;
    public Resolution lookupAddresses() {
	// lookup matching address
        Address matchingAddress = backendService.lookupAddress(houseNumber, postCode);

	// convert to JSON using json-lib
	String json = JSONSerializer.toJSON(address).toString()

        // stream the JSON directly to the browser
	return new StreamingResolution("text/javascript", json);
    }
}

In the browser, you would typically use a library to deal with the business of making Ajax requests. In this example, I’m using the excellent Prototype library to make the request. I call the addressLookup function in response to the user clicking on a button.

function addressLookup() {
    // get the houseNumber and postCode fields from the document and create a hash
    // use Prototype's helper functions for accessing the houseNumber and postCode
    // fields in the document
    var params = $H({houseNumber: $F('houseNumber'), postCode: $F('postCode') });

    // build the url that we will invoke via Ajax */
    var url = '/mos/address/AddressLookup.action?' + params.toQueryString();

    // invoke the url and on success call the specified handler function */
    new Ajax.Request(url, {onSuccess: handleAddressLookupResponse});
}

function handleAddressLookupResponse(xhr) {
    // eval the JSON response to create a JavaScript object
    var address = eval(xhr.responseText);

    // now we can access the properties of our Address POJO directly in JavaScript
    $(line1).value = address.line1;
    $(line2).value = address.line2;
    $(line3).value = address.line3;
    $(line4).value = address.line4;
    $(country).value = address.country;
}

And that’s all there is too it! The addressLookup function makes the Ajax request to the action bean, passing the house number and post code as request parameters. The Ajax response is handled by handleAddressLookupResponse. The nice thing about JSON as data format is that it can be evaluated directly by the JavaScript engine in the browser, making all the properties of the Address POJO available in JavaScript.

Writing the acceptance test

Following our model for acceptance testing action beans, we can use json-lib to write an acceptance test for our AddressLookupActionBean. Here’s an example of a test:

public void shouldReturnExactCustomerAddressWhenHouseNumberAndPostcodeSpecified() {
    // Invoke the AddressLookupActionBean and get the JSON response
    // How this is done will be depend on your web framework
    String json = ....

    // Use json-lib to convert the JSON into a Java DynaBean object
    DynaBean address = (DynaBean) new JSONSerializer().toJava(json);

    // Now we can make assertions against the returned json
    Assert.assertEquals(address.get("line1"), "expectedLine1");
    Assert.assertEquals(address.get("line2"), "expectedLine2");
    Assert.assertEquals(address.get("line3"), "expectedLine3");
    Assert.assertEquals(address.get("line4"), "expectedLine4");
    Assert.assertEquals(address.get("country"), "country");
}

So now we can write an acceptance test that bypasses the UI and tests that our ActionBeans are returning the expected JSON. In Part II, I will delve into more detail on how we can write tests for the JavaScript code in the browser.