Author Archives: Steven Thomas

About Steven Thomas

Steven Thomas an independent Agile Programme Manager.

The Sign Off – An Example of Delegation and Decision Making

Posted on by

I had just joined a team as programme manager and was talking to the lead user experience (UX) designer about the latest version of the UX design. We’d not worked together before and this was the first time I’d seen the designs. They looked pretty good to me and I told her so. That is when it got a bit weird.

PgM: They look great.
UX: Okay, I’ll get everybody together to get sign off on the designs.
PgM: Um, who is everybody?
UX: <Lists names of the business representative, product manager, technical architect, business sponsor, technical sponsor, UX discipline lead for the department, development manager, portfolio manager, team assistant to take notes, and quality manager>. I hope they don’t want too many changes.
PgM: <Jaw drops>

Continue reading →

Specification by Example versus Behaviour Driven Development

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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

Posted on by

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 →