Agile Quality

Being an agile team is not achieved by flipping a switch, becoming agile is a journey where the validity of qualifying yourselves as being agile is a sliding scale.

Along with an adherence to the structure and ceremonies of your chosen agile approach there is also a required mindset that needs to be adopted in order for the benefits of agile to be realised.

So if being agile is not a binary metric how do we know in our day to day working lives if were moving in the right direction towards our agile nirvana.

Story Writing

An agile story is the communication device by which stakeholders can communicate to the team the outcomes that need to be achieved to implement some desired functionality.

As with any form of communication its possible to do this badly, to generate misunderstanding and confusion that ultimately lead to a failure to deliver or a delivery that provides the wrong outcomes.

Story writing should not be an arduous process, it should promote discussion but it shouldn't cause confusion.

A key to this is realising that story writing needs to start only when a broad understanding of outcomes is already in our grasp.

The process of story writing should be for the team to create an understanding of what needs to be done and the approach that will be taken, it shouldn't be a painful process of trying to tease out of stakeholders what the point of doing this work is.

You can learn a lot about agile quality by watching a team in a story writing session, are you watching a well oiled team who understand the product they work on and where its going? Or are you watching a group of individuals churning out software without an understanding of why?

Backlog

Once a certain number of stories have been written then you have created a backlog.

Again a backlog can be seen as a form of communication, it describes the journey a product is going on and identifies the signposts and milestones that need to be hit along the way.

A good agile backlog is fluid, the next priority can be changed, stories can be added, removed and re-ordered.

What shouldn't be fluid is the over arching themes of what is trying to be achieved, the product that is being built and the path of its evolution.

A low quality backlog will not demonstrate this cohesion, it will present itself as just a collection of work items thrown together in order to give a team something to do. It will not have obvious goals or points of delivery.

The quality of a backlog can often been seen by asking a member of the team to talk you through the stories, what they achieve, why they are in the order they are and where a deliverable exists.

Delivery

The point of all this is to deliver software and almost regardless of what development philosophy you apply the effectiveness of a team should be measured in their ability to deliver working software.

However we need to understand what is realistic to expect.

No matter the quality of a team the ability to deliver any amount of scope in any amount of time is a fallacy.

What should be valued is the predictable nature of a teams delivery, this predictability will come from an accurate and stable velocity.

When this is combined with a quality backlog made up of quality stories this enables accurate estimation.

A stable velocity can only be achieved when a team, whose members don't change, is working its way through a well crafted backlog towards a well understood goal.

Velocity should be the third measure of the agile quality of a team, as the team improves its practices it should demonstrate an upward trend but not have large variation between every sprint, within the short term past performance should predict future delivery.

Ultimately all these aspects of agile combine and interact, the important aspect is to embrace the agile mindset and realise it is not a project management process.

It is a living organic approach that embraces change and wants to deliver what is required on regular and improving cadence. But as with any system, garbage in will lead to garbage out.