Thoughts from a Thirsty Bear

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.

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 mobil

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

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 ja

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

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....

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.