Antony Marcano's blog

My Tack on Effective Change

Sat, 13 Nov 2010 08:19:44 +0000

One of the key characteristics of how we coach our clients’ teams is that we help them start from where they are and introduce small, frequent changes that help them progressively achieve their goals.

Each incremental change is driven by a problem the teams recognise they are facing. We then help to find a small change they are happy to introduce as an experiment. This change must be a solution or a step towards a solution to the identified problem. Sometimes this experiment will be limited to a single iteration. Sometimes it’s limited to a single user-story in a given iteration.

Based on the outcome of the experiment, the team decides what to do next. They may continue the experiment, introduce the change beyond the limitations of the experiment or even abandon that change and try something else.

This has two distinguishing factors...

Read the rest of this article on my new blog...

youDevise series on my new blog

Sat, 24 Jul 2010 22:22:32 +0100

I've started a new series on my blog... it's a weekly diary of what it's like to work with youDevise as a developer. I thought it might prove interesting to those considering working there in the future... since they are frantically hiring.

You can read the diary on my new blog.

Wondering why I have a new blog?

Monsters, Names, Pot-Roast & The Waterfall Model

Tue, 13 Jul 2010 00:47:18 +0100

“Antony” (without the ‘H’) is the anglicised version of Antonius. In victorian times (there or thereabouts I’m guessing), among those wishing to appear oh so intelligent, gossip spread that the spelling of “Antony” was wrong… For, so they would say, it is born of the greek word “anthos” (meaning “flower”) – oh dear… so many poor children with misspelt names…
Despite being completely wrong, the world forgot of my name’s etruscan origin and spelt it with an ‘H’… This misinformation established itself through the eras so much so that, today, the de-facto spelling is “Anthony”. It has even found it’s way into the American pronunciation of the name as: “An-thon-ee”.

Waterfall development has something in common with this story… somehow, through misinformation, what it once was has been warped, into something else.

The key difference is that Waterfall is now increasingly represented as was originally intended. Unfortunately for me, my name is not…

Read the rest of this post on my new blog...

Wondering why I have a new blog?

My blog has moved... but don't panic...

Thu, 08 Jul 2010 23:57:20 +0100

I’ve decided to move my blog. This is a sad day for me, but my posts have long-since outgrown testingReflections. The content of my blog posts is now about so much more than just testing that it doesn’t seem to make sense hosting it here anymore.

I’m still the curator of testingReflections and intend to continue to be so, as I still get many people telling me how valuable it is to them. I have many plans for it, to bring it up to date but I simply haven’t had the time. I am working hard to make that time, so I appreciate your continued patience.

Feature Injection User Stories on a Business Value Theme

Fri, 14 May 2010 07:45:24 +0100

Feature Injection, an approach to Agile Business Analysis created by Chris Matts, is a much misunderstood thing –. It is a way of combining several techniques to understand just enough of a business problem to start expressing solutions to it. It provides specific techniques to incrementally and iteratively comprehend each of the following:

The business value sought (the why)
The problem domain (what specifically needs solving to deliver that value)
The resulting roles, incentives and product capabilities (the solution)

Basically, it helps us to evolve everyone’s understanding of the business-need as we (by other means) also evolve the implementation of the product.

Developer Race-Tech: Continuous Testing

Thu, 29 Apr 2010 00:12:48 +0100

Gearboxes in competitive motor racing are designed to shift as fast as possible. A competitive race-car has computer controlled, hydraulically activated gear shifts that change gears up or down faster than you can blink (literally)! Compare that to the circa 1 second gear-shift a competent driver takes to manually de-clutch, change gear and re-clutch on a road car. Even automatic gearboxes on road cars can't keep pace with the rapid gear changes that a race car delivers.

Adaptive Budgets? "Pull" the other one!

Sat, 10 Apr 2010 11:49:54 +0100

Recently, I wrote about my views on using and estimating with task-cards. I highlighted that tracking progress with burn-up/down charts showing effort completed/remaining is not a true measure of progress, especially if we subscribe to the idea that we measure progress with working-software.

I also highlighted how tasks "horizontally slice" a "vertically sliced" story.

Taking repetition to task

Tue, 30 Mar 2010 06:36:43 +0100

Others have talked about the virtues of stories as vertical slices of a problem (end-to-end capabilities) rather than horizontal slices (system layers or components). So, if we slice the problem with user stories, how do we slice the user-stories themselves?

If, as I sometimes say, acceptance tests (a.k.a. examples/scenarios/acceptance-criteria) are the knife with which we slice a story into even thinner vertical slices, then I would say my observation of 'tasks' is that they are used as the knife used to cut a story into horizontal slices. This feels wrong...

Keeping pace with an evolving understanding

Fri, 26 Feb 2010 11:32:56 +0000

One of my ongoing rants was described to me as "awesome" (thanks Amy). I'm sitting here at the early moments of XTC and rather than procrastinate about writing this post, I decided to do it now! Despite doing that, it seems that it took me a month to get round to publishing it!

My rant is often a reaction to conversations that arise about what makes something "Agile". Often, in these conversations the other person places emphasis on "Agile" branded practices. One of the key dimensions of agile methods is a recognition that human beings don't know or understand things 'instantaneously'. We learn in an evolutionary way. This is no different whether we are evolving our understanding of somehting on paper (e.g. in UML diagrams and other such paper based modelling mediums) or whether we are representing this in a tangible, interactive, real implementation of what we think the customer wants. The key difference is that the customer can learn more about their own understanding of the problem they've asked us to solve by using something real, rather than just working on 'paper' (albeit virtual paper).

More Sharks and Delaying Critical Mass

Tue, 19 Jan 2010 15:37:02 +0000

In a previous post I talked about Critical Mass of software. I showed how an ever-increasing cost of change resulted in it becoming more economical to completely rewrite the system than to enhance and maintain the original.

I explained how this could be avoided by using practices that sustain a consistent and flat cost of change. I also mentioned that you could defer reaching critical mass. Some teams find it difficult to get the time to do this because "the business" always has "more important" or "higher-value" things on their backlog.

Sharks, Debts, Critical Mass and other reasons to Sustain Quality

Mon, 18 Jan 2010 19:06:48 +0000

A while back I tweeted about critical mass of software:

Critical Mass of Code - past which the changeability of the code is infeasible, requiring that it be completely rewritten.

An elaboration of this might be:

Critical Mass of Software: the state of a software system when the cost of changing it (enhancement or correcting defects) is less economical than re-writing it.

This graph illustrates a hypothetical project where the cost of change increases over time (the shape of which reminds me of a thresher shark):

MARTA - Risk Management... beyond mitigation

Sun, 01 Nov 2009 20:08:05 +0000

In a previous rant about the misuse of the term mitigate in the context of risk management I listed the following strategies (I call them MARTA) for managing a given risk:

Mitigate - Reduce the severity of its impact

Avoid - Don't do the thing that makes the risk possible

Reduce - Make the risk less likely to happen

Transfer - Move the impact of the problem to another party (e.g. insure such as paid insurance or outsource with penalties for failure)

Accept - Do nothing or set aside budget to cope with the impact

I recently found myself having to explain this and used the analogy of crossing a busy road with fast-moving cars. What's the risk? Well, you might get hit by a car.

CITCON Paris 2009

Sun, 20 Sep 2009 10:47:33 +0100

This weekend I attended CITCON Paris 2009 with my friend and business partner Andy Palmer. It was a fantastic event, although next time I think I'll volunteer fewer sessions. Andy and I found ourselves playing a major role in most of the sessions we attended which was absolutely exhausting!

JNarrate & ScreenPlay (formerly known as WebUser) Framework... what do you think?

Mon, 20 Jul 2009 01:48:56 +0100

Update: The 'new' WebUser's name has been changed to ScreenPlay4j. All rererences to the new WebUser below should be taken as 'User'.

At the first Agile Alliance Functional Test Tools workshop, I briefly showed a spike I'd done that illustrated how straight forward it would be to write acceptance tests in code. It was somewhat inspired by work already done on things like JBehave and RSpec. However, while they moved further away from code and towards plain text, I went in the opposite direction.

FitNesse - NarrativeFixture Story 1 nearing completion

Mon, 22 Jun 2009 22:09:45 +0100

The FitNesse Narratives project that I've been working on along with Andy Palmer, has reached a major milestone - our first story is functionally complete. We're finishing off some refactoring and need to automate the build but once those things are in place our 'Iteration 0' Story will be done.

I thought that you'd like a preview of the NarrativeFixture, the star of this story, so you can start to see where we are going. You'll be able to get your hands on it and use it yourself soon enough.