I spent two days recently enjoying being in Cornwall attending and presenting at the first Cornish agile conference Agile on the beach.

The event was a great success with world class speakers (you can see the full list on the website), and an actual beach party on the thursday night with a band (All the fires) and hogroast. The organisation was also superb, co-ordinated by Event cornwall. From the attendee perspective, It was great to meet and talk to such a good turn out of passionate developers and companies.

I have some involvement in the genesis of the event. My dad, Mike Barritt is working for a company called Oxford innovation who are helping companies in cornwall to develop and grow. At some point a while ago, I had connected him with Roger Marlow and suggested that a good way to help everyone get into agile was to host a conference. A year or so later, and I found myself down in cornwall amongst some of the people I have massive respect for in the industry. The event has also had a great sponsorship and support from ThoughtWorks, which makes me really appreciate what an amazing company it is to work for.

Some highlights for me were hearing Mary and Tom Poppendieck talking about Lean Startup and running a value stream mapping workshop, Kevlin Henney reminding us all that software should be FUN, and Jason Gorman firing us up to keep our focus on quality codemanship and staying out of the “Anaerobic” zone when developing code. It was also great to see everyone getting down to the code in a dojo with Jon Jagger, to have the fantastic Rachel Davies helping people with common agile adoption problems, and have Steve Freeman talking about TDD. Quite a line-up!

Unfortunately I couldn’t attend my colleague James Lewis’ talk as we were speaking at the same time, but I have seen the slides and it sounded awesome, so I hope to catch it another day. Parallell to us was Roger so I missed his talk too, but it sounded like he had a good time.

I managed to make a presentation myself, talking through some of the experiences I have had as a consultant working for ThoughtWorks, and in particular some developer practices. I over estimated the amount of material I was trying to get through but did manage to get to a few key points! For those who attended a couple of interesting jump points to follow up might be Martin Fowler on Feature Toggles, gource (the tool at the end), and The continuous delivery book by Jez Humble.

All in all, the event was a great time and I hope that it signifies the beginnings of putting cornwall on the world stage for software development and high tech companies!

I recently (Friday 14th May 2010) gave the closing Keynote at Agile North, a one day conference held up in Preston.

The talk was loosely based around a metaphor of mountain climbing and playing with the analogy of being a consultant on an agile project being like a mountain guide. The idea is that someone who is a mountain guide has many years of experience climbing and coaching people on the mountain.

The talk I think was well recieved and generated quite a bit of interest from people, I think because we were talking about real experiences on our current project.

I co-presented with Mark Crossfield who is the Tech Lead on the team I am Coaching at our current client, AutoTrader, and I felt it was an interesting balance between my “Guide” view and his experience leading a team into an Agile project for the first time.

We covered five short stories about our experiences on the project.

• Safety First – going beyond CI to pipelines
• The Walking Skeleton as a metaphor for iterative feature delivery
• Evolution of the codebase
• Collective Design
• Telling the story of the code

The Slide deck is up on slideshare and the talk can be viewed here.

At some point they promise to put up the video of the event at which point I will update this post.

What is the key focus of agile practices ?

To me, it is Delivery of working software.

What do we mean by “delivery” ?

Delivery is software working in production. Even stronger, software that is being used in production.

What does “working” mean ?

This may depend on the currency you have for measuring success. Usually it means improving the bottom line of the company. It might be indirect such as generating interest for a website or simply getting a product delivered at all.

My definition of “Lean” may not be entirely accurate (I’m not an expert) but from my understanding, taking a lean approach, writing the code is only part of the story.

Lean tells us that there is no point in having a backlog of artifacts in the factory if we can’t get them to the customer. We need a good distribution system so that artifacts are pulled down the pipeline as quickly as possible, right from where they are consumed.

For software this means the production environment. Really the production environment, not staging or the ci environment or a dev box.

Setting up the distribution pipeline is as important as any other part of the project. It needs to be automated, reliable and responsive (i.e. as soon as a new feature is required it can be sucked into production as soon as its completed)

Once your delivery pipeline is in place everything else becomes smooth. People stop worrying that they are not going to receive new features quickly and so they feel more able to focus on what the need right now, in smaller chunks which means the delivery system flows more smoothly and the features are produced in a more responsive way.

He was interviewing Vinod Khosla who was talking about investing in the future. He said that he nevers invests in things that are going to succeed and then this:

“The willingess to fail gives me the power to succeed”

This is a great quote, especially relevant to Agile software development philosophy.

Before starting i uninstalled the mono i had already:

#!/bin/sh -x
#This script removes Mono from an OS X System.  It must be run as root
rm -r /Library/Frameworks/Mono.framework
rm -r /Library/Receipts/MonoFramework-SVN.pkg
cd /usr/bin
for i in `ls -al | grep Mono | awk '{print $9}'`; do
rm ${i}
done

First i could search for the mono package by typing

$ port search mono

To begin with this did not show the right version so i did :

$ port selfupdate

This checks for a new version of port and updates its list of available software.

now i see:

coco:~ Jim$ port search mono
mono                           devel/mono     2.0          Implementation of the .NET Development Framework
mono-addins                    devel/mono-addins 0.3          Mono.Addins is a framework for creating extensible applications
monodoc                        devel/monodoc  2.0          Documentation for the Mono .NET Development Framework
monotone                       devel/monotone 0.41         A distributed version control system
mod_mono                       www/mod_mono   1.1.16.1     an Apache plug-in for hosting the Mono System.Web classes
coco:~ Jim$

so all good, i ran

port install mono

but get :

darwin_stop_world.c:307: error: 'ppc_thread_state_t' has no member named '__r31'
make[3]: *** [darwin_stop_world.lo] Error 1
make[2]: *** [all-recursive] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

A quick search on google brought this:

http://lists.macosforge.org/pipermail/macports-tickets/2008-February/005279.html

The instructions here talk about editing this darwin_stop_world.c file and changing some constant values. They give the path to the file for an older version but a bit of ls ing turned up the new folder:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_mono/work/mono-2.0/libgc/darwin_stop_world.c

Ok, so now the tricksy bit…

The instructions in the above link talk about some constants not set up correctly. On the line wher ei saw my exception, it was referring to the following bit of code:

#elif defined(POWERPC)
#if defined(_STRUCT_PPC_EXCEPTION_STATE)
	lo = (void*)(state.__r1 - PPC_RED_ZONE_SIZE);

	GC_push_one(state.__r0);
	GC_push_one(state.__r2);
	GC_push_one(state.__r3);
	GC_push_one(state.__r4);
	GC_push_one(state.__r5);
	GC_push_one(state.__r6);
	GC_push_one(state.__r7);
	GC_push_one(state.__r8);
	GC_push_one(state.__r9);
	GC_push_one(state.__r10);
	GC_push_one(state.__r11);
	GC_push_one(state.__r12);
	GC_push_one(state.__r13);
	GC_push_one(state.__r14);
	GC_push_one(state.__r15);
	GC_push_one(state.__r16);
	GC_push_one(state.__r17);
	GC_push_one(state.__r18);
	GC_push_one(state.__r19);
	GC_push_one(state.__r20);
	GC_push_one(state.__r21);
	GC_push_one(state.__r22);
	GC_push_one(state.__r23);
	GC_push_one(state.__r24);
	GC_push_one(state.__r25);
	GC_push_one(state.__r26);
	GC_push_one(state.__r27);
	GC_push_one(state.__r28);
	GC_push_one(state.__r29);
	GC_push_one(state.__r30);
	GC_push_one(state.__r31);
#else

in the post, he seemed to simply remove all the ‘__’ underscores and it worked… so:

	#if defined(_STRUCT_PPC_EXCEPTION_STATE)
		lo = (void*)(state.r1 - PPC_RED_ZONE_SIZE);

		GC_push_one(state.r0);
		GC_push_one(state.r2);
		GC_push_one(state.r3);
		GC_push_one(state.r4);
		GC_push_one(state.r5);
		GC_push_one(state.r6);
		GC_push_one(state.r7);
		GC_push_one(state.r8);
		GC_push_one(state.r9);
		GC_push_one(state.r10);
		GC_push_one(state.r11);
		GC_push_one(state.r12);
		GC_push_one(state.r13);
		GC_push_one(state.r14);
		GC_push_one(state.r15);
		GC_push_one(state.r16);
		GC_push_one(state.r17);
		GC_push_one(state.r18);
		GC_push_one(state.r19);
		GC_push_one(state.r20);
		GC_push_one(state.r21);
		GC_push_one(state.r22);
		GC_push_one(state.r23);
		GC_push_one(state.r24);
		GC_push_one(state.r25);
		GC_push_one(state.r26);
		GC_push_one(state.r27);
		GC_push_one(state.r28);
		GC_push_one(state.r29);
		GC_push_one(state.r30);
		GC_push_one(state.r31);
	#else

This was defined on lines 130 and 273

the second one now looks like :

	
		#if defined(_STRUCT_PPC_EXCEPTION_STATE)
			lo = (void*)(info.r1 - PPC_RED_ZONE_SIZE);
			hi = (ptr_t)FindTopOfStack(info.r1);

			GC_push_one(info.r0);
			GC_push_one(info.r2);
			GC_push_one(info.r3);
			GC_push_one(info.r4);
			GC_push_one(info.r5);
			GC_push_one(info.r6);
			GC_push_one(info.r7);
			GC_push_one(info.r8);
			GC_push_one(info.r9);
			GC_push_one(info.r10);
			GC_push_one(info.r11);
			GC_push_one(info.r12);
			GC_push_one(info.r13);
			GC_push_one(info.r14);
			GC_push_one(info.r15);
			GC_push_one(info.r16);
			GC_push_one(info.r17);
			GC_push_one(info.r18);
			GC_push_one(info.r19);
			GC_push_one(info.r20);
			GC_push_one(info.r21);
			GC_push_one(info.r22);
			GC_push_one(info.r23);
			GC_push_one(info.r24);
			GC_push_one(info.r25);
			GC_push_one(info.r26);
			GC_push_one(info.r27);
			GC_push_one(info.r28);
			GC_push_one(info.r29);
			GC_push_one(info.r30);
			GC_push_one(info.r31);
		#else
	

Watch out for the top of stack one! its an extra one.

ok this works!

I had to restart the terminal because it didnt seem to find the new programs – it still thought mcs lived in /usr/bin not /opt/local/bin which is where port puts it.

Now i can compile c# version 3.0!!

oh yeah, be sure to use gmcs to compile, not mcs which is the old one.

http://www.theregister.co.uk/2008/10/08/scaling_agile_development_poll_200810/

enjoy.

Whilst retrospectives should really come out with very specific achievable and measurable actions, these more general themes can also be useful.

One of the team, Jeremy started writing the basics of the actions on cards as statements, like “Challenge Requirements”. We put these “mantras” on the wall and so we can see them and sometimes refer to them during standups.

This Iteration we did the same thing and it seemed to be a good way of capturing and making visible a result of our retrospective.

So far we have :

• Challenge requirements
• Understand Story Intention
• Challenge the spike
• Its not over until UAT (User acceptance testing or signoff)
• Keep stories focused and SIMPLE
• Migration code will ALWAYS be used again
• Transfer ownership (of stories, if people leave or move teams)
• Share Knowledge (as people roll off the project)
• Is it releasable? (an individual story)
• Demo Early

I gave a presentation at TW last thursday last month (August).

The subject was Collective design.

There was some interesting discussion about design in general.

For now, the slides can be seen here:

Collective design presentation

Abstract:
Software development implicitly creates a software “design”, the shape of the software artifact. To build software requires people. This talk discusses how the design of software is affected by and communicated between software developers, particularly on projects involving many people.

I think a principal might be never to make guarantees on other peoples behalf. For example : you talk to someone and say yeah my guys can get that to you by next Thursday. This now means you have committed someone else to something they have not themselves agreed to. It might be more useful to have them talk to the party who wants something and then have them agree with that person to deliver said promise.

This relates to the idea of a team being responsible for deciding how much work they can do within an iteration. It is not one person but all involved who have committed to this amount of work. There is a group responsibility and this is much easier to run than the command and conquer approach.

Far from being unscalable to larger groups, you could argue that this level of decentralised drive is essential. However it is certainly possible for a single individual to provide the drive for many people , it tends to be quite autocratic though and can often make people feel threatened which is not an ideal environment for fostering creative work.

The last one is interesting. I just found someone talking about it on the net. Its basically to help remember that a story should have a why ? Part.

AS someone I WOULD LIKE the system to do something for me SO THAT I can gain some benefit.

Acceptance criteria is the CONTRACT by which we agree with the client of the software we are writing what we will deliver.

Therefore it is the focal point of all parties involved. EVERYONE has an interest in what is contained therin:

THE CLIENT – This is how you make sure the team have understood what you want and how you MEASURE wether they have delivered it to you.

THE DEVELOPERS – this is how you make sure that you know the full extent of your work and thus how you know when you are finished with your job. Things outside the acceptance criteria which become apparent once you start a story must involve some kind of negotiation to append.
QAs – this is your lifeblood. It is impossible to determine if something is finished without knowing what its supposed to do. Acceptance criteria should be being consulted at every point in the develoment of a story. At the start, during and at the end. E.g. How many of the acceptance criteria have you met today ? This is what you will need to demo to the business.

BAs – you are the facilitator of the acceptance criteria. It is your job to negotiate between the ideals and desires of the client and the knowledge of the team of what is ACHEIVABLE within the given TIME PERIOD.

TEAM LEADs – these are what let’s you sleep at night. If there is well defined acceptance criteria the chances are that estimates will be more accurate and you will not have to explain why you have not delivered the functionality you guaranteed to the client.

Easy eh?