Immersion week one!

end of the week,

finally over the lag and just have the retrospective to go.

today heaps of balloons in the office with everyones name on them!

Some great discussions and ideas.

An analogy for interaction with the clients – like swimming in a rip tide – you cant swim against it.

Building relationships is like building a fire.


Immersion Day3

A lot of focus has been placed on collaboration and facilitation.

This is very cool as I was beginning before I came to start to focus on these as important concepts.

Discussing with Patrick my coach he pointed me to this book:

Collaboration Explained

Of course there is always someone who has been there before and written about it:)

Also I discovered the blog aggregator and so have added it to my links page.

In particular, this entry From Sam Newman is relevant A Tech Lead Manifesto


Immersion Day1!

so its the end of day 1 and its 2am and im awake with jet lag.

so far so good – not going to put any spoilers on here but there was plenty of interaction and collaboration going on. Think its a really positive experience, even if you only consider the fact that we are visiting our office out here in pune – aswell as us getting a feel for whats happening on the ground here, we ar egetting to know people and also i imagine its good fun for them to have lots of people from all over the place arriving.

the office is very spacious and has heaps going on – there is a kind of table tennis and karam league going on so have signed up for that.

everyone on immersion is very freindly and looks like a great week ahead!

its also really good to have time to think away from a project and in an inspiring environment – have a few ideas which may or may not get implemented!

will post photos at some point


Agile Collaboration

have been thinking about COLLABORATION. and i would like to work on it in more detail. For now here are my random notes:

Balance between collaboration and ability.

value collaboration as a skill equally with skill. especially collaborative communication : as distinct from simply communication – being very verbose but just slagging everyone else off for being stupid is not useful.

Rate things according to how useful they are:

define a CURRENCY for useful. In terms of agile the prime directive is producing working software. Also same for lean. THis is the currency. Is a behaviour / skill providing value in terms of achieving this goal?

Itas about HUMAN behaviour, not MACHINE or SOFTWARE behaviour!

Personal requirements:

be confident enough to know your not the best at something and still be valuable.

Subservience can be good and USEFUL? not sure about this.

WHATS THE POINT ? see value and currency

Be nice to people!

Accept others as having a valid point of view EVEN if they are doing something which you BELIEVE to be invalid not useful! this is an extreme principal – i.e. you might like to say “accept others as having a valid point of view, UNLESS they are doing something useful” this challenges you to be INCLUSIVE in your approach.

The competition between EGO and COLLABORATION – eveyone wants to be the HERO! the lone coder upon whose shoulders the fate of the world rests. even in the Agile pairing world this is funcamendtal human emotion – dont supress it, embrace it and try to utilise it – not sure how – but maybe by recognising collaboration as equally valuable can achieve a balance.

AUTHORITY through collaboration, not TECHNOCRACY.

IN theory if you have the best way to do something you should ALWAYS be able to get someone else to see the “truth” if after 30mins cant convince them then maybe it DOESNT MATTER!

Can take the method of XP and identify behaviours which are good and attempt to ALLWAYS do them – it at least generates an IDEAL and even if the reality never reaches that IDEAL, it will provide a driving force. much like the rest of the AGILE process.


Some generally interesting agile stuff…

So am getting fully back into the world of commercial software and enjoying soaking up new stuff again.

on my firefox tabs i have:

leaky abstractions

convention vs configuration :

some QA TOOLS:

and also been looking at JBehave and Behaviour Driven Design – where the tests disappear and you simply have behaviours which define the code.