“When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go.” — Nanny McPhee (via Lyssa Adkins) I am an Agile coach and the goal of my job is to put myself out of a job. My mission is to teach people Agile and to make sure they understand and c...

Checklists have a somewhat bad reputation in the Agile world, probably because they “smell” of too little self-organisation and too much process. I find this reputation is entirely undeserved as they can be extremely useful as a memory aid, or to visualize a workflow. Checklists play an important r...

For four of my six and a half Agile years I was solidly in the Scrum camp, Lean, in my opinion, was already part of Scrum and its influence made Scrum even better. I don't think that any Agile practice is for the work shy and there is a lot of personal courage needed to get any practice working well...

A “done” definition in an Agile project is a statement that the team use to measure whether they’ve met all of the requirements for completing a userstory / feature (and in some cases completing an iteration or release). Done is one of the major shifts from doing Agile to being Agile. So, what is “d...

Software projects experience a problem called technical debt. In short, technical debt is the result of making a quick and dirty work around (often for valid reasons such as deadlines) which creates rework later. I recently visited an organisation that had a wall of pain which I thought was an excel...

Many people’s first encounter with an implementation of an Agile framework is the visible workspace. I find first reactions to this very telling: for some it feels like a natural way of expressing their work and they can see what is happening in an instant, while for others it’s some cards on a wall...

The Agile manifesto states “Working software over comprehensive documentation” – this seems to be one of the biggest mindset shifts that organisations need to make when adopting any Agile framework. For some people that simple statement brings up visions of chaos, lack of control, and the worst fear...

Conducting an interesting and engaging end-of-sprint review is an often overlooked art: Not only do we want to show what we have built during the last sprint and collect feedback and good ideas for what to build next; we also want to give our audience a good experience. At my workplace we always in...

One of the things that immediately caught on when we started our journey towards being Agile at Snapper was the use of visual workspaces. The team loved the sense of achievement of moving a task from "In Progress" to "Done" and found the board helped them stay focused and co-ordinated. Everyone from...

After my last post on the role of the Scrum Master I have been asked if I could write a similar role description for the Scrum Product Owner. Here’s my view of the role: The Product Owner The product owner is a visionary who can envision the final product and communicate the vision. The product o...

The idea For quite a while I have been waiting for an opportunity to try a 5-why root cause analysis in a sprint retrospective. The 5-why analysis has its origins within Toyota and lean manufacturing and is used to find the root cause of a problem through identifying a symptom and then repeating th...

Last week I presented at WebDU in Sydney. The conference was excellently organised by Geoff and the Daemon guys and I met lots of interesting people. And I love Sydney! In short I had a blast. Apart from a workshop on user stories I presented on 10 ways to fail with Agile. Judging by the Twitter str...

The other night I attended Rashina Hoda’s totally awesome presentation “Agile Undercover: When Customers don’t collaborate” at the Wellington Agile Professionals Network. Rashina presented the research she had conducted on the basis of interviewing 30 people across 16 organisations in New Zealand an...

Recently some of the teams I’m coaching found it difficult to distinguish between acceptance criteria for user stories and the definition of done. Here’s my attempt to make the distinction clear: For a user story or feature to be "potentially shippable" it needs to meet the expectations of the Prod...

To get our code to production what is left to do is to turn the "potentially" releasable product into a releasable product. To do this a number of activities are required: Which ones and how much effort they require varies greatly between types of organisation. The fastest way to perform rollout ac...

One of the teams I have recently coached quickly got a grasp of how to phrase user stories but found it hard to relate to the concept of acceptance criteria. I wrote this short FAQ as an attempt to make it easier for my team to work with acceptance criteria and hope that other teams might find this...