Month: May 2011

Playing By the Rules

I’ve been trying to reflect on some of the recent successes we’ve had at work.  These successes where highlighted in a recent retrospective we ran last week.  Increased teamwork/collaboration, and improved built in quality to a certain degree. 

How over the last couple of months has the team seen such a rapid improvement?

The answer is pretty simple really – we have been playing by the “rules” outlined in eXtreme Programming & SCRUM (to a certain degree):

  • Pairing
  • Test Driven Development
  • Planning Poker
  • Retrospection
  • Daily Stand Up’s
  • Continuous Integration (to some degree)
  • Reflecting on Agile In A Flash cards 
  • Watching Clean Coders

As one of the Agile In A Flash cards said the other day – we have been playing by the rules, which is something we must keep doing until as a team we are more mature.  Once more mature we can start to review the “rules” and adapt them to our situation if they do not fit.  Hopefully this will allow us to further satisfy the needs of our customers.  In my opinion the most important part of software development. 

As a team we probably need to refine our pairing, and having properly defined roles during pairing.  How to ensure that both driver and navigator are working together.  A common problem is the navigator is distracted.  We could simply do the write a failing test then swap, scenario which I have seen work well at XPMan.  Another way is to use the Pomodoro Technique.  As I’m writing this it’s probably the case that as a team we should decide on a way to pair and follow this for a couple of weeks an retrospect on it!

Test Driven Development is another area that we need to get better at, but I think we know what we need to do – we just need to start doing it!

As you can see there is still much to do, a recent mind map highlighted just how far our team has to go.  Some of this is in relation to rules we’ve not implemented and some of this is just to enusre we keep applying the “rules”

Feeling the Rhythm

This week has seen our team embark on a major piece of new functionality for our legacy system.

Our progress has been relatively slow up until today, this might be due to the stories being epics, or it might be that we are doing all the right stuff! 

Test first (although probably not true TDD), pairing, getting existing code under test before modifications, improving the design of the existing code base.

We have two pairs who are working together on two stories.  Two of the people have swapped mid-week, Russell and I, have “owned” a story for the week. 

The two stories we are working on are quite different, the first story (which I fortunately picked) was to create a new page for the legacy system.  The code for this has been written using TDD; the new page interacts with the legacy system through the Model.  You might question why I stated “not true TDD” earlier – the reason is that we are lacking the automated acceptance tests to ensure that the outer ring of the TDD cycle is correct.  This is something I’ll be feeding in to the next sprint.

The other story is updating an existing page.  Essentially this job is three fold – get the code under test, improve the design (change to MVP), and make the functional changes.  This has been a huge job.  Unfortunately, we are not going to be able to fit everything in to this sprint; however, we will be able to leave the code in a better state than when we started!  We are forcing ourselves to pay back the technical debt that has been accrued – this is quite painful and time consuming!

The pairing has been extremely beneficial – it’s made the team focus on getting the job done.  I can’t say whether it’s improved the code quality, my gut feeling is that it’s caused conversations about the design of the code, which has simplified it (the tests also help with this), and also caught some things which are just plain wrong.  We even had a CRC session to flesh out some of the details of the classes and to ensure that they had the correct responsibilities (thanks Sam & XPMan!).  Pairing also seems to add energy to development or maybe that’s the caffeine!

It’s felt like we’ve not moved much for most of the week, but this afternoon the team’s feeling was that we were eventually getting somewhere!  The team decided to add a couple of hours to our afternoon – something which I’m not always too keen on – I’m a believer of a sustainable pace.  However, I also believe that if the team is agreed then this rule can be bent a little.  So we stayed for a couple of hours, and managed to get a couple more tasks off the list, and now we are pretty close to completing the two stories. 

This week has had a really good rhythm to it.  The Red-Green-Refactor cycle lets you get in to an amazing flow, of sadness then happiness, then more happiness as the code is refactored.  The team has been trying to apply what we’ve learnt from the cleancoders.com webcasts to the code base.  Especially the Boy Scout rule.

It’s important that we ensure that we deliver business value, but also improve the code base to work with, and have fun!

Motivated Individuals – Great Teams


Getting up at 4:30am in the morning on your holiday may seem like a bit of a daft thing to be doing; in the end holidays are meant to be relaxing and a time to unwind.  Some people enjoy lazing on a beach.  Unfortunately, that’s not my idea of a holiday – my ideal holiday is cramming as much “stuff” in to the shortest possible time.  “Stuff” is defined as ski touring (where I’ve been), ice climbing, rock climbing, skiing.

So what’s the reason for getting up so early and how does this relate to anything at all!!!

Well the reason for getting up early (especially in huts) – is because the hut guardians generally want you on the hill early so you can be back early.  The reasons are probably three fold:

  • In winter the afternoons bring a greater chance of avalanches.
  • In summer the afternoon brings the possibility of thunderstorms.
  • It also gives you the most amount of time to achieve your goal – i.e. go up a hill/mountain!

I’m not one for getting up early, however, on holiday it seems even easier to get up than it does on a work day.  It is quite simple go to bed a lot earlier than normal so that you can ensure that you are fresh in the morning – there is also not much to do in a hut after dinner!

When you get up in the morning at “silly o’clock”, there is an enviable buzz around the hut – people are psyched for the day ahead.  This energy is really amazing, you can feel it flowing through the building. 

This is the perfect example of building teams around motivated individuals (read principle 5), if a software team had the same buzz as my fellow mountaineers/hut goers then it would probably build kick-ass software.  Quite assumptive I know!

My mind now ponders at how to get this motivation flowing through everyone in a team; is getting people up at 4:30am in the morning reasonable!!!

Having a shared goal would be a good start, and finding out what motivates each individual in the team…