non-random ramble

I started writing this post a few weeks ago and since then been in several conversations around the same area, so thought I’d get on an finish it:)

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.

I was just watching John Snows’ documentary about America which is on CH4.

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.

I just tried to install mono version 2 from darwin ports.

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.

I just received this link from Tom Marsh at the guardian, its quite an interesting article and thought it would be worth publicising on our blog.

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

enjoy.

At the end of our last couple of retrospectives, we ended up with a set of actions that were really for the whole team to think about. Actually they were more like principles we should be following for the next iteration, rather than specific tasks.

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