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
Author Archives: Steven Thomas
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
Epics: My Love Hate Relationship with Large User Stories
Epics aren’t very good for driving the development team because Epics lack sufficient detail and will take too long to complete anyway. But Epics are, like their smaller relatives the user story, great as a place holder for a conversation.
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
4 Objectives for an Automated Test Strategy
I recently explained to my team the objectives our automated test strategy had to fulfil:
- Provides “living” requirements documentation
- Results in a comprehensive regression test suite
- Ensures high functional coverage
- Runs fast for developers
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
“Small” is an Estimate
One of the ironies of the discussion on no-estimates is that the no-estimate proponents do in fact estimate. In a small way.
Continue reading
Agile Programme Roles and Responsibilities
To go with my typical programme organisation I thought I’d describe the roles and responsibilities I expect on an Agile programme. Remember I’m interested in software delivery so I’m talking about programmes that have software development at the core. Non-software programmes would have a different mix of roles.
Some roles in an programme correspond to the roles in an project. The scale of responsibility is larger and emphasis on coordination greater but the nature of the roles is broadly similar. The Agile Programme Manager, Programme Product Owner and Technical Architect roles fit this mould, corresponding to Agile Project Manager, Product Owner and Technical Lead.
In addition a programme needs some roles that don’t appear at all in a project, in particular Programme Director and Business Change Manager. Again these roles are a result of the wider remit and increased communication necessary in a programme but also because of the focus on organisational transformation.
Continue reading