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

How solutionising in your standup burns time you dont want to waste

This will be a very short blog.

I have been to tonnes of standups…….. tonnes……, and its not uncommon to observe a lot of solutionising.

You might also call it tunnelling; its when two people quickly dissappear down a tunnel of thought around an issue and rapidly lose the group.  You will know its happening when other people start to lean, drift, sit down, check their phones etc….

The issue might be important, and it might not be, but developers are often tunnelers by nature.  They dont like problems, they want to solve them. You can’t hold that against them, and you dont want to be constantly shouting “take it offline” else the standup’s usefulness will be a bit too regimented and people might think you are a being a bit of a militant pain.

So dev leads, standup leaders, scrum masters, agile coaches, heres a reminder for you:  If you have a 20 (overly large) person stand up, for every 3 mins you spend solutionising, thats a whole hour of development effort.  In fact in this case, if you spend (God forbid) 20 mins solutionising on various topics, with 20 people you’ve just burned the best part of a day.  Is a day worth it just to solve a problem thats far smaller than a day? No!  Of course not.

The best thing to do in these situations is take the topic off line, with an agreement that the related parties will (pardon the expression) “get a room”!!

Of course the time burned depends on the size of the group.  In many projects every hour counts, so I have written a little table to highlight time burned by solutionising.

(I was going to say time wasted but I think projects burn time whether its wasted or not depends on the outcome)

I hope you find it helpful.

Group time Solutionising 30 secs 1 min 2 mins 5 mins 10 mins 20 mins 30 mins
with 5 people 2.5 mins 5 mins 10 mins 25 mins 50 mins 1h 40mins 2.5 hours
with 10 people 5 mins 10 mins 20 mins 40 mins 1h 40mins 3h20mins 5 hours
with 15 people 7.5 mins 15 mins 30 mins 1h 10mins 2h30mins 5h 7.5 hours
with 20 people 10 mins 20 mins 40 mins 1h 40mins 3h20mins 6h40mins 10 h

Oh ..
and a handy standup link for those who want to find out more about standup patters:

Posted in Core Agile, stand ups, xp | 2 Comments

Developing margins

After a lengthly break from blogging, mainly due to the nature and intensity of my work changing, it occured to me….  that I didn’t have enough time, in fact, nobody had enough time… something that needed to change…

Divine revelation?

I was actually inspired by my local church on this one, on a message about developing margins for other people.  Being 100% busy is a symptom of the times especially around the western world, especially in London.  In the “church context” it was about having time for your neighbours, and even turning up to church early and hanging around afterwards spending some quality time with people, rather than dashing in and out, leaving barely enough time to say a “hi” or a “bye”. 

The rat run

I was challenged by this, not only on the personal social level but also on the commuting level.  From the simple task of how a commuter crowd fails to efficiently navigate through the turnstyles at Cannon Street station, using only 5 of the 15 available gates because they are in a rush thinking only of themselves, in doing so causing congestion for others by blocking the routes to the other turnstyles, if only they would invest a couple of seconds to spread out a bit, a couple of seconds cost to individuals works out to a minute saved for the poor people at the back.  To the “rat runs” in London where people barely leave any margin between cars, busses, taxis and errant bikes while crossing the road, near misses becoming the norm.   I have seen a couple of people lain out on the road over the past year because they got their margins wrong and been hit by a cyclist. Speaking of safety; margins also exist on the motorway suggesting a safe distance between cars.

margins used in traffic

The workplace

What I am most interested in are the margins in the professional realm of software development.  You could expand this to any aspect of project management too.  Now this is an area where there is some recognition from other professionals who realise that a project should have something called “contingency”, a good project should have “contingency” in its plans, its a good high level rule thats generally accepted, but it doesn’t tend to get looked at in any great detail. 

If it works, then lets figure out why, and exploit it.


Margins can mean many things, from the white space that surrounds the context of a page to the type of financial collateral used to cover credit risk.  The margin context I am referring to is the provision of buffer space between the time you take to do something and the boundary which is set to do it.

How margins work:

On a personal level:

They enable you to help others, at “your expense” and “their profit”. 

It enables other to help you, at “their expense” and “your profit”.

The net effect is that at a cost to the individual, the team wins.  Not only that the individual often wins too as by seeing a problem from a different context, gains domain knowledge.

At a project level:

During estimation if you leave a margin for development and delivery:

You invest the cost of delivering later to:

1) De-risk the project from a late delivery due to unknown factors
2) Accommodate late changes
3) Invest in quality for reuse and building future projects
4) Invest in accuracy and quality of the current deliverable

At a department level:

If you leave a margin for your yearly book of work you:

1) Promise fewer deliverables up front to reduce the risk of the compound effects of delayed and late delivered projects
2) Promise fewer deliverables to allow the teams time to reflect and improve on how they are working and therefore deliver more effectively in the future
3) Promise fewer deliverables to help retain team members in the organisation and therefore their learned domain knowledge.  Therefore removing the need to invest in domain knowledge again and again due to a higher turnover of staff (with little guarentee of success or margins at any level).
It sounds a bit like common sense does it not?

The endemic underlying challenge to margins

Firefighting, Inherent Win-Lose mentality and rewards are the anathema of margins. 

Firefighting, robs us of our free time, it is usually unplanned work of high urgency requiring 100% attention at the cost of everything else. Firefighting is the precursor to more firefighting in a viscious circle as often the time required firefight (eg. code quality checking, QA windows etc..) cuts into the margins (if any) to produce good code in the first place.

How not to use margins

I have seen margins being used only at the end of a piece of work, these margins inevitably get used up.  This is when people dont invest the time earlier, but allow it to be eaten up later.  An hour not invested at the start of the project to make something better, will easily expand to five hours later.  The end result being that the quality isn’t there. You need to apply margins on multiple levels.

Do not confuse margins with planning

The more planning you do at the beginning of a project the more re-planning you will need to do mid way through the project when you begin to deliver the code, and find out that it needs tweaking or there were a few issues with testing.  What the margins enable at the beginning of a project is to invest in quality.  The margins you will have at the end of a project will help in added or changed functionality.  The cost of change is lower because of the quality of resuable code, the fact that nothing was rushed due to late night working or high pressure means instead of fixing bugs in the provided margin, you can actually add or refine functionality.

Posted in behavioural change | Leave a comment

What to do when you find resistance to change….

Back from holidays and ready to blog again. After a sustained period of overlapping work it had reduced my creative capacity somewhat.

Many of us have come across resistance to change while attempting to move a company more towards agile.

The classic story:

Hey we have a great job for you, just come and lead/work/be part of our team. We do agile software development and simply love working in an iterative manner. We have stand-ups and product owners and free ice-cream on tuesdays etc…

Sounds promising

Upon arriving and while not being ignorant to the fact that agile adoption requires both top down and bottom up change you get faced quickly with the real situation, which is: (not restricted to multiple layers of middle management) “I’ve done it this way before, it sort of worked then, I wont change it now”.

This can often discourage those new to agile from continuing in their agile career and in a state of “norming” simply adopt the path of least resistance.

I could perhaps give about 5 anti-patterns off the top of my head right now. But we all know what the problems are, as we are regularly faced by them, in fact whereever software development occurs you will find resistance to change.

Thing is people dont realise that change is here to stay! (I know cliche!)

So I am an agile adopter / coach / scrummaster / what do I do.

You have two options

1) Quit and work for an agile company that are already fully agile, eg. Rallydev Thoughtworks or perhaps try a more company which is genuinely agile. (Though the former might not be so impressed if they thought you weren’t able to at least convince your former colleagues that agile is a far better way of development even if changing them is far beyond your control).
2) Stay

Within option 2) you have also two options.

a) Choose to norm.
b) Choose to change the company.

a) If you choose to norm. I believe you will quickly become jaded, demoralised and perhaps institutionalised. This is dangerous for agile, especially if you are professing to be agile, in which case its like agile without the discipline or reinforcements that provides the transparency and feedback that is required to make good software in a reasonable amount of time.  If you do norm, make no pretense that you are doing agile.  In the hope that should they attempt agile again, they wont think that they have tried it and failed.  Agile is a revealer of the inherent problems in a system, this often causes people to blame agile more than change their failing system.

b) If you choose to change the company, then you have chosen a difficult thing. However this is my favourite option. I personally love this challenge, you may however need to manage your expectations you had when you joined the company.

To find out how you can change the company, you can often look at what doesn’t work and do the opposite.

1) Change everything all at once, on your own.

– Doesn’t work, because you get spread too thinly. You cannot back up your ideas and concepts.

Agile is iterative, reflecting frequently in small bursts, learning through small changes here and there. Its far better to do agile well with one team than attempt with 7 teams at once. You need to take something, own it, demonstrate the improvement and then move on with that as your foundation.

2) Expect everyone to agree with you and jump on board.

– Often it takes 1 to 1 persuasion and demonstration to get people onside. People dont like change. You might think that developers always are the first to embrace change, but (people – being people) dont often like the discipline that comes with agile. Often developers love to ditch the documentation and component designs but hate to become accountable to their code, especially their designs and techniques.

Guess what, sometimes people dont want to change, and you can’t make them. Which means you need to be stronger in Agile than they are in waterfall, or cowboy, or anti patterns etc… be prepared for conflict and stand your ground, but dont be a person of conflict for the sake of it. You prove the point for better software not to win an arguement.

3) Fight on all fronts.

– Like with spreading yourself thin, you dont need to argue agile on every case. You might see 50 improvements you might want to make, but guess what, they dont need to know about 48 of them right now, they can discover the others in a few weeks time. Work it bit by bit. You might want to ask the question “How are we being agile” as opposed to “are we agile”. Dont bash people with having standups perfect, TDD perfect, retrospectives perfect, customer relations perfect (product owner) all at the same time in the first week. (Unless you have the people at hand, and you have a big stick and they are co-located and perfect developers with perfect personalities). Work on common challenges one at a time. Allow the team to identify problems and then feedback themselves, treasure discovered is more valuable than treasure given.

4) Pure servant leadership.

Servant leadership is often described the best way (and I would tend to agree for many reasons), however its hard to influence if you have not got a stick. You see shepherds have a stick, they herd sheep, they dont need to beat the c*&p out of a sheep to get them going, they just need to show the stick, they stick saves the sheep, pulls them out of trouble and leads them in the right direction. Sometimes if you haven’t been given a stick (authority) its best to obtain one, get a bit of grit in yourself and you can do it. Its quite forgivable to leave if this doesn’t work at this point, however I have a strong belief that through persuasion, you can bring about change . Get some nuts. (Shameless Mr T Snickers reference). A great idea is to get linked in with a supportive community, perhaps like the XTC (Xtreme Tuesday Club) they will help back you up and repair you after your persuasion battles.

thats all my musings for now, and this is not an exhaustive list.

Posted in Uncategorized | Leave a comment

Naked Standups

ah I see I have your attention 😉

I recently hosted a small session in an “unconference” in Deutsche Bank where we talked about daily standups, we talked about the various patterns of reporting, eg. what did I do yesterday, what am I doing today, whats impeding me, and how you can change the “do” word to “learn” (a kind of learning model suggested by Liz Keogh picked up in a recent Qcon conference) and changing the “do” word to “achieve” also to get a little more focus on committment.

I am fine with those, I think they are a good idea.

We also talked about distributed standups and the idea that you might all be sitting down having a mini-conference call, or crouched around a conference phone standing next to the task board.

But what I am most interested in is the quality of whats being said.

Naked standups

Naked standups are when people can talk completely freely about what they are working on without the feel of intimidation from a boss, or colleague who may be a bit of a task master or someone who looks down on you, or what went on in the previous day. It ties in very well with the “Safety Check” used in retrospectives and facilitated meetings.

Something I have noticed about standups is that some people tend not to reveal everything, or rather they withhold a little information so instead of being transparent for the benefit of the team, they are a little opaque for the perceived benefit of self. This is influenced by:
who is there
the culture of the team
the culture of the department or company
their recent (coding) actions
how (more often) bad or good something is,
personal shyness,
I could go on!



How do you deal with these?

Well I am not going to tell you how to change the culture of a company, I’m writing a blog not taking over the world! However most of these could be helped with those conversations you have at the coffee machine (or posh franchised yet subsidised coffee house in your building), over lunch or down the local pub or company gym.

What we can strive for ourselves is to remember that the better standups are the ones where we are not afraid to denude ourselves in order to resolve issues and develop better as a team

Posted in Core Agile, stand ups, xp | 2 Comments

Pair Programming, “Recognition vs Recall” and Keyboard Shortcuts

I cannot find anything about this in suitable detail on the web so I am writing my own:

what we “learned” in school

IT students (including myself way back when) have been sold the story that recognition is much better than recall when they use software, in fact its evolved to the mantra “recognition over recall” for all things IT and web related. Of course its right, when using a GUI or windows XP or something new on the web, and especially if I am a new user I’d like to recognise things that I can click, I don’t want to have to read a manual and have to work out what to do, and learn the hard way else I will use something else, another operating system or different website.

However when it comes to repeated actions, including software development, especially using IDEs its a completely different story. You might then say, hang on a minute why wouldn’t recognition work here. But let me start with the driving analogy as most of you will be able to drive.

Car journey

Lets take a car journey using recognition for driving.
Get in the car, adjust the seatbelt, start the car, wait. how do I do that, oh yes, turn the key hang on gear stick, is it in neutral? no, push the clutch in, wheres that? oh yeah left foot, turn the engine on, bring up the clutch change the gear, I can see all of these, this is good, the car starts moving I can look and go for a drive, eek the car is revving, back to the gear stick, change gear, oops need the clutch, clutch in change gear, revs are fine, ah yes the road, what are those? mirrors oh yes anyone behind me? anyone in front of me? yes, brake, car slows down engine struggles, oh yes change gear, hold on push in the clutch change the gear use the clutch look at the road. Where were we going again? Oh yes turn left, which means look a the mirrors make a signal, look at the indicator stick and use it (left hand side for english car, right hand side for japanese) look back at the turning slow down, take the turn. Phew.

Notice how I wasn’t focussed on the journey. Many of you will remember this is what it was like when learning how to drive a car.

Now lets take a car journey using recall.

Get in the car, (habitually put seatbelt on) start the car, (left foot on clutch automatically put it into first) car pulls away, you look at the road, anyone behind? anyone ahead? yes slow down,(change gear), left hand turning coming up, turn left, check behind and automatically signal.

Whats the difference? Well in the second example I had learned and put into a recall mode HOW to drive the car and I was more focused on going on the journey.

I was thinking more about the journey as opposed to how the car works. If I have to think more about how the car works everytime it can get exhausting when the purpose of driving is to go somewhere.

Right lets bring it back to programming.

Or more importantly the word “Recognise” involves cognition thinking, it literally means “to know again”; when you are recognising something you are actually thinking about it. If you are thinking about it then you are not thinking about anything else. You are context switching, and we humans dont multitask well at all.

However if you can recall an action, you can sub-conciously do the action while focussing on the problem at hand.

Lets take running a JUnit test in Eclipse as an example. Note the JUnit test key combination is probably one of the hardest to do of the shortcut keys:

Recognition way #1:

* grab the mouse
* look for the run icon
* see “Run as” hmm nothing under there
* go to “Run configurations” because you’ve just seen that, ooh unit tests appear
* click on run – unit tests runs
* get back to coding

Recognition way #2:

* grab the mouse
* look for the run icon
* spot the JUnit view, click on it
* see the “run again” icon
* click on it – unit tests runs
* get back to coding

Recognition way #3:

* grab the mouse
* look for the run icon
* spot the JUnit view, click on it
* right click on the unit test
* click on run – unit tests runs
* get back to coding

Recognition way #4:

* grab the mouse
* right click on the test document
* filter through the 50 options til you get “run as”
* see JUnit test click on it – unit tests runs
* get back to coding

There are more!

Recall way:

* Alt + Shift + X then T
* Worst case: “No JUnit tests found”
* Action: navigate (Alt and left arrow perhaps) to the unit test, then “Alt + Shift + X then T”
* Took 1 second, didn’t necessarily touch the mouse.

If you take the time to learn the Alt + Shift + X then T command, (just like you took time to learn to drive) then the Recall way is not only much faster it gives you more thinking to your problem domain.

The same applies to most actions which employ the mouse, if you are looking to “Do” a function then you are not “Doing the function”.

To quote the Matrix “Stop trying to hit me and hit me.”

Stop trying to code, and code, just like Rob said

Let me rephrase “Stop trying to code and code”

Its role within paired programming:

Firstly with two sets of eyes, the less time you spend faffing around with the mouse the more time both of you can spend on the code and the conversation about the code. When you pair program for the first time you notice how much time you waste by doing the code related tasks as opposed to doing the coding itself.

How do I learn this?

You can only learn it by practicing, no-one knows instinctively how to drive and change gear and follow the rules of the road, the best way you can learn is by practicing often with someone else who will show you the keyboard shortcuts.
If you are completely new to it, start with the simple Ctrl+S to save what you are doing, rather than grabbing the mouse and looking for that icon, which inevitably is too close to the print dialog and “create new project” wizard.

If you dont have someone else to help, then here are a few shortcuts for Eclipse that will help you:

ps. I have noticed Ctrl+F11 works too, but I prefer “Alt + Shift + X then T”, you can easily do it with one hand without looking at the keyboard, get a different keyboard (especially with paired programming) there is often a different function key layout you need to look down all the time.

Oh and if you are an IntelliJ fanatic, good for you! #notThatIamJealous

Posted in behavioural change, multitasking, pair programming, xp | Leave a comment

FitNesse and Java vs Cucumber and Groovy

I was recently tasked with piloting a couple of design tools designed to help us with our development.
The first one was FitNesse, and the second Cucumber with Groovy.

The problem with “cutting edge” pieces of software tooling is that the tutorials are often up to the mercy of those who pioneered it. This is not always a good thing. In fact unless they are communicative experts its a bad thing; its a bad thing because the guys who come up with this magnificent software aren’t always the same as the guys who are able to write the best tutorials, and explain the simplest concepts (or see the need to).

What is FitNesse?


“FitNesse is a software development collaboration tool
Great software requires collaboration and communication. FitNesse is a tool for enhancing collaboration in software development.

FitNesse enables customers, testers, and programmers to learn what their software should do, and to automatically compare that to what it actually does do. It compares customers’ expectations to actual results.

It’s an invaluable way to collaborate on complicated problems (and get them right) early in development”

Well righto! thats right and its also correct, so what is it?

Well its this diagram and this is the truth:

So what is it? (Those who remember Cat in Red Dwarf a cult tv comedy classic )

In one sentence:

Its a wiki, that enables a BA to put in expected outputs given inputs, which plugs into an easily codable Java adaptor designed to plug the values into your system. (ah why didn’t you say so)

What do you need?

Developers willing to code adaptor classes that populate your business objects/services using setters and getters.
BA’s willing to use the wiki, and learn its own little language syntax.


Overall it was quite straightforwards to setup, I found the options were not amazingly intuitive but after a while I got the hang of it, and its nice to see the green filling in the boxes to show your adaptor (fixture) class is discovered and tests passed.

Cucumber and Groovy

What is Cucumber and Groovy?

Well seems a little simpler from the outset but it has no wiki. The idea is:

1: Describe behaviour in plain text
2: Write a step definition in Ruby
3: Run and watch it fail
4. Write code to make the step pass
5. Run again and see the step pass
6. Repeat 2-5 until green like a cuke
7. Repeat 1-6 until the money runs out

Ah looks good except for the Ruby bit because I have Groovy, and that took long enough to get working. Good news comes in the form of cuke4duke which gets Cucumber to work with Groovy.
Fortunately the guy who did it had some examples underneath the tutorial (Aslak Hellesoy) and I was eventually able to piece together some command line prompt uses from elsewhere on the net.

So what is Cucumber and Groovy in my words?

Cucumber involves a form of structured english language in the form of a scenario or set of scenarios.


Feature: BMI Calculator Feature
In order to ensure that my BMI calculator
As a Moderately Overweight Developer
I want to run a cucumber test find out if it works or sucks

Scenario: Robert thorough
Given I have entered Robert as a name
And I have entered 5 in feet
And I have entered 9 in inches
And I have entered 190 in pounds
When I call calculateBMIService
Then the stored result should be 28.1
And the stones should be 13 Stones

Groovy then receives these instructions and using regex sneakily uses the JVM (without compilation need) to test the assertions.


Before() {
input = new com.rob.calculators.BMICalculatorInput();
output = new com.rob.calculators.BMICalculatorOutput();
bmiCalculator = new com.rob.calculators.BMICalculator();

Given(~"I have entered (.*) as a name") { String name ->


I found it a little trickier and slightly frustrating to setup in terms of command line stuff, but I eventually got there, configuration is the bane of me so this is where I am most likely to get frustrated and give up, but after I got there it seemed to behave itself!

and thats it.

What do I prefer? hmm JUnit, maybe thats because I am willing to sit with a BA/Tester/Person and write the unit tests so theres a bit of affinity bias there 😉

I actually like them both, but I would say that Cucumber may edge it, for the domain language used will help slightly more in delivering business value, but I would expect both of these to evolve over the coming months and couple of years to something where both are better than either of them now. The only thing that put me off about the domain language of FitNesse was the use of “Fixtures”, quite obvious when you know but not when you don’t, remember its about selling this to those who are new to the product. If they had said the slightly more wordy “Custom Static Adaptor” then as a Java guy I’d know about it, and as it in my case is written in Java then thats the right domain terminology. They could have written “Custom Glue Code”, and I’d have had a better idea too, the name itself made me think that its another domain specific language with nuances I need to learn.

My real point is this:

These are great great tools, made by extremely intelligent people (far more than myself) but often they dont have the time to sell it / package it / sugar coat it into something that will be found easy by all those invovled in using it, and by that I am talking business and BA’s.

Its one thing creating an expert tool/concept/idea, but if you can explain with examples in a really simple manner then it makes the job easier for people who come across the tool (who may not have fantastic communication/selling skills) who want to adopt agile and are also trying to sell to their bosses so they can get top down buy in.

In balance now I know them a little more I’d be comfortable with using them both, in fact I would try them both rather than reccomend one of them, each project team has a slightly different domain, and remember we are into writing really good software, whatever tool works best we use. If the company is “wiki-mad” and the requirements are less wordy and more calculative and the Java developers very enthusiastic then there is no reason FitNesse wont work well. If you already use Groovy it may be a mistake to go towards FitNesse, but still try both and see! Experiment!

Posted in Agile Requirements, BDD, Cucumber, FitNesse, Groovy | 3 Comments

Agile, lean and kanban exchange 2010

I recently attended the agile, lean & Kanban exchange in London

Sadly I got snowed in Thursday, and after hiking 2 miles through snow to a station that was closed (people were telling me on the way it was closed!) I decided to turn back and spend the rest of the day with the family.

Friday was different, and through taking 2 busses I managed to get to a peripheral station heading in to London and to conference utopia!

I attended the talks on Retrospectives in the morning ran by Rachel Davies, and got a few extra nuggets to try in future retrospectives. Namely

  1. Using a checklist (no I still haven’t sorted that out yet, I usually book a room with a 15 min buffer and then prepare it as I see fit – prime directive, columns on board, old tasks etc… before the team arrives).
  2. Not using the Good/Bad columns, this suggestion was made because it tends to polarise the teams and can affect how people contribute to the session.
  3. Allowing more time for the actions at the end. Rachel used a diagram to explain that part of the meeting is looking back and part of the meeting is looking forwards to the next sprint/iteration, so 50% of the time for actions is not a bad idea.
  4. Actions taken can actually be further broken down into smaller pieces so they can be scheduled into the next sprint/iteration.

The next talk was by Patrick Kua from ThoughtWorks and was on “Making Management work with Agile”. Patrick expertly presented about some of the issues and challenges that are faced by agile teams using a bottom up agile approach. These fell broadly into the following areas:

  1. Planning
  2. Measurement
  3. Direction
  4. Problems solving
  5. Decision making

Some of the key quotes and points included:

“Tell me how you measure me and I will tell you how I will behave” (Eli Goldratt), this in fact is my favourite point of the whole session, and it took a while to for me to get it! It can be applied in a whole number of different ways. For example, if you measure the number of tasks done, people will create lots of tasks, and then focus on the number done perhaps as opposed to the priority. Another example – if you are recording bugs fixed, then maybe people wont be too careful about preventing them because they can be fixed. Its the difference between delivering value verses ticking a box in a way that value doesn’t have to be delivered.

Other key quotes included:

Genchi Genbutsu (go and see for yourself) – there is only a certain amount you can communicate over the phone, to see the whole picture you need to be present. (Principle of the Toyota Production System.)

Having no problems is the biggest problem of all (Taiichi Ohno)

Management processes with budgeting at their core are not neutral in their management, ie. budget drives decisions not value driving decisions.

A bad system will beat a good person every time (W. Edwards Deming)

You can catch the slides here:


We then had lunch followed by the Open Space Unconference Sessions facilitated by Rachel Davies.

I have never been part of an Unconference before, and to be honest I was a tiny bit unexcited about it. However it turns out that it is based off feedback from previous conferences where attendants reported that the “coffee time” where they networked and spoke to others in the industry was in fact the best time for them as they were able to share and discuss their challenges and find solutions to their individual problems.

Unconference works by interested people placing a “topic” up on the board randomly choosing a time and a location and then attendees examine the board and chose a “topic” from those posted to attend. Its very open, and attendees can be like bumblebees and go from one to another if many are being held at the same time, or they may wish to stay with a particular topic. The only rule is that the originator must stay with their own “topic” for the duration.

The unconference in session, topic setters seen queueing on the right, facilitator Rachel Davies sitting on the left

One of the “topics” I went to involved the playing of a software development “game” using dice to determine software completion and bug introduction and was run by Liz Keogh and Jon Jagger. Good fun to watch!

Stakeholders, analysts, developers and testers with Liz Keogh at the top of the table, behind is the velocity indicator

Overall an excellent day, sadly I had to get back home (weather) so I missed out on the pub. Perhaps next time! For those who have never been its definitely worth a look, and for those who have gone, well the feedback for those I secured tickets for was extremely positive!

Posted in conference, Core Agile, kanban, lean, skillsmatter | 2 Comments

XTC (eXtreme Tuesday Club)

I thought I’d share my experience of going to the XTC for the first time.

Having heard that its ‘A regular London meeting (weekly) for XP newbies, practitioners, and experts. Like XPday it’s ‘more than just XP’. See some of the previous meetings for examples of what gets discussed”

Fortunately it was situated within walking distance of where I worked so 20 mins after work I arrived bang on 7pm to quickly find myself talking to a group of Agile enthusiasts. Some of them had extensive experience of their field of Agile, some moderate and some were newbies urgently seeking answers to their mid-project predicaments. Some knew eachother well and there seemed to be a core of a few practicioners who expertly worked their way around the groups so they weren’t stuck in cliques.

The topics of discussion ranged from rightshifting, to how to bring in TDD from a distributed perspective, to corporate agile adoption and even further developing the agile manifesto; Tweaking the delivery of “working software” into “business value” and identifying the fact that the “user” is a mythical beast and in fact there are a range of stakeholders out there as well as many personas of end users.

Some people ordered food, others ordered a mix of alcoholic and non alcoholic beverages, typically in proportion to how many questions they had. Note: If you are looking at taking notes (even mental ones) probably best to stay as non-alcoholic as you can.

Me slouching near the right of this picture, picture courtesy of Tom Gilb

Over all I thoroughly enjoyed it and will be going as often as I can.

The one I went to was this one:

Posted in xtc | Leave a comment

Agile Multitasking

I went to a skillsmatter session last night, and a great one it was too!

Coffee, the hidden key for multitasking?

All about how to “multitask” and “context switch” in an Agile manner (NOT!).

Greg Gigon dismissed the myth of multitasking (well at least for the male) by highlighting that just because computers can do it, with their multiple cores, we only really have one, albeit large mysterious and internally unknown and so we cant really multitask. Greg supported this with various statistics about how trying on two tasks at once inevitably takes longer than if you did one at a time.
The key phrase for me was “attention rich”, quoting biologist Dr. John Medina “We are biologically incapable of processing attention rich inputs simultaneously”.

Take reading this picture for example:

Multitask this!

This multitasking is not a new problem. But it has been recently exacerbated by the role that media and pcs, phones, twitter, facebook etc.. have taken in our lives.

Not a new problem at all; In fact 100’s of years ago Lord Chesterfield said:
“There is time enough for everything in the course of the day if you do but one thing at once; but there is not time enough in the year if you will do two things at a time.”

So what’s this got to do with me?

Well Greg led us on to talk about how we can AVOID multitasking in our daily working lives. The biggest one he talked about was removing interruptions.


Interruptions comprise of but are not limited to the following:
colleagues needing help,
blockers in your own work,
phone calls etc…

Often the problem is also us, in that we interrupt other people from working because of our own problems.

So how do we fix this?

Greg suggested a number of answers, including:

Pomodoro technique – (see Gregs blog at the bottom for details on that) its essentially a time focus technique, working with the natural ability of the brain to focus on tasks for short periods of time.

Paired Programming makes it less likely to check emails, twitter, facebook etc, you are also less likely to be interrupted by people!

Kanban helps limit the number of tasks people are working on.

Also music, that is “familiar music”, can help people tune out and focus on what they are doing, this is contrary to what I believed at the time, but it does make sense. I personally cannot concentrate well listening to music, but if its music I know well apparently the brain processes it differently and acts as a wall against other background interruptions. This will obviously not work for new music or radio.
I’ll admit that when I have worked listening to music its because I am doing mundane work or less brain intensive work (think documentation).

I might also add a couple of my own ideas and one is where you simply have a todo list, visible and in front of you. My personality is that I like to achieve things, and I feel like I have been rewarded if I can strike things off my list of things to do! I am also in the process of using my very own task board, this makes what I am doing very public, and transparent, and therefore will also help me keep focused during the day. manage people’s ability to be interrupted.

Another idea is to manage interruptions using visible signs (ie. headphones on head means stay away) or even messaging statuses. You could also make a couple of programmers available for contact and by implication the other programmers are not available to people like the business. Obviously getting the balance right is important.

For a far better description of these principles please visit here:

this is good too on multitasking!

Posted in multitasking | 3 Comments