Sunday, December 21, 2008

New kid on the blogosphere

My friend, Simon Voice at Connections, has just started his own blog. I know he has some interesting views on the whole agile software revolution as viewed from a recruiter's perspective, and already has some interesting posts on there.

Thursday, November 20, 2008

What a difference a sand timer makes....!

Planning Games can be a problem. Especially with large teams where it is difficult to get consensus, and also far too easy to descend into lengthy discussions where different people are in fact violently agreeing with each other (at least in terms of what size something is). What should be a simple one hour maximum meeting to scope out the relative sizing of specific business stories can turn into a Dilbert-esque four hour meeting from hell.

Classic Planning Poker rules suggest using a timer to try and avoid these kinds of situations. Anyone can start a two minute timer, and at the end of the time the team must estimate. Limiting the amount of time gives a degree of pressure and focus to the discussions especially when there is disagreement. Also it limits otherwise lengthy discussions where in fact everyone now agrees on the estimate.

I the past I have tried using this technique with some teams that had a tendency to get bogged down but with limited success. I have tried using a mobile phone, but people found it too complicated to set up quickly and easily. It was also too "personal". A stopwatch did not achieve the right results either - it was simply ignored probably because it counts up an not down. And I have never found a decent egg timer that is easily and accurately settable to two minutes (same problem as the phone). Then I stumbled across a kids 2 minute sand timer....

(Yes, it really is that pink!)

What a difference the low-tech solution has made! It's easy to start (!), obvious when it's running and/or running out and does not disrupt the flow of conversations. Everyone I have spoken to has agreed that it has saved time. It has not always worked, but in general the signs are positive so far. I have even seen the timer being used in other entirely unrelated meetings.

Tuesday, May 13, 2008

Black Hole Team

Have you ever noticed how some teams do not have a "buzz"? That certain energy that differentiates a good team from a great team. Anyone who has worked for any length of time in software will almost certainly have experienced the lacklustre plod of a team in crisis.

But there is a rarer but not unknown phenomenon created by the further collapse of teamwork and common sense. I call it the Black Hole Team. Here, all joie de vivre has been crushed out of the team. All hope of changing, evolving and improving working practices has been extinguished. Team members are simply coding zombies, attending work not out of pleasure or professional pride, but instead simply to churn out second rate code that gets them from 9 o'clock to 5. By this stage the team has become so dense (sic) that new team members have the life and energy actively sucked out of them until there is just the shell left.

So just how does a team collapse to this level? The ways are many and varied, but common problems include:

  • Unsupportive leadership. If a team tries to improve but is simply not allowed to action the necessary changes, eventually they will give up trying to improve.

  • Political environment. Politics poisons software. Period. Engineers need to have the space and encouragement to improve, but are generally not political animals - most find it distinctly distasteful at best.

  • Poor environment. If a team is working in a physical environment that is uncomfortable, or that stifles free communication of ideas, and cannot change things then they are in serious trouble. Nothing says "The company does not give a stuff about this project or this team" as lousy desk spaces.

  • Cliques. It is possible that a significant minority of the team has worked together before and are now fixed in their ways. Bulldozing through stale ideas and techniques at the cost of innovation leads to damaging conflict unless justified by genuine hard facts and discussion.

  • Random edicts imposed from outside the team. Again, this kind of thing makes a team feel unvalued especially if they have already solved a problem adressed by the edict in a more efficient manner. It sends the clear signal "they can't be bothered to work efficiently so why should we?"

  • Professional pride. Yes, untempered engineering pride in delivering a good product despite the odds can be counterproductive. This misplaced loyalty will gradually be replaced by contagious cynicism, despair and even active undermining of product in extreme cases.

Pulling a team out of this state can be achieved by two things. Leadership and the authority to make certain key decisions (they don't always go together). The aim is to get back to a working environment that is seen as safe to work in, where suggestions are respected, considered and actioned, where the team has the ability to change and adapt anything to get around waste that is stopping the job getting done. Things to try:

  • Get the team what they want. Accomodation bad? Improve it. Get the team identify key areas for improvement and then make sure it happens.

  • Remove the politics and focus on delivery and adding value.

  • Correct or remove disruptive team members. I have said before, there is no point in trying to change the behaviour of someone who does not want to change, but the person causing trouble may not even realise they are doing it. Use one-to-ones and talk to them, but be prepared to move them to a more suitable team.

  • Break up cliques. In the same way as individuals can disrupt a team, so can groups. Split them up and use them to form two or more experienced teams.

  • Protect the teams from random edicts. Try and understand what the underlying business requirement is, and negotiate a mutually acceptable solution with the help of the team. Another more subversive strategy is to ignore it until it becomes inevitable - often no-one ever notices. If becomes impossible to ignore then make sure the true cost of the decision is fed back to all interested parties, especially your customer since I can guarantee that he will not be happy that it's costing him!

  • Disarm the professional pride problem. Persuade people to go home at a sensible time.

Give people the space to fail, to learn. Show that they are valued even when the going is tough. You will still have the loyalty (more, in fact), but it will be sustainable even on the most challenging of projects.

All of these actively demonstrate that the team - and by implication, the project - matters. When a team knows they matter you will be amazed at what they can achieve given the chance.

Selenium and HTTPS

This is documented elsewhere, but here it is again:

The problem - you want to test a web site where you get a popup to accept an unrecognised certificate, eg when using a self-generated certifictate. Selenium cannot click on the resulting confirmation window, but worse still Selenium does not store your decision even though you have selected 'permanently accept' manually the first time.

The solution - basically Selenium is launching a clean copy of the browser each time. So you need to create a persistent profile to use each time.

As far as I know this is only possible with Firefox.

Create a new Firefox profile (firefox.exe -profileManager). In this case the name of the new profile is selenium-https-profile

Add the certificate to it Add a suitable .pac to redirect to the SeleniumServer

function FindProxyForURL(url, host) {
if(shExpMatch(url, '*/selenium-server/*')) {
return 'PROXY localhost:4444; DIRECT';

Start the server

java -jar selenium-server.jar -firefoxProfileTemplate "C:selenium-ffox-profile"

Use the *custom target in your Selenium client to start Firefox with the specific profile

*custom C:\Program Files\Mozilla Firefox\firefox.exe -P selenium-https-profile

Seagull Architects

How familiar does this sound? Your Friendly Neighbourhood Architect flies in, makes a lot of noise, craps all over the design without any sort of interaction with the user or codebase and flies out leaving the Team to tidy up as best they can....

Unfortunately Seagull Architects are still out there causing a nuisance on all types of project, not just agile.

So please, Do Not Feed the Seagulls....

(Note - there are unconfirmed reports that Seagull Architects are evolving. Into Vulcan Architects. Here they walk in, Vulcan-mind-meld with the requirements and codebase (again without any real interaction with customer or real world code), and announce the design required. "That's illogical, Captain")

Thursday, March 13, 2008

Quote of the Day

From The Inquirer (of the latest Firefox 3 Beta):

"Still it does make Microsoft's IE7 look like a bloated asthmatic slug towing a caravan full of elephants in comparison."

Now there's a vision....

Thursday, February 21, 2008

If you think you're beaten...

If you think you're beaten, then you are.

I have recently been involved with a team where key players spent enormous amounts of time and energy trying to identify reasons why we shouldn't try things.

Working with people like this drags down the entire Team. It lowers morale because it becomes harder to make the changes that energise the working environment. The Team knows that it can never get better because the naysayers will do their best to block change and maintain the status quo.

If only people would spend time and energy actually fixing the problems instead of finding reasons to justify substandard tools, processes, practices and behaviours.