Developing software ain’t easy.
How do you know how you are doing ?
You could start collecting metrics about your code. These can give you some indication how maintainable and reliable it is.
The metric which come to mind to the most people is code coverage. Some people say it must be near 100%, other say 80% is a good number. At the end it can’t tell you if you are doing great or good. The only thing you might read from it is that a low number indicates a potential problem.
Duplication is another one you should look out for. A high number of duplicated code might bring up the problem that a bug was fixed in one place but lives on in other. If you are doing code generation (e.g. from WSDL’s) you might have a lot of duplicated code reported to you. A closer inspection is needed to really make sure this is a problem in the code you have written and is not auto generated.
Test success is not a metric you should be worried to much about. It just needs to be 100% at every checking in a shared repository. No discussion.
Cyclomatic complexity let’s you measure the number of linearly independent paths through your code. A high number means a more complex code. A complex code base is hard to maintain and involves a lot of work to adopt it to new requirements.
Dependencies between packages is another important value to check on (see Uncle Bob’s paper on Acyclic Dependency Principle). Basically it revolves around that packages should not have cyclic dependencies between them since this does have an impact on releasing and testing (and therefore coding). A change in one package could trigger a whole system build to make sure everything works together.
Tools like Findbugs let you define rules to which your code should comply to. This is great because it is tailored to your code/company and ensures you control and fine tune the measures. Or so. It requires some time to define these rules. They need to be refined over time and you have to understand them to make use of it. Of course you can leave out some of these and reduce complexity. Do not underestimate the effort to implement these.
This rounds up the metrics you can get from your code base.
But wait, there is more.
A valuable metric is the meantime between reporting a feature or bug and fixing. This gives your team (and management of course) a rough estimate how fast you can react to market changes.
To get an estimate of the mean time before a failure happens you can measure the time between two bugs. The higher the number the better. Current reported bugs per lines of code can also be measured. These metrics will give you some confidence in your code base.
At the end of the day the ultimate measure is the money on the company’s bank account. If this is not working out you are in trouble.
How to get all of these ?
There are some static code analysis tools to get you started. I only can talk about Java related tools but there are others as well.
To get more information about your bugs should query your bug tracking system like Jira or Bugzilla.
Summary
There are much more numbers out there but I think these are the ones you should always keep an eye on.
Look out for
- Code Coverage
- Duplication
- Cyclomatic complexity
- Cyclic dependencies
- Test success
- Time to market
- Mean time between failure
What metrics do you look out for ? Let me know in in the comments and why.
You are doing scrum, your story is big, you really don’t know much about it and the feature does not get implemented in time.
Sounds familiar ?
I had this a couple of times.
What turned out to be a real problem is that, tech nerds as we are, we spent most of the time coding up a nice solution (and we were almost always convinced that this was the minimum we should have done). What we underestimated was the time we would need to integrate it with the rest of the system. When we broke new ground integrating new technologies it turned out is is very easy to miss that point.
In theory ‘just’ code against a defined interface and you are all set up. In practice you will find the interface not working as intended or web services returning everything wrapped in CDATA. This is the point where you start to panic. This integration was supposed to be easy. Everything else is already working and only a couple of hours where allocated to integrate the new functionality (and sprint review is tomorrow). So it is crunch time, again.
What did we learn ?
If possible (and this is not always the case) start implementing one small feature from top to bottom all the way through your application, e.g. selling green cars through you web site. If this works you can go on and sell blue and red cars. It also helps to organize teams along user stories. This way everybody is responsible for the story.
If you have teams organized along responsibilities like database or GUI, the communication between the team members will suffer (since they usually sit in different rooms). Everybody tries to code up against the defined interface and the integration usually happens pretty late in the sprint. Each team claims that his stuff works against the agreed contract (but still some things do not function as they should). Just hours before the integration should be finished, it turns out the specification was not correct and other things are needed. Back to the drawing board. Overtime. Feature not implemented.
After you got the integration running make sure an automated test is covering it. These need to be expanded over time and you make sure from the beginning that it will always work. It would be very nice to have the integration test running before writing any actual code (read: test driven development) but this never went to well for me since the two sides are very fuzzy in the beginning.
My hope is that next time we come to a situation like this I remember a couple of things I wrote down here 
.
For the last couple of month our scrum master always drew our daily burn down chart. Nice and fine and it always happened automagically. It came to the point that we (the developers) only occasionally paid attention to it (a little less then we should). One day our scrum master stopped doing it and forced us to do by ourselves. While it seemed a bit strange at first it turns out it was a brilliant idea.
We are now reminded every day how much hours we burned (in contrast to we just complete cards but nobody calculates the sum and tells that everybody). If the result is far below the theoretical number of developers x 8 hours a day we quickly analyze the problem and try to solve it. We are more aware that we might be in trouble. This was not so much the case in the last sprints.
Self made burn down chart
It could be that it just works because it is new but I think it is worth a short. I certainly like how everybody stands around the burn down chart and tries to do mental arithmetic.
We do have our Sprint Review tomorrow. We will not meet our commitment. Bummer.
What happened?
After the planning we did the breakdown of almost all stories. We had 5 Stories and another epic. As we did the epic breakdown we knew that we could not nail down every task since it was clear that some refactoring along the user story would be needed. So we marked one card in that story to remind us that we need to break things further down and refine the tasks.
The first couple of stories went very well (although we still suffer from estimating small stories too big and big stories too small). In the third week we got to our reminder card and our domain experts began to really think about the tasks needed and designed a much more useable and better architecture. This took a couple of hours and could not have been done at breakdown time (or could it?). It turned out it was quite some work to be done but we still could meet the deadline.
Some of us started to implement the new design and things seemed well. What we not did is a detailed planning of the tasks. It was more like we do see what is needed and write down task cards as we see the need for it. This was mostly done on ‘unplanned task cards’ (see earlier post on Scrumboard Cheat Sheet).
Due to the complexity that team could not check in their changes for some days (Remember? Never check in code which does not pass all tests). The only problem was that without that part of code most members of the team could not proceed very effectively on the epic. We found ourselves in a classic deadlock. I was part of those who could not work as intensive on the sprint goal as they would have liked to. It was a frustrating experience. In the end I think we could have been somewhat closer to the goal if we would have seen the warning signs like we just do write the task cards at the stand up (and acting on them). This goes down in my book under ‘Lessons learned’.
I’m not sure how we could have made it better. Doing a better task planning at the breakdown? We usually spent about two hours to define the tasks. Going over that time with the whole team seemed always to stress this a bit and it got less effective .
Should we have spent earlier on more time in designing the refactoring? Two people could have started right after that on that topic. But that epic had a lower priority and everything else should have been done before that if we do follow agile ideas.
However since our Product Owners saw that coming (there were usually at our daily standup) there were not shocked about it as they would have never heard of that problem before. But I guess they are not too happy with us.
Three more days and we are done. Promised.
In the last couple of month we continuously improved our scrum task board. After a sprint planning we usually do a story breakdown into tasks. All tasks for one story get ordered and a time for each will be estimated. We do try do make sure every task is smaller than 8 hours so it can be completed in one day.Our ScrumBoard is a magnetic whiteboard with hand drawn lines.
We do use color coded cards for the tasks we do. We do shuffle the colors each sprint but we have different colors for:
- The Story itself
- A Task
- Unplanned Task (like a thing we forgot at breakdown)
- High Priority Bugs which need to be fixed right away
- Non Sprint Tasks
Different colors make it easy to see if we were good at estimating the work which needs to be done. It shows us very easily that we might be in trouble with our commitment because we got of external tasks. The burndown chart shows this as well, but the colors show us why (as well as the bars, more on that later).
The top row is reserved for unplanned tasks, bugs and time boxed events such as workshops with the solution owner or support for the product owner. Four rows are for stories we are working on.
As soon as somebody starts a task he writes his name on the task card and puts it in the ‘work’ column. He usually takes as many cards until the added hours of the tasks equal the time he is available to the sprint today.
Each card has a specific order in which it needs to be executed to complete the story. Some tasks could be executed in parallel and some have to wait. If we find one card blocking and somebody is working on it, the rest of the team sometimes starts with a new story or helps finishing the blocker. Right next to it we draw a small bar for each day we are working on this task. When we see that a task which should take e.g. 4 hours is now in the ‘work’ column for 2 or more days then this needs to be addressed in a way that we brake this card further down or assign more people to it so this can be finished. Bar code cards are not cool.
If a task is done, we put them at the end of the row in the ‘work’ column in 90 degree angle. This card will be moved the next morning during the 15 minute daily scrum to the ‘done’ column. If something comes up during the daily scrum which needs to be discussed by the team we write this down in the Standup Backlog at the board.
To get a better impression have a look at the ScrumBoard Cheat Sheet of my team.
Update:
This is our current sprint overview:
Our current scrum board
What is Extreme visibility?
Extreme visibility is all about providing information about the code to every team in near real time. We show several metrics such as complexity of the code (xs), todo’s, deprecated methods, number of broken builds, open tickets and their priority and so on. These are distributed over a couple of screens which our software is rotating through. Every team member can easily see if his or her commits effecting the code quality in a good or bad way and makes the members aware of certain quality standards we try to keep in our code base. A typical screen looks like this (mockup):
Extreme Visibility
We discovered that showing these kind of statistics to the team has the effect that everybody in the team room cares about the numbers (and therefore the code quality). Without this display you just don’t know how your changes will effect the overall quality of the code. It might seem a bit threatening to individual team members at first (like we do show who checks in without a commit message) it turns out this is not really a problem.
While we did provide very detailed information in the past about the trunk and every branch (every user story is on it’s on branch), we found out that too many screens are counter productive and results in not caring about the values displayed too much anymore. We also do believe that showing time line and progression information on several metrics are very motivating to the team. We are planning of tweaking the information this way in the near future.
The software we use is written by ourselves in Grails. On the front end we simply have Firefox running a full screen mode. Every team has a big screen TV connected to a computer (turns out I could connect my Sega Dreamcast too). We did collect some good feedback and learned a lot about the usage in the last couple of months. The next step now is to enable the teams to write their own modules to provide the information which is the most useful to them.
I’m not aware of any open source (or other) software doing the same kind of thing. Writing it by ourselves we could tailor it to our specific needs like showing svn information, showing Teamcity build statistics or information about the code using Structure 101.
Overall the team I’m working in is very happy with the information we get from our extreme visibility monitor. XV makes sure we all can see how the quality of our code develops and we get warning signs to take counter measures to bring it back on track. And that’s what we want after all 
.
