Category Archives: ThoughtWorks

Life after ThoughtWorks Part Deux

Last year i wrote a blog post Life After ThoughtWorks and this year i was reminded of it by an (now ex) ThoughtWorker Chris Read.

I re read the old post and marvelled at how far i had come in twelve months, and also how my attitude towards TW has changed too.

Now, twelve months on from that last post and I’m older for sure, more knowledgeable too, but i’m still passionate about Agile software delivery. So passionate in fact it often leaks out into my daily life. I have jokingly called my self evangelical about it. I’m often challenged by people who have had a less than optimal experience with Agile as a software delivery methodology, and sometimes i can feel their hate and anger for this stupid thing called Agile that everyone is talking about.

So, first up an apology, to a good friend of mine Keith Henry. Keith was talking to me about this weird and wonderful stuff called Agile at least 6 years ago, and i dismissed him as a nutter, while he just nodded and grinned; he knew I would succumb eventually, then he could (rightfully) say i told you so. Keith, i’m sorry it was I that was the nutter.

Next up a thank you. To several ThoughtWorkers who have changed my perceptions, shared their wealth of knowledge with me, and listened to my many, many criticisms, scepticism and pessimisms. They taught me many things (often through observation and not directly), and so, in no particular order:

Luke Barrett – for many things, the consummate consultant and voice of reason.
Graham “Wookie” Brooks – for teaching me that you can teach an old dog new tricks.
Chris “Dude” Read – for the filth and the energy.
Tom “Boobies” Scott – for teaching me to get my game face on, and never high 5 in public.
Richard “ffs” Fillippi – for the “Victor Kiam” moment, classic.
Sam Newman – don’t over promise and under deliver.
Jo Cranford – for making nice story cards and making coke come out of Chris Reads nose.
Pat Kua – Agile and performance testing can work.

I worked with many, many more ThoughtWorkers, but those above are the few who have shaped who I am twelve months on.

The big Question – Are we coping?

So TW roll off, hows it all hanging, are we still Agile? I think we mostly are, there have been a few times were the edges became a little frayed, but I think that in the past we may have stood by and watched as the fabric fell apart. This time we were able to tell that we needed to act, and were able to put in place a fix that was secure enough to have the required longevity and light enough as so not to deplete us of time and resource, and of course, we left the repair until the last responsible moment.

Our big challenge is not staying Agile, but keeping one team, that is distributed across two locations in sync. More than that, keep the synergy. That is not a software delivery problem, that’s a people problem.

Life after ThoughtWorks Part Deux

Last year i wrote a blog post Life After ThoughtWorks and this year i was reminded of it by an (now ex) ThoughtWorker Chris Read.

I re read the old post and marvelled at how far i had come in twelve months, and also how my attitude towards TW has changed too.

Now, twelve months on from that last post and I’m older for sure, more knowledgeable too, but i’m still passionate about Agile software delivery. So passionate in fact it often leaks out into my daily life. I have jokingly called my self evangelical about it. I’m often challenged by people who have had a less than optimal experience with Agile as a software delivery methodology, and sometimes i can feel their hate and anger for this stupid thing called Agile that everyone is talking about.

So, first up an apology, to a good friend of mine Keith Henry. Keith was talking to me about this weird and wonderful stuff called Agile at least 6 years ago, and i dismissed him as a nutter, while he just nodded and grinned; he knew I would succumb eventually, then he could (rightfully) say i told you so. Keith, i’m sorry it was I that was the nutter.

Next up a thank you. To several ThoughtWorkers who have changed my perceptions, shared their wealth of knowledge with me, and listened to my many, many criticisms, scepticism and pessimisms. They taught me many things (often through observation and not directly), and so, in no particular order:

Luke Barrett – for many things, the consummate consultant and voice of reason.
Graham “Wookie” Brooks – for teaching me that you can teach an old dog new tricks.
Chris “Dude” Read – for the filth and the energy.
Tom “Boobies” Scott – for teaching me to get my game face on, and never high 5 in public.
Richard “ffs” Fillippi – for the “Victor Kiam” moment, classic.
Sam Newman – don’t over promise and under deliver.
Jo Cranford – for making nice story cards and making coke come out of Chris Reads nose.
Pat Kua – Agile and performance testing can work.

I worked with many, many more ThoughtWorkers, but those above are the few who have shaped who I am twelve months on.

The big Question – Are we coping?

So TW roll off, hows it all hanging, are we still Agile? I think we mostly are, there have been a few times were the edges became a little frayed, but I think that in the past we may have stood by and watched as the fabric fell apart. This time we were able to tell that we needed to act, and were able to put in place a fix that was secure enough to have the required longevity and light enough as so not to deplete us of time and resource, and of course, we left the repair until the last responsible moment.

Our big challenge is not staying Agile, but keeping one team, that is distributed across two locations in sync. More than that, keep the synergy. That is not a software delivery problem, that’s a people problem.

Creating FitNesse tests

Okay, so we are still having problems with CruiseControl (it falls over after n builds) but meanwhile i need to start creating tests in Fitnesse.

The ThoughtWorks consultant has already started, but i just reviewed the work and i’m less than impressed.

I want each page to contain some prose that describes what’s being tested and why.

The structure of a requirement should follow a basic syntax. We should have a basic description of what is needed from a business perspective:

As a [role] I want [requirement] so that [business value].

And the tests should line up by defining an Acceptance criteria, basically we define what “done” looks like:


Given [context] when [action] then [outcome]

The Acceptance criteria should be written jointly by BA and QA, and the acceptance tests map directly to acceptance criteria.

So on each page (a test) i want a preamble (the story), the requirement and the acceptance criteria.

The Fit table (the actual test) can then sit directly under the prose for the acceptance criteria.

That way, each page (each test) is the requirement, the test and the test results.

Of Agile, ThoughtWorks, Selenium and Fitnesse

I have set up this blog to capture some of the problems we are bound to run into over the next 60 days.

I work for a well known (read busy) commercial website in the UK. We currently use a traditional waterfall approach to our software development life cycle, and we are under pressure to deliver more, and deliver it more frequently.

I am an ISEB certified Test Practitioner and I supported by two testers on my Team. Martin, a test analyst, who has achieved his ISEB/ISTQB Foundation certificate in software testing, and Robert, a junior test analyst who will be taking his foundation training later this year.

We are all aligned to thinking about software testing in the same way. That is, we have a clear set of requirements (be they, technical, business or design) and we test against those; simple no?

However in the real world it is never that cut and dried, and often requirements are thin, late or non existent, and (of course) liable to change at the drop of a hat. This is compounded further by the businesses increasing frustration at having to wait for a simple change to be implemented; we are only talking about a website here right? It’s not like we are trying to boil the ocean.

Cue Music – Enter ThoughtWorks.

Somewhere along the way the business got to hear of ThoughtWorks, a company that can offer (among other services) a helping hand for any software house wishing to become Agile. I don’t want to talk too much about ThoughtWorks and our relationship with them, because I only want to focus on the Testing aspect of becoming Agile, and because I could fill another blog with chatter about working with ThoughtWorks.

Anyhoo, we are a Linux, Apache, J2EE & Oracle house. So it felt right that we should use Selenium for our automated testing. ThoughtWorks originally created selenium so it felt right to use it with them. We have looked at Selenium in the past and I have used selenium scripts with the most excellent Reality QA product from the guys at GOMEZ (more on that later).

A couple of interesting points about selenium; Selenium is a chemical element with the atomic number 34 and is represented by the chemical symbol Se. Selenium can be found naturally in nuts (Brazil nuts are the richest ordinary dietary source), cereals, meat (such as kidney), fish (shellfish such as crab and lobster), and eggs.
Selenium is often touted as “The cure for mercurial poisoning” (being poisoned by Mercury), and any tester can tell you that Mercury produced (before being bought by HP) some highly priced automated test tools of the variety that “require plug-ins” to do anything more ordinary than record and playback (Test Director for instance). So I think the developers of selenium thought it would be funny to name their product Selenium. I think however that the last laugh may be on them, because selenium is not actually an antidote to mercury poisoning, it’s just a chelating agent for heavy metals including mercury and although selenium is an essential trace element, it is toxic if taken in excess. There is no known antidote to selenium poisoning.

Of Agile, ThoughtWorks, Selenium and Fitnesse

I have set up this blog to capture some of the problems we are bound to run into over the next 60 days.

I work for a well known (read busy) commercial website in the UK. We currently use a traditional waterfall approach to our software development life cycle, and we are under pressure to deliver more, and deliver it more frequently.

I am an ISEB certified Test Practitioner and I supported by two testers on my Team. Martin, a test analyst, who has achieved his ISEB/ISTQB Foundation certificate in software testing, and Robert, a junior test analyst who will be taking his foundation training later this year.

We are all aligned to thinking about software testing in the same way. That is, we have a clear set of requirements (be they, technical, business or design) and we test against those; simple no?

However in the real world it is never that cut and dried, and often requirements are thin, late or non existent, and (of course) liable to change at the drop of a hat. This is compounded further by the businesses increasing frustration at having to wait for a simple change to be implemented; we are only talking about a website here right? It’s not like we are trying to boil the ocean.

Cue Music – Enter ThoughtWorks.

Somewhere along the way the business got to hear of ThoughtWorks, a company that can offer (among other services) a helping hand for any software house wishing to become Agile. I don’t want to talk too much about ThoughtWorks and our relationship with them, because I only want to focus on the Testing aspect of becoming Agile, and because I could fill another blog with chatter about working with ThoughtWorks.

Anyhoo, we are a Linux, Apache, J2EE & Oracle house. So it felt right that we should use Selenium for our automated testing. ThoughtWorks originally created selenium so it felt right to use it with them. We have looked at Selenium in the past and I have used selenium scripts with the most excellent Reality QA product from the guys at GOMEZ (more on that later).

A couple of interesting points about selenium; Selenium is a chemical element with the atomic number 34 and is represented by the chemical symbol Se. Selenium can be found naturally in nuts (Brazil nuts are the richest ordinary dietary source), cereals, meat (such as kidney), fish (shellfish such as crab and lobster), and eggs.
Selenium is often touted as “The cure for mercurial poisoning” (being poisoned by Mercury), and any tester can tell you that Mercury produced (before being bought by HP) some highly priced automated test tools of the variety that “require plug-ins” to do anything more ordinary than record and playback (Test Director for instance). So I think the developers of selenium thought it would be funny to name their product Selenium. I think however that the last laugh may be on them, because selenium is not actually an antidote to mercury poisoning, it’s just a chelating agent for heavy metals including mercury and although selenium is an essential trace element, it is toxic if taken in excess. There is no known antidote to selenium poisoning.