Specification by Example versus Behaviour Driven Development

Personally I favour the phrase “Specification by Example” over the more commonly used term “Behaviour Driven Development” (BDD). That is because I demand the specifications are by example but only encourage my developers to do outside-in test first development (from BDD).
Continue reading

No walls: What to do when you’ve no Walls for your Informative Workspace

You move into a lovely new office. Lots of light and open spaces. Beautiful. Modern. But no walls.

Agile kind of assumes you’ve got walls. Whiteboards. Sprint Plan. Product Backlog. Burn down Charts. Kanban boards. Cumulative Flow Diagrams. All prominently displayed to transform your office into an Informative Workspace.

So what do you do when there are no walls?
Continue reading

Manage All Assumptions as Risks

Assuming something means taking it for granted. In other words you’ve got a more or less conscious theory (or, less charitably, a guess) that something is going to happen. The trouble is that the assumption might not be true.

That screams risk. And as a programme manager or project manager you need to manage risk.
Continue reading

User Story Format Should Not Be a Straight Jacket

I use the formal “As <user role> I want to <action> so that <goal>” format when it helps. The main value of the format is it puts the focus on the users rather than on technology components. So if the user story is about user facing functionality then I will usually use the formal format as a back up to the shorter name of the user story.
Continue reading

When Meeting Madness Strikes

Some people and some organisations like meetings. If you drop Agile with its Agile Heartbeat into the mix then you might find that meeting madness strikes.

I’m a Kiwi living in the UK and I’ve noticed the British will form a queue if given the barest of excuses. Similarly, in some organisations, the people will call a meeting at the drop of a hat. People in coordination roles (e.g. project manager, discipline lead) seem particularly prone to this.

Don’t.
Continue reading

Agile Requirements Snail: Feature to User Story to Scenario

The Iterative Incremental approach inherent in Agile applies to delivered functionality but also to the requirements elicitation part of the process.

I like to refine requirements over time. Start high level, just enough to remind us to have a conversation, then fill in the detail just as we need it. What starts as a simple name of an Epic Feature will turn into multiple User Stories each with several Scenarios. But you don’t need all of that at the start.

The iterative nature of requirements definition is suggestive of a spiral process – what my daughter would call a “snail”:

Agile Requirements Snail

Agile Requirements Snail

Continue reading