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")