Virgin London Marathon Part 3


So my calf swelled up and froze….I left my calf to recover for a week, I even did a bit of RICE (Rest Ice Compression Elevation) treatment.  Nothing particularly improved, it was quite painful for a few days but I could still walk on it, just not run, let alone 26.2 miles.

All I noticed around me was the frustrating sight of people running.  My colleague nipping out for a 7 mile run, and then meeting up with my brother for lunch only to go to the marathon store and look at trainers (for HIM!).   Later in the evenings I would be driving somewhere and just notice hoards of people running in the dark with their reflective gear.  Its annoying, that should be me out there.

So I google the symptoms in my leg until google has nothing further to give, on the subject. Its clear, its not a major issue, its a muscle strain but not a major one.  I have learned when this happens I MUST STOP IMMEDIATELY, its no good running on an injury, should that happen in the marathon thats a different thing, but I need time to heal and recover.

So I went to the physio

Who told me that although its good to have a never say die attitude to training, you should definitely stop if something is up.  That’s something that I pretty much learned the hard way, especially as I realised it took me out for over a week.  He located the pain point and identified the minor strain. The good news is that for this kind of injury you can start doing light exercise to help stretch everything out while it heals.  Tomorrow I will hopefully get back on track with a light 1-2 mile run.

Is RICE nice or is it unnecessary

So most of the traditional information points to RICE being the key thing, but not according to my Physio, this leaves me confused and it seems that despite the advances in modern science, there are still conflicting views on how to look after yourself:

  • Rest – allows the body to heal, but total rest isn’t always encouraged, this is the least disputed one
  • Ice - As a painkiller is a good idea, it reduces swelling and blood flow, but incidentally blood flow and a body response is what is required for healing….
  • Compression - Yeah holds things together and reduces swelling again, a tiny bit controversial in that you need the blood flow around the muscle to help heal
  • Elevation – again stops blood pooling around the area, actually fewer arguments against this, as you dont want too much bruising as that can take a while to clear

RICE is advised to be done immediately after an injury. Your body starts laying down fibrin and collagen and scar tissue to knit it all together, but its random so you need to guide it somwhat, therefore after a few days movement is really encouraged, if you stick frozen peas on a muscle a few weeks after the incident then you are likely making the “fibrin/collagen based” tissue less flexible and more brittle.

From the conflicting evidence I do side a bit on the RICE treatment, purely because they lob injured professional footballers in ice baths, and they are a huge investment so they probably picked the right thing.  The problem with these ideas is they all sound plausible.

Whats next

Ok so assuming my leg is on the good mend, I am increasing the instances of my runs to 4 times a week but keeping the distance short.  This is because running is a traumatic exercise and I want to allow my body to catch up and get used to the healing, training and conditioning that I am about to put it through

Fun facts about the London Marathon

  • A lot of people wee themselves, while running, I hear its true and its because if they stopped they wouldn’t be able to start.  I cringe at that,.. thats not me …. surely.
  • You can get splattered by peoples running gels that they drop
  • You can get accidentally spat on, (nice)
  • There are allegedly showers that you can run through, the wee-wee people must run through these (and linger I’d imagine).
  • There are lots of random people handing stuff out, from jelly babies and gels to occasional pints of beer, so keep your eyes peeled.
  • Tower Bridge gets packed apparently 8 people deep!


I just completed my first 15 min recovery run.  Its a run purely to get the calf into the swing of things and train the healing in the right direction.  So far so good!!!!

If you have been inspired by this and/or Sparks charity please give generously to my Virgin Money Giving Page here:

Posted in marathon | Leave a comment

why superman has no love life

or corporate team dynamics and how heroes can hinder overall team progress

“None of us, are as good as all of us” is a quote I frequently hear resounding in my head,

Most memorably its times of high pressure where you often see a single hero fill in a gap, at the reward of much praise. However when it happens regularly, daily, even hourly, what is happening behind the scenes is not a strengthening of resolve, or a building of a team, but a dilution and lack of balance of the team.  Undoubtfully heroics are great, however repeated heroics cause a stretching of individuals, and teams need to strengthen more by every part doing its bit (including overlapping), rather than some parts reaching over the multitudes to help.  These heroes end up spinning plates, .. why? because others let them; focussed on the results of their own goals rather than the success of a healthy team. The heroes should occasionally stop, and let others slip slightly. How else will other members of a team realise there is something wrong and work to improve so they can support themselves for the overall improvement of the team.  If a hero helps 10 people with 10% of their work that these people, could really do themselves (but are too lazy to), then when does that hero helper get time to do their own tasks?

What are the signs?

1) The victim’s cry for help

the victims cry of help

The victims cry of help is rarely structured

There is superman, just hanging around doing his own thing, probably adding value somewhere and not really wanting to be interrupted. Then comes the cry for help, which is a distraction at best; nobody works well with interruptions.  Superman has no real social and/or love life, he is getting interrupted all the time.  This of course is a metaphor for actually getting useful work done. If you are constantly getting interrupted by emergencies, then something is probably wrong.

2) The batsignal

the batsignal, is an informal pre-agreed behaviour

The “batsignal” is a result of rewarding and reinforcing the wrong kind of behaviour.  Even Commissioner Gordon gets tired of screaming for help, so what do they do? They establish an informal but agreed mode of calling you up, this is the “batsignal”. This could be confused with working synergistically, but you will know if it is synergistic or not if its dependent upon a person instead of a group or a system.   Take a day off, call in sick, or be unavailable for any period of time and if all hell breaks loose, then you probably have a problem…. These informal paths can taken any form, from a Director standing behind your chair, to an instant message, phonecall or nudge from a colleague.  The main thing is that if its regular and if its taking you away from your work its probably not healthy for the team.

3) The villain

when good people stand around and do nothing....

Actually, who are the villains?…  Well, it depends on the context:

a) You can be the villain. If you allow yourself to be distracted from your work, its actually your responsibility, don’t be a victim! You can be your own worst enemy (or you could have people not particularly helping you, and they can be part of the problem).  However you can’t really change people easily, but you can change yourself.  So its time to speak up and do something about it, set boundaries for appropriate issue resolution.

b) Other people may be the villains, they may see your plight and not want to get involved. I am less comfortable with this no matter how true it is, because it could develop a “blaming others” mentality.  If you are part of a team and you are the target contact to solve issues then encourage other team members to help, you can rotate these kind of emergency calls to nominated individuals, on what is called (strangely enough) a rota.

c) Are the victims crying for help actually the villains?   Only if you let them.  They are your customers, and how you reward them is how they will behave.  If you want to be superman, they will cry for help, if you want to be heroic they will create a “batsignal”, but if you want to be systematic and ordered, and organised, then they will follow your system and order.

The issue lies with team dynamics

“none of us are as good as all of us”.  Its not “none of us are as good as one of us”….

Team dynamics consist of the team’s working relationships, tempered by people’s personalities in an environment of a certain degree of pressure. A team can wish to go in one direction, but end up going a different way because of unconscious psychological behaviours and interactions.  How your team deals with urgent issues, how they are organised will determine your overall direction, strength and growth.

so whaddya gonna do?

eeeh.... whaddya gonna do? (for the Sopranos fans...)

Without some kind of introspection, individuals will not realise the problem for what it is, and that’s never going to happen all at once, however if your team practices retrospectives then that’s a potential game changer… You can raise and identify the issue and go about evaluating and testing a way to resolve it.  Some patterns that will help you include:

  1. Documenting all of your common solutions (wiki), so others can pick up the cries for help.
  2. Agreeing a rota with your team for solving issues, this can be backed by the knowledge share in 1.
  3. Agreeing a common communication point that is not a “batsignal” and can be prioritised effectively, so you are not dealing with things that seem urgent but are not important.  JIRA is a good example of this. The whole team can use it.
  4. If its not your job, and you suspect someone is being lazy and letting you be their dogsbody, its no harm to someone to occasionally let them slip so they realise they need to strengthen themselves.

Posted in agile adpotion, behavioural change, multitasking, team | Leave a comment

Virgin London Marathon Part 2

The good and the bad

Well first the good, and that is the running vest has now arrived.  Plus all the forms etc from Sparks including fundraising T-Shirts.  While it felt real before, this is bringing a sense of crystalisation and added focus .

The running vest arrives!

Pleased with my new running vest

meh injury

And then the bad, after completing a 6.5 mile run, with the onset of “man flu”, I developed a heavy cold for a few days, at the end of the week with the cold still lurking I decided to give it a blast on a relatively easy five mile run, intending to fartlek (short bursts of 80% speed separated with a half paced recovery on even stretches) to further challenge my body. After the first mile my calf decided to hurt, and then progressively get worse for the next mile.  Instead of stopping I decided that it would either run off or get worse so my body can heal it properly. (I can’t be cultivating a give up attitude right now.)  So it got a little worse and settled as a dull roar of pain.  Anyhow I completed the 5 miles in a moderate time and it was frozen peas for the next two days. They tasted bland.

nobody will want to eat those peas now, but perhaps I shouldn't tell and just sneak them back into the freezer....

Well did I learn anything…

Yeah I probably learned a few things about my body, that I should be taking my training more gradually from now on.  I have been given a book to read by a colleague called “The Non-Runners Marathon Trainer” which is a very good read.  These are some of the things I have learned:

  1. Don’t set a time, or determine you will not stop running and occasionally walk, for achieving the worlds greatest run, if you miss the time or end up walking due to hitting “the wall” in exhaustion you will feel mentally defeated and depressed, which is really not very encouraging given the distance you will have just run.  Previously I was setting a time of <4 hours and now I will revise that, especially given my current injury.  If you train too hard, you WILL get injured.
  2. You are not racing yourself, (how would you win if you’ve never ran the damn thing before anyhow), you are not racing the others, you are racing the marathon itself.
  3. The last 6 miles is supposed to be the last half of the marathon (physically) and of course that means the first 20 miles, will fly by…..
  4. Should you hit the wall, its likely because you have run out of glycogen based energy, so you are onto fat now, that burns at half the rate when it gets going.
  5. Running more frequently and shorter distances (than I have been) will help my skeletal muscles and ligaments toughen up for the long term more than trying to hit a few longer runs.

and my leg?

I have plenty of time to sort my niggles out, over 20 weeks to go.  For me it is about getting my body into being a running body, strengthening the right muscles and joints. Focusing on developing a healthy body and not focusing on the times and distances they seem to impress everyone.  Being teetotal is an important factor in this can wait until after Christmas.

If you have been inspired by this and/or Sparks charity please give generously to my Virgin Money Giving Page here:

Posted in marathon | Leave a comment

Virgin London Marathon Part 1


Historically I have never enjoyed running.  I used to say I hated running, which was true, however I hated being overweight slightly more; I chose the path of least hatred.  Other exercises were fine, cross training, spin classes, army circuits, five a side football, however although getting me fitter, none of these were quite as good as reducing weight loss. However I like my food; my takeaways, my chocolate and my beer so I have an uphill task.

Running was really a misnomer for me; jogging or plodding along was more accurate, as I regularly saw (and see) people who seemingly spring past me as if on magic legs, effortlessly gliding past as if the laws of gravity were different for them, it was like they had a rocket up their bum.  Whilst my shambolic form pounded the ground using a series of inefficient, half coordinated joint jarring juts.

In my early days I recall watching the marathon on television, remembering the red carpet stage (in particular) but having absolutely no understanding of how normal people could do this race.  It seemed back then that they were from a different planet to me, and I had no interest in following them.

Given my level of fitness and the fact that I am over 35 now, I was thinking that perhaps a marathon wasn’t ever going to be something I could do in my lifetime. Not that I didn’t think it was possible but that the draw towards it wasn’t enough for me to pay the price in training.

turkey foil boy

an attempt to look fit... except it was just a firedrill where they handed out those heat things that made me look like turkey with bacofoil

The Inspiration

The inspiration for me happened when watching my sister in law Mellissa Whittle run for her Charity Tommy’s earlier this year, she was driven by her own personal circumstances.  She started out with a mixture of running and walking over short distances and somehow managed to build it up further and further demonstrating how possible it was to do.  We traveled down to London to support her on the day, and I was completely struck by the atmosphere that was there that I was reduced to tears.  It is hard to explain, and has to be felt to be understood; It was partly the sheer encouraging support for the runners, who were a large number of frankly heroic people who were putting their bodies through an incredible test in order to raise money to change other people’s lives.

I was inspired, the seed was sown.

The very next day I made enquiries at Deutsche Bank (the place I am contracting) to see if they had any places for the London Marathon the following year, and found out that they didn’t tend to decide those until later in December that year, when they had selected their Charities of the year.  So I looked around to see how to get into the London marathon.  There seemed to be 3 ways.   The ballot is the obvious way, where approximately 130,000 people apply for 10,000 places, so I was all over that; I applied as soon as I could and got my application in on time, even donating the cost of the fee for a further ballot for extra places seemed a good idea! However my bid was unsuccessful, maybe I shouldn’t have put in a slow expected time, who knows? Its a low probability anyhow 1 in 13…..  The other way was via some kind of running club and I wasn’t really going down that route, I didn’t want to go running, I wanted to do that race…., so that left me the last way being via a charity.

I was particularly drawn to the children’s charities and applied to many.  Life starts with childhood, and I believe all children should have the same chance in life, even if its not a reality now we should strive for it.  While tempted to follow Mellissa’s charity (Tommys) I wanted to carve out my own path. Unfortunately I was turned down from many of these oversubscribed charities.

Then earlier this month I heard that the Charities of the year were chosen for Deutsche Bank and one of them was “Sparks”, they didn’t have any special places for Deutsche Bank however I got into contact with them immediately and enthusiastically put forward my application.  Rather surprisingly they almost immediately said yes, and being a Charity of the year with Deutsche Bank it means the first £1000 I get raised for this charity will be matched (even though I am not an employee of Deutsche Bank I have a relationship through my company through which I work.)  This was hugely encouraging and a brilliant feeling. I had made it in principle to the starting line of the London Marathon.  The next steps are to gain fitness so I can actually run it and start fundraising.

In hopeful anticipation of a place, (which included various competition entries) I have already been training, which started out around 3 miles approximately twice a week around  July – August time, and rather accidentally (when I once got lost) I extended it to 4 miles by missing a turning, and then encouraged that I immediately didn’t collapse then I worked my way upto 5 miles and only very recently 6.5 miles.

I didn’t immediately start running, as my weight was 13st 5lbs which I felt was too much for my knees, so I resolved to go on a bit of a diet, and do cross training stuff at the gym which would give my joints the best chance of avoiding injury.  I resolved to start running when I hit 13st/13st 1lb.  Which I did.  Since then I have been slowly losing the pounds and currently weigh in at around 12st 7lbs +/- 1lb depending on diet/water etc…

I am now considering a multitude of fundraising ideas, (and would welcome some), above the generosity of my friends, colleagues and family, as 2000 pounds (matched or not) is not a small sum of money to come by.  I have raised £10 so far and I will not despise the day of small beginnings.

The purpose of this blog

I  hope this blog will serve to inspire or at least entertain those reading it.  For those whom I manage (somehow) to inspire, I’ll hopefully inform them on a few tips on running a marathon, hopefully without any examples of “how not to do it”.  Additionally I am fortunate enough to know a few work colleagues who run marathons, from normal people to a couple of elite / ultra elite runners, whom run frankly absurdly low times and high distances.  A nice spread of advice you might say.  I am blessed with a number of tremendous examples to follow and I hope my writing this down will also serve you.

If you have been inspired by this and/or Sparks charity please give generously to my Virgin Money Giving Page here: I will be blogging my journey to the start line, as I believe as much as the marathon is a race, its also a demonstration of the preparation and diligence that has gone into training for it.

Posted in marathon | Tagged | 4 Comments

Thoughtworks Twist as a reporting tool – feedback loops part 1

A short while back I blogged on my thoughts-from-the-front-line-with-thoughtworks-twist and mentioned in it that it provided a pretty good reporting tool in its own way. Well we managed to put it to good use. Ok, we hacked it a bit, but I will tell you what we did, and if you use this package (v4.2 I think it is), you can do the same thing, and the result is pretty impressive. (For later versions I cannot imagine they’ve refactored everything so you could probably do the same stuff).

Twist is really designed as a BDD tool for performing BDD tests, and it uses Selenium (amongst others) for testing its UIs. However I had my own problems.

As an Environments Manager
I want to know how all my environments are performing
So that I can respond before a problem is noticed by the users

or perhaps in BDD form

Given we have problems in environments
When an environment has an issue
Then I want to be 2 steps ahead of the users and fix it already

The problem was quite simple, and common, we had no-one checking the environments regularly, and any issues that the users faced were not being resolved very quickly. After some analysis we frequently found that the problem had been there for some time; perhaps the server was down at midnight but the users noticed at 11am. Had we known about the issue we could have had it fixed at 9.15, but the issue was only exposed when the users tried to test the system. (ps. User == customer === Business Analyst).   Manually checking these environments out of hours is really an inefficient (and tedious) use of people’s time, and that is completely out of the question.

So All we needed to do is point Twist at the environments. Using Selenium to impersonate a user, log in, and perform simple functions we were able to identify a huge percentage of problems before the users noticed. We would schedule Twist so it would run every 15 minutes thus providing a heartbeat of all of the environments.

Environment failure

Oh oh look an environment failed, I'd better take a look!

However the key hurdle is this, how do we display the results, and to whom. Agile is a great advocate of transparency, and we so happened to have a ceiling mounted 40″ monitor where everyone could see what was happening. All we needed is display the results on the monitor. Which meant we needed the results in a nice displayable easy-to-feedback format, a proper information radiator, with an appropriate meme. That everyone could see.

Environments Passed

Finally, we can all relax, the environments are working again!

As you know Twist has its own rich functioning report page. But it was too “busy” for our purpose. Somewhere in the field of jar files was a bit of CSS and HTML generating the report… and we found it.

In the midst of the plugins directory was this jar file: com.thoughtworks.twist.core_2.4.0.12641-3bffc171c71291.jar
In the midst of the jar file was a handy file called report.vm (com\thoughtworks\twist\core\execution\report). This file is essentially an Apache Velocity templated file. This produced the html and we edited it to produce a simple table showing the successful execution of the end to end tests. Because we could, we managed to add in a few customised Internet memes, randomly selected based upon the severity of the state of the environments.

For a while people came along to stare at the screen, because the memes were amusing. But the average time of an environment becoming unresponsive/crashing/experiencing an outage and the Environments Team noticing changed from (sometimes) hours to minutes. We were also able to identify outage patterns with this and remove external dependencies that caused them.

Close out your feedback loops

The biggest lesson here, is my favourite lesson of feedback loops. Close out your feedback loops. What you don’t want to have in any project is a feedback loop which is long and arduous. There will always be problems, lets not focus on planning to avoid them, but dealing with them in a swift and dexterous way.

One argument I did think of against using Twist for this purpose was that I could have just used “Selenium” to do this and generated my own HTML. However, this fails for two reasons, the main one being, the kinds of tests BDD/Plain Language style we can insert at short notice allows us to really enrich the type of testing that we do. So this is not just to see if a page is responding or not, but also to test basic functionality and look for targeted errors. This is really easy to execute and maintain in twist using their provided scenarios and eclipse style implementation of the tests, separating business value (or testing value) from the executed tests.

enriching these environment tests are easy and fast

enriching these environment tests are easy and fast

If you can picture it, a new visual bug is found by the test team in the morning, and can be included in the tests and checks for all the environments in the afternoon, or perhaps the bug fixes found last month, are they included in this particular environment? its that easy to do.

Posted in BDD, feedback, Twist | 1 Comment

one born every minute

Can we learn anything from giving birth early, about early project delivery?

On the 19th July 2012 we welcomed William Maximus Elbourn into the world, and since then I have had limited time to blog. However I was inspired by the workings of the NHS enough to plant a seed of thought in this blog.  My wife Samantha was induced earlier than expected because they detected a volume change in the womb, we had an early delivery.

Giving birth is the end result of what is a 9 month project. Usually started by a brilliant idea. Timely project delivery is such a huge issue in the software delivery, and early project delivery is often desired but a relatively uncommon occurrance.

one of these gets delivered every minute

my wife loves this programme, I can't bear to watch it myself

early delivery

Occasionally with natural birth you can get complications, sometime mild, sometimes major and sometimes tragic, but the NHS deals with these complications in a way that seems contrary to most software delivery projects. The NHS to reduce risk, often deliver early.

However with software projects it seems the reverse, perhaps the project needs to be delayed by a week, just to fix some critical bugs, or a month to add the correct features often leading to many months…. With pregnancy delays would be easily fatal to a baby in a womb as the placenta begins to disintegrate as the body prepares for release (birth). Sadly lots of these software projects get abandoned, canned, mothballed or go way over budget as a result.

Before a baby is born, there are lots of unknowns, for example – experts still occasionally misinterpret the gender, the same (and more) goes for software projects, especially around the requirements.

The NHS also use a “burn up chart” (nah they don’t call it that but I guess you can see what I am doing here), this chart records the estimated growth based upon the scans and measured volume of the womb. As long as the baby is within a certain range then there is no cause for concern. Should the baby be gaining or losing weight, particularly near delivery time, an early delivery is often performed.


When the baby is delivered early, more people have access to the baby, and the right people can help the baby, you also get clearer diagnosis of any issues and greater feedback from the baby in terms of response to stimuli etc. The baby (and the mother) has a much greater chance of survival.

So why not with Software

Imagine it, you have a certain amount of functionality ready to go, you have a product backlog longer than your whiteboard will allow room for. This product backlog contains unbuilt untested functionality, that is needed for this project to be live. But what if you delivered early, what if the benefits of your ready-to-go functionality could be realised early? What if feedback from that functionality would negate half of your backlog and emphasise something new, more profitable and as yet unseen. What you deliver might not be super shiny, or gold plated but it may be an (often unconsidered) option giving early benefit to your customers.


does your software delivery make you feel like this?

from one end of the scale….

“But you cannot deliver garbage into production…!”

I am talking in the context here of a team that is delivering releasable software, and I acknowledge that you cannot just put something that puts a business at risk into production, I am talking about incremental units of functionality (vertical slices if you like).

If the project is in a worse state than this, (lets say a less developed state) but is releasable you can still deliver it into a different environment, perhaps if its greenfield development deliver it into UAT then. Or put it somewhere where people can see it, and give valuable feedback instead of sitting on the problem.

When you expose the project to others, the right people can help the “baby”. This takes a certain amount of guts from project managers who dont want to appear to be asking for help, or perceived as a failure. It takes teamwork. The problems and uncertaintities faced in software development are rarely unique, and often outside help or feedback help tremendously.

…to the other

“Hmmm… what features shall we deliver first (or at all) into production”

The software industry already has established something called multivariate testing (or A/B testing) where you can deliver multiple (potentially conflicting) features live, which are proportionally split across your customer base, feedback can quickly gained and used to ascertain which is the better feature, and you can then roll out the more successful feature at will. This is particularly applicable for online marketing / ecommerce applications, you can read more about it here. While this might not be delivering early it does reduce uncertainty and get early feedback which can affect your backlog.

Posted in behavioural change, Core Agile, getting into production | Leave a comment

Cowboy Coders

I often hear this reference banded around, but no-one has really been able to clearly define what a “Cowboy Coder” actually is. We have all seen behaviours in our IT experience of “cow-boyish behaviour” or even know a few “cowboy coders” ourselves. You may even be one yourself, and not realise it, and I am sure most of us have displayed cow-boyish tendencies in the past … ;-).

cowboys from once upon a time on the west

cowboys from once upon a time on the west possibly the greatest start to any movie

My simple definition of a cowboy coder is:

someone who writes code according to their own rules,
ideals or what they are feeling like at the time.

This unfortunately expands to:

someone who interacts in the whole software lifecycle according
to their own rules, and therefore is rather difficult to control,
lead and encourage to be an effective part of a working team.

no real cowboys should be hurt in the making of this blog

Cowboy disclaimer.
I love cowboys, who work a very difficult job
in a disciplined manner in teams.   I loved Stephen King's
"The Dark Tower" series, I loved the Good the Bad and the
Ugly and I thought "Once upon a time in the west" was
terrific.  I think its a poor analogy that poor quality
people of trade get labelled as cowboys.

Intellectual Intimidation over working as a team

I have seen some IT professionals sadly behaving in a cow-boyish manner by using intimidation.  Essentially they know their topic really well, usually its their programming language they specialise in, but unfortunately decide thats the only thing that matters and their focus is onto personal performance rather than team progress. Typically expressed in disdain and intimidation of other ideas from colleagues and a lack of wanting to help others, which spirals into a real intolerance.

Eg. “Harry is useless at design patterns he doesn’t even understand the decorator that I designed…”  … well why don’t you explain the decorator pattern with him, and exercise your communication and patience skills until he also understand it…..?

thats a nice design pattern why dont you show me how to use it

that's a nice design pattern why don't you show me how to use it

Now some of us enjoy a steeper learning curve than others, but the Dreyfus model of skill aquisition ( (and my own experience) teaches us (sorry not directly mentioned in the reference) that competancy will always be achieved by someone over time.  For some people its faster, for some not.   Which means if you have someone who is not grasping things that quickly, guess what, give them time, they will do, unless you have been completely mad in your hiring strategy.

For example someone who has blagged that they are a dev lead but really they are a junior developer, can still gain competency in the dev lead work, but it will take time.

A lot of the issues stem from thought and behaviour patterns. We are of course working in an industry that is very volatile, especially with the .com bubble bursting at the turn of the millenium as well as the current financial crises.

1) People want to keep their job, if they make other people look good they feel that they would become less valuable.  That’s pretty much the opposite of teamwork and against every corporate “value” in the book, yet people still do it.

2) People with a win/lose mentality, thinking there is a fixed reward, or that they can only profit from someone else’s expense.  Snuffing someones candle out does not make yours brighter, it might seem brighter to you, but the room is darker.

3) People who retain knowledge for selfish reasons, they become like wizards and warlocks.

Essentially it all boils down to selfishness.

other types of cowboys leave a painful legacy

I have also seen individuals who would rather “reinvent the wheel” rather than use a standard library or design pattern just for the enjoyment of it.  Guess what, often its a slight improvement on the existing code, however, the way its written, and then handed over can cause complete confusion for the rest of the team.  Sometimes its better to have a slightly less efficient piece of code that’s easily maintained than a slightly better piece of code that is impossible or extremely expensive to maintain and understand.   Often this stems from a lack of discipline in a developer to follow through on what was a good idea and embed the knowledge in the team leaving a good legacy rather than legacy code, which if you are or were a developer we have all had to deal with ….


Something else I would loosely put into the cowboy category, is someone who will talk ill of a fellow team member without really trying to help them, or rather will make a show of helping them without actually helping them. Guess what? Sometimes its the failure of the teacher rather than the pupil, a teacher hasn’t taught until a pupil has learned.

Remember someone being “not good enough” could simply be the fact that going from a novice to competent is taking longer than you thought.  Now not everyone gets to “Proficient” or “Expert” but that’s done via demonstration not remonstration.

is really really poor quality code cow-boyish code

I actually dont see a huge deal of this, maybe in the side I saw more of it, but really really poor quality code I don’t see as really cow-boyish these days,  bad quality code is just bad quality code, it has no personality; I  would be more interested in the behaviour of the team that allowed that quality through.


Its not a black and white definition, and nor are people who display cow-boyish behaviour cowboys all of the time, and all of the way through.  But its always good to do some self examination from time to time.  One thing that will be obvious is that cowboys, although may be able to understand the workings of a team, and understand team playing are not team players while in cowboy mode.

Posted in behavioural change, team | Leave a comment

Banishing Warlocks, Witches and other Magicians


Thats some of the problem with software development, its that it is perceived to be too hard. Someone is compiling code from over here and deploying over there to those servers with those tns names, and you need to bounce the servers but in the right order and do the smoke test just after the database release and oh and how are we doing the patch fix? are we using properties files? and apache is down, its gone wrong, SOMEONE PLEASE FIX THIS MESS.

In steps your local friendly white witch, wizard or magician

The hero.  See all that stuff above? They figure it out, they compile the code deploy the ear, amend the classpath, delete that overriding properties file and alter the tnsnames so its no longer out of date.  Phew.  Magic.  They just turn up wave their indispensible wand, and (certainly in my book) earn their salt.  Who wouldn’t think that?  Just dont let them go, because … well we need them to do their magic………………………

………………..and therein lies the problem.

What a wizard might look like

What a wizard might look like

What happens if?

The wizard is unavailable? You are stuck. You have a truck factor of 1. You are in trouble and guess who is sitting exactly where they want to be?  Guess who is going to get their contract extended? Guess who is going to get a high performance objective/bonus?

Ignore the man behind the curtain

The magnificent Oz

The magnificent Oz

This picture will be familar to people of a certain age myself included. The man behind the curtain, is (of course) the Wizard of Oz, and what is appearing to be mightily important and magnificent is actually one person’s attempt to “blind with science”. (For those who have not seen the Wizard of Oz check out the plot) Often the “magic” a developer does to resolve a situation, especially in repeated circumstances is no more than pushing a few buttons and twirling a few knobs.  Important perhaps, needed definitely, but really tech?…… no.

Other problems

You have a wizard, a very capable developer, but the issue is worse than truck factor.  You have a system where you need to repeat things time and time again to test systems, to test deployments, and slowly you will find that the balls will drop, OH they get picked up as soon as the wizard realises that the old ear file was deployed instead of the new one or the wrong tnsnames got done this time etc…  But you have a very capable developer who instead of focussing on the developmental road ahead with it’s rewarding challenges, is instead juggling tasks.   But only they can do this stuff… only he or she has the pc with the correct maven settings or classpath or project setup.

The solution is simple

write stuff down

write stuff down

Probably many reasons (some discussed above) why people don’t already do this, but its always a worthwhile investment.  I mean who likes to think about stuff that you can write down anyway, I’d rather be thinking ahead.

When you write the stuff down, the magic disappears, and becomes tangible and useful within itself.  Maybe its actually a simple “copy and paste” with an ear file and another 1 line change to the “tnsnames” file, hey! guess what? We can get one of our junior members of the team to do this and they will learn something new, and hey! guess what? The team begins to improve, and freed up members of the team can work on the real problems at hand, without worrying about issues afoot.

Oh and use a wiki. Its great and often automatically version controlled too for auditing purposes. (not sharepoint, not sharepoint, and sharepoint NOT! sharepoint is flakey difficult and information hiding).


Writing stuff down:

  • Frees up the developer to work on more intuitive problems
  • Allows the team to work as a team and not a collection of individuals
  • Increases the team’s combined problem domain knowledge, lets call it the IQ of the team
  • De-risks projects
  • When stuff is written down, its easier to see how it can improve, therefore it improves collaboration
  • Saves time even in the short term
  • Increases truck factor
  • Not sharepoint (unless you are backing up the wiki)
  • Makes onboarding much easier, you dont need your top developer continuously spending time onboarding newbies as a result of more developers being needed because the project is behind.
Gandalf summarises

Gandalf summarises

Its ok Gandalf, the only loss is in that magic halo around the individuals who have the knack of solving those reccuring problems.  But Gandalf I say, dont fret about your powers, you can use them still but at the cutting edge of the problem solving.  The idea of breakthrough, is that one person or group breaks through, and the others simply follow through, and the team can simply stand on the shoulders of giants. But then you knew that because you are Gandalf the white now ;-)

You might find some passive resistance, that then requires a bit of team cohesion, understanding and discipline which should be enforced.  Changing people’s mindsets is one of the most difficult challenges any leader or manager has to do, but simply by putting “write stuff down” on peoples goals or performance objectives could solve this. (Show me how you measure me and I will show you how I behave : Eli Goldratt)

So we need to banish the magic, and make those warlocks, witches and other magicians into team members again.

Posted in Core Agile, lean, team, xp | 3 Comments

killing zombies using the double tap technique

Or How to kill zombies in a corporate environment

Many of us work in a corporate environment. Getting stuff done in a corporate environment has its challenges at the best of times, but when the company has decided to put in multiple silos of specialty, with SLAs of multiple days hidden behind group email addresses then you may be experiencing a corporate ZOMBIE APOCALYPSE.

corporate zombies

A Corporate Zombie is mainly engineered by situation in which they work. (R.Elbourn)

What is the experience like?

You need something, perhaps a database instance or unix access, something which the company has decided to put into some kind of structured organisational silo defended by a Jira system or at least a group email address and if you are lucky a single point of contact. So you take the following actions…

  • You raise a Jira for the work to be done, it goes on their Jira queue, and gets turned around and rejected because you made a mistake. You then rethink, resubmit, and chances are that you made another mistake. The whole process takes about two weeks and the feedback on each mistake is both “zombie” slow and uninformative – painful!
  • You send an email to a group address, and get no response for a day or two, (any immediate response usually being “sorry I haven’t worked in this group for two years can you remove me from the list?”) any eventual response is perhaps negative, unhelpful and at at best sluggish, meanwhile the clock is ticking.
  • You send an email to a group address and then 3 days later you get a link to a wiki to fill out a form, giving no or outdated instructions on how fill out the form.  You can’t recall all of the application ID’s, ITPMs and different stakeholder groups from the top of your head, it takes time.  You fill out the form to the best of your ability and you don’t get feedback for 2-3 days.
  • You see them on an online chat, but they are rarely “green(available)” and more often than not offline (even though you know they are in). If they are green they and you do message them they frequently don’t respond or magically “disappear”.
  • …and you find out that they are incredibly resistant

Right now you are thinking of taking the computer screen and flinging it against the wall.  You are filled with frustration, I mean how difficult is it to get a unix id with access to some UAT servers setup? Or maybe you just want a new database instance done, you know what actions need to be done, but there is a huge bureaucratic system of zombies in the way, zombie people, zombie documents and zombie systems of (lack of) support. You then go on a lengthy rant which down the pub or in a bar and it usually involves lines like this:

You: "These guys seemingly are employed to stop me doing work, they are inhibitors of progress, all they do is get in the way, they are the champions of the status quo, hey ! help me to help you, help me help you, help me help you."
Colleague: Quality rant, have another beer.

Why is it like this?

Remember corporate zombies are people too.

zombies are people tooYou might want to correct me, and say zombies were people, but corporate zombies are people, they are just like a zombie to you.

Reasons why they are zombies to you:

  1. They are very busy people
  2. They don’t know who you are
  3. They don’t know about your project
  4. They don’t care about your project because they dont know about your project
  5. They usually have 800 unread emails in their inbox, to which they get updates of at least 150 per day, why should they deal with yours first?
  6. They are protected by SLAs which means they don’t have to jump when you say jump
  7. They might not even be the people you need, so their interest level is low
  8. They are often dealing with Production issues, you are developing to UAT you will find stability is preferred to change (especially in the finance sector), you are automatically low priority
  9. They might be a little institutionalised or disinterested because they don’t always see the big picture
  10. They are measured on the size of their Jira/problem/issue queue not on the quality of their answers
  11. Being in a silo implies that there is a division of labour, therefore they are dealing with a much wider audience than you, and overall throughput is their measurement of success
  12. There could be many more reasons.. feel free to add some of your own…

So why should they be helping you over other people in their workload? Sorry to disappoint you, but prioritising an email as “High Priority” simply doesn’t “cut the mustard“, its frankly lazy and unprofessional unless followed up with a call or visitation.

How to deal with it:Use the double tap method

No not “one to the heart” and “one to the head”, or “two to the head” or crow bar to the head, or just do anything to destroy the brain, or even run the zombie over to place them in a wood chipper.  Remember the zombie thing is a metaphor.

You need to tap on their shoulder or tap on the phone.  Emails are good to back up and confirm a conversation that has already taken place.

Tap the shoulder

You may need to do a bit of investigative work, which means looking in the group directory, or asking other people, find out who you need to talk to.   You are not really dealing with a faceless zombie corporation, but a system with a few bits in place to protect themselves from lazy people who haven’t got their stuff together and waste their time.

Once you have found out who it is, go and find them, by far the best form of communication is face-to-face.  Its an agile manifesto principle:

The most efficient and effective method of

conveying information to and within a development

team is face-to-face conversation.

Next go and find out where they work and talk to them.

Tap the phonepad

Many times the person you are trying to reach is unavailable, or in a different building (you could just go for a walk) in another country (perhaps not!).

In which case pick up the phone, and persist. You will rapidly discover whether you are talking to the right people or not, and you will find someone to whom you can explain the importance of your project and the detail of your work.

You will also find out that they are not really zombies but humans with a workload rather like yourself, and in fact they’d be happy to help champion their processes by walking you through it.

Guess what, when you email them, they will respond a lot faster, they are no longer a zombie to you, but then why would you email, you know them on the phone or in person and its much faster.   Guess what, they respond to your online communicator messages now… bonus.

One less zombie in the corporate world, well done!  This saves time in your requests, and the whole blame and escalation game that your Project Managers, their bosses and their stakeholders would inevitably have to do as they do the work that you were supposed to do in the first place, because someone wasn’t responding to a drop in the 1000’s of emails that that have

So your bosses no longer need to:

  1. Escalate the issue (that you already did by speaking to them face to face over the phone)
  2. Explain the importance of the project (that you already did by speaking to them face to face over the phone)
  3. Get them to show you their process (that you already did by speaking to them face to face over the phone)
  4. Get commitment for them to help you (that you already did by speaking to them face to face over the phone)

Remember zombies are people too.

The end

Posted in behavioural change, lean | 1 Comment

Thoughts from the front line with ThoughtWorks Twist

At the beginning of this year I was fortunate to be drafted into a team with the task of enabling them to sucessfully use a new-to-the-bank tool called Twist developed by ThoughtWorks.

What is Twist, and what other tools is it like?

To quote ThoughtWorks

Twist tackles the biggest problems that prevent most companies from building an automated regression suite that can keep pace with their complex changing application. Twist helps teams create maintainable, understandable test suites while providing a bridge from manual to automated testing.
Testing can be the biggest hurdle in any organization’s journey towards continuous delivery. Most companies fail to cycle through testing, acceptance and regression quickly enough to release at the speed they need to.

In my own words

Its a thing, that lets you test things repeatedly, in a nice easy to read way.


Its an eclipse based tool, where simple semantic language is converted into pragmatic repeatable tests via. an adapter, using the adaptor pattern.

What is it like

Quite simply its a bit like a cross between an early version of Cucumber (with the plain text structure of requirements) and Fitnesse (with the use of the adaptor pattern).

What does it look like?

The scenario

Twist Scenario PageThe scenario is simply a plain text file, in fact it looks like this

Given Thoughtworks Twist out of the box
When I load google
And do a search for agile 78
Then I can get a feel for Thoughtworks twist with its in-built selenium


*USER Story*
As an Agile practicioner
I want to load google and do a search for agile 78
So that I can test drive Thoughtworks Twist with its in-built selenium

Browser Search:
#I want to load google like so ""
#I want to search for "agile 78"
#I want to click on the first page and confirm it contains "Robert Elbourn"

This is the bit thats a bit like Cucumber, however what Twist then does is enrich it to make it look a little less like a textpad file, and instead something that looks more marked up / flashy /corporate / dare I say enterprise?

Anyhow you will see there are 3 main sections in the page. The top section containing tags, context, workflow and execution buttons, this I don’t touch in this blog. The middle section, this contains your user story, or your business meaning, the value you are trying to achieve with your working software.
The bottom section is the framework for the code.
In this case Browser Search becomes your java class, and each unique following line transcribes to the methods of the Browser Search class.  The light brown lines simply show unimplemented methods, and the black lines are implemented in the above mentioned class.

The code (adaptor)

The codeA simple press of F3 takes you to the class you need to implement to prove the test, with assertions or otherwise.

The results

The resultsAs you can see you get a handy green line for every step of the scenario passed.

Getting to work with Jenkins

Was nothing short of a pain but we did it.

If you like us are using Maven with “Poms” then there is no direct integration with ThoughtWorks Twist.  All is not lost however as ThoughtWorks does provide an ant build file which then plugs into maven using the “maven ant run” plugin. ThoughtWorks also provides a rudimentry maven script but I couldn’t get it to work, so I did my own.

Nice Reporting but lack of direct compatibility with Sonar

When we got the twist tests running as part of the larger project Pom, we discovered that if any of the twist tests failed the build went red. Initially I was thrilled but I wasn’t so popular with the developers who pointed out that when the build goes red, they get no feedback from their Sonar tests, which would otherwise have gone Yello with an indication of how many failing tests in a nice visual way (i.e. it built but some tests failed). The short term solution was to separate the POMs for better test feedback granularity on the unit tests existing in other modules of the project.

Twist actually provides pretty good reporting in its own way. It actually takes screenshots of any pages where errors are discovered (really really handy I mean how many times have you been served up a defect by a tester with no screenshot of the discovered problem) and compiles them into a report which can be viewed locally, or remotely on a server. I managed to alter the script somewhat and for every seperate build we had a versioned report which was then served up by Apache and accessed via a hyperlink to from the console logs of the Twist module in Jenkins. Heres an example:

Twist Reporting Page showing the errored screenshot

You just have to accept that Twists tests in our project context are automated acceptance tests and need to be considered seperately to the unit tests. While this is fine, I have to be aware that some extra work is required putting all of these metrics together to give to the stakeholders.

It doesn’t guarantee BDD … but could support it

Just as sitting in a car doesn’t guarantee that you are a good driver, or even a driver; having Twist in your project doesn’t guarantee you are doing good BDD or even BDD at all. The question is, if you were doing BDD and were given Twist, would it help? assist? be neutral or get in the way?

I actually believe it will help, yes. However its the team that drives the tools, and not the other way around, the team needs to choose the tools whether its Cucumber, Gherkin, JBehave or FitNess or whatever. Sticking to one tool is probably enough, and if you are looking to improve BDD, then your primary focus has to be on your people on the project rather than the tools.

If you are trying to get someone in your company to buy into it, apart from its slightly pricy license cost (around 500 per floating user per year**) it will sell well to the management, this is because of its packaging, its reporting, the fact that it looks fairly slick and “enterprise” and not something developed and designed and understood by developers only. Confidence and presentation is a huge thing and Twist is not weak in this area.

(**price is now down to around $99 per user per year since writing this post (or at least buying the licenses)  see blog comment)
Posted in agile adpotion, BDD, Cucumber, FitNesse, Twist | 2 Comments