The Scores on the Board

As developers working within an agile team we spend a significant amount of time looking at some kind of sprint board.

We see what's left to do, whats being worked on and what we've completed. All of this helps us tell whether or not were going to achieve our goals.

But is their actually more to see on the board than that? Is it actually possible that the board can tell us something about our code?

Stories Reflect The Code

I'm sure all of us have been in the position where were struggling to see a way through the sprint.

"This story depends on that one, and we can't start that until this one is done" 

Quite often were quick to just write this off as bad luck or bad planning but when this happens over and over again is their something more?

Tightly coupled code will produce tightly coupled stories. If you struggle to break down your code base into elements that can be worked on individually and simultaneously all of your sprints will contain a lot of blocked stories, progress will be slow and much of your resource will be twiddling its thumbs.

This will never be more true then when your sprint involves making changes to an existing part of your system, the extra time taken early on in development to define some robust and flexible interfaces will be paid back here when you can fully utilise everyone in the team can get stuck into making the necessary changes.

This isn't just about the developers either, sprints with a lot of blocking stories will also be hard on testers as it inevitably results in a big bang of delivery to test towards the end of the sprint rather than a gradual stream.

How Many Points?

Even before the sprint starts the quality of our code can influence how smooth the agile process will be.

A major part of pre-sprint activity is pointing the stories which can on occasion be greeted by a large exhaling and puffing of checks from everyone involved.

An inability to point a story can be caused by the story not being well defined or ambiguous but it can equally be caused by the code.

It isn't easy to point stories when the code is large and complex and where the interaction between classes or sub-systems is strongly coupled in a manner that is not easy to penetrate.

In this situation their is also a tendency to be pessimistic adding on a certain margin because were confident things are going to go wrong when we start trying to work with that part of the code base.

This ball of string pointing where we become scared that if we change this everything else is going to come crashing down around us is another sign that the agile process is giving us just as much information about our code then it is about our product and team.

We Still Have Defects

Defects are a fact of life in software development, the business of writing code is too complex for mistakes never to be made and for consequences to always be anticipated.

But this doesn't mean that we should just shrug our shoulders whenever a defect is found. This isn't to say that we should be looking for someone to blame but more that we should be identifying why this particular change to this part of the code is causing so many problems.

This is not only to help understand how we can improve the code base but also to stop fear spreading. A strong desire to not change one particular aspect of the code can lead to bad decisions being made, decisions that from a structural or architectural view don't make sense but simply mean if we do it like this we don't have to touch that.

As with most things in life it best to take your medicine early, if you start seeing signs that something is wrong, no matter where those signs may be coming from take the information on board and plan a remedy.

Agile is indeed the gift that keeps on giving, it not only allows us to effectively streamline and manage our delivery but also gives a lot of feedback on the quality of our code all we have to do is listen.