This is first of a series of blogs to explore the importance of metrics in an Agile project. The approach to a specific Agile project is often described as emergent. In the sense that we don’t start off with a prescribed approach in mind but we adopt as our understanding of projects grows and it’s profile and key challenges emerges. Agile metrics can be used as an aid to understanding a project’s profile (informational metrics) and it’s challenges (diagnostics metrics). The following is a list o…

SCRUM and Kanban (as applied to software development) are different. Proponents of the two drift from staunch opposition to declaring Kanban as a special case of Scrum.
I have been practising and coaching Scrum for a number of years and I delight in the effect it has on project teams. While I practice Scrum I find [...]

For the majority of agile teams user stories are the preferred tool for requirements management. User stories provide numerous benefits including; a focus on the business problem being solved, a just in time approach to specification, amenability to splitting that supports working in short time-boxes.
The problem with user stories in practice is that the desire [...]

My current client is a major telco. They have been developing high qaulity software for decades (literally). They have heavily entrenched waterfall process. They are used to doing everything to the letter of their methodology. When I first came on site two years ago I used to dispair of them ever doing anything agile.

Today, they seem to be doing agile pretty well. Its not been a universially posiitve experience and there are plenty of non-agile values and practices still floating around. On the whole though I have been impressed that rather than seeing Agile as an excuse not to write documents, they have embraced the disipline required by a leaner software process.

I have worked with clients who were much more reactive and used to being at the cuting edge. They embraced agile becuase it appeared to legitmise the lack of structure in their approach. They produced poor software when they produced up front designs and they continued to produce poor software when the developers were ‘let off their leashes’.

Upon reflection I think my current client, with its long history of rigour and application of best practice has made far better use of the agile techniques. Maybe its becuase they continue to apply disiplince. Possibly its becuase they are very aware of the dangers of a less formal approach and are always trying to mitigate any risk that not having the waterfall in place might bring.

Perfection in software is impossible. Software developement is subject to the Law of Diminishing Returns . So how do you decide when enough is enhough?

In a recent presentation Al Goerner discussed catagorising stories. Two of the more interesting catagories were “New feature” and “Feature enhancement”. In an Agile project where new stories are constantly being added to the backlog, these two catagories can help use decide when a pr…