Maintenance - Repay the debt

It's time to repay some of that technical debt you have accumulated. The project has been running for a few years and often the code gets smelly. The code smells of complexity and bugs.

What do you do to approach such a problem? You clean it up of course!

Now I will tell you how you can choose what areas in the code you want to clean. For this you need a couple of tools. First one to calculate complexity and then you need something that tells you about changes in your codebase.

I have used Complexian and StatSVN in this example, but you may find other tools that does the same job just as well.

I started with Complexian and found that a few classes had a complexity above 21, which I consider as high risk. Then I combined those data with what we can get from StatSVN and came up with more that suggested that we should focus on the classes that has high complexity and many revisions. This because I reckon that a class with high complexity that is changed a lot must mean trouble. There is a lot of different approaches you can use, but this one proved to be sufficiant in my case.

From Complexian
Register.java: Complexity is 38

From StatSVN
Register.java : Lines of code: 2273
Register.java : Revisions: 32 (4th place)


Here you can of course add all the static code analysis you want, but for me this is sufficient to tell that there is something wrong with this class. In this way it is also easy to persuade the project manager that this is a risk that needs to be taken care of.

Then I dive in to the class to find if's and else's that needs a refactoring.. At the same time I notice that the class is in the wrong package as well. My goal is to reduce the risk in this class. Never refactor without a goal. Refactoring makes no sense if you do not do it to achieve something better. If the class never gets changed and you have no bugs that you know of in there, leave it alone. It would probably not show up as a candidate either since there would not be many revisions of that file.

Write some tests for those methods that have high complexity is hard, but rewarding. In this way you deal with risk in a professional manner instead of just "feeling" where to do you cleaning.

Hope this gives someone inspiration and a way to start repaying that technical debt they have accumulated during the years.

The Importance of Removing Impediments

What is an impediment?

I do not actually know, because it is such a difficult word. But what I do know is that the time I have to wait for a build to finish is not productive for me. It even costs the customer money. This is for me an impediment.

If the time it takes to build the application is too long it starts imposing challenges on me. When it takes too long I do not want to build too often.. If i do not build too often, the tests is not run often and I will not commit code very often. This leads to finding bugs much later than I normally would have if I had ran the build more often. So I use more time fixing the bug because I have produced much more code since i made the bug somewhere in the huge codebase.

Did you get it? If not let's run som numbers on it instead. Lets say that it takes 8 minutes to build and that you use most of the resources on your computer while doing it. The best you do is drink a cup of coffee or read up on some documentation while you wait. Let's say you do the cup of coffee and wait for 8 minutes to see if the tests fail or pass. Its not only you in the project, but ten people that does the same thing. We all do it 2 times a day, because it takes so much time and we dont like coffee that much. We do it every day of course. So the numbers become:

8 minutes x 2 times x 10 people x 5 days = 800 minutes = 13.3 hours

Not only does it take you 16 minutes a day to build, but it takes the whole project 13.3 hours to build a week. Let us then say that you work 40 weeks a year and your project runs for 2 years.

13.3 hours x 80 weeks = 1064 hours

So during the lifespan of your project it has been used 1064 hours for running the build. What if those hours could have been used to implement more functionality because you have so much good code that your build did not take any noticable time at all. Imagine that the cost where 1000 NOK per hour that would amount to 1064000 NOK used on build/coffee during the project.

1064 hours x 1000 NOK = 1064000 NOK

That is not just an impediment to me, but to the customer. Build time matters! So remove those impediments while you still have time left to do so. If you are not busy building the application of course...

Priority and Age of Conan

What is priority?

It is often easier to ask people about what they want first instead of asking them about priority. This often shows when you ask the product owner about what is important and they say that all is important. Then you might try to ask for what is the most important functionality. Then they normally have problems choosing which task it is, because they are all important. They all have high priority.

Here is a trick; Ask the product owner what they want first. What do they want in the next delivery? They usually pick the most important for them. If you have multiple product owners, then let them pick their different functionality and add it all together in to the sprintlog.

Now over to something I just recently noticed about priority and product owners over at the discussionboards for Funcom's new MMORPG: Age Of Conan (AoC). The game has been in the stores for about a month and hundreds of thousands have bought it already. If you read the posts on the forum you will quickly see that many of their customers are not satisfied about the product. Even though one should be careful to believe everything on discussion boards there is one thing that really is obvious. Many of the posts talk about priorities of bug fixes and new functionality. I wonder if Funcom listen to their product owners, who in my opinion is the customers that play the game. The last patches has been critisized for not delivering the bug fixes that are important to the product owners. There have been posts about new functionality that have no value for the product owners.

To have hundreds of thousand product owners is no easy task I can imagine, but I ask myself what would I do? It seems to me that they really need to involve the product owners and actually deliver value. I propose to make it possible to vote for issues on the discussion boards and make it visible that these are the most important issues. Then when the new patch arrive they actually deliver what the product owners thought most important.

Make a list (backlog).
Vote on items from the list (1 week or until next patch).
Put the items on the list in prioritized order.
Start at the top and work you way down.
Rince and repeat.

Any comments?

Visibility

I have just ordered a 32" flatscreen for our project! I plan to use it to increase the visibility of the continous integration status. By this I mean the build status, the Cobertura test coverage data and the JUnit report.

This means that when we have the daily meeting, the screen will be very visible and as scrum master I want to increase focus on our test coverage. More coverage will enable us to make changes without the fear of breaking the application.

The last week I have used several hours to remove broken and useless tests from the codebase. This has been tedious work and the result is a lower test coverage than earlier, but now we have only tests that are running and not giving us an error (not the same as failure). We have made tests during our workshops and these tests now shows brightly on the JUnit report (-sky) as passed tests. Hopefully this will be motivation to actually go in to old code and bring it up to better standards with tests. We do all these changes one small step at the time and it actually seem to be working!


I will be back with some pictures when the screen has arrived.

Certified Scrum Master

Yep. It's true! I'm now a certified scrum master.

This week I attended "Agile Project Coaching and Project Management with Scrum Certification" which was teached by Martine Devos.
The course was more a workshop than a lecture and I really enjoyed it even though I knew most of the theory from before. The way she spoke about her practical experience in regards to getting things done, the pragmatic approach to teach us about the different techniques of agile was great. It was highly influenced by questions and people got really good answers supplied with examples and stories from the real world.

She talked about the importance of showing progress and visibility in the team, part of the solution there is big charts!

Another important issue she brought up was agile planning. Yes, there is actually more to this than just an iteration (sprint). We did an exercise and put together three sprints and made a release plan for this. The first sprint was more detailed than the second and it was more detailed than the third sprint.
The idea is not to waste your time in details of later sprints as the customer or even the world may change its course before you actually are to implement it. Maybe you even learned of a better way to do it. But you need to know something of whats coming up the road. Things like, is it big, medium or small? Is it complex? Does it involve others or only your team?
Take things into account, but don't use all your precious time on the details. Use common sense.

With all this in my backpack I'm looking forward to Wednesday where Mike Cohn is talking about agile estimation and planning. See you at xp.meetup!

Getting things done..

You have heard it before and I am saying it again. When you got a lot of things to do it's easy to loose focus. As a project manager its imperative that you have focus on the prioritised tasks.

I'm what you can call a "yes" person. When people ask me for help or wants me to do something for them I tend to say yes. This keeps me interested in work and it often puts me in positions where I can learn new things, meaning that being a yes person is great. But sometimes the amount of things I have said yes to gets too big. Thats when I start to loose focus on what I need to do, especially what to do first. When this happens we ask ourselves questions like, what is the most important task or which task has the nearest deadline. These questions are important, but what you need to do first is to actually know what tasks you have said yes to.


Make a list!

It's often as simple as that. Just make the list and things becomes much more clear. Then add deadlines on the tasks and prioritise it.

As a professor at the university I knew said, when you know what to do there is only two more things: First thing is to start and the next is to continue!

Not that different from scrum now is it?

Some inspiring webpages on GTD and the like:
Coaches corner
All things Workplace

Estimation

Have you ever lost track of time after saying to someone (your better half maybe?), it will only take a short while. Then suddenly dinner is cold and a couple of hours have passed, at least. Is this because you did not know how long time it would take to do the things you had planned. Maybe your definition of a short while is different than your better half's definition? Maybe the planned things where not the actual things you had to do anyway.. We estimate in our living life everyday, how long will it take me to get there, how long will I use to make dinner or how long will I use to answer these emails and send them.

It's a well known fact that we tend to be overly optimistic when we do estimation, especially if we are planning to perform the task ourselves.

In our team, we just started with planning poker. Before we did some estimation with post-it notes using numbers on them , but not all in the team where involved in the process. Before this we normally have the ones that where to implement the changes, estimate the time it took, without much discussion other than project manager adding to the estimate with test and administration time (yes most people forget about time to test).

Questions that often comes up is, who are doing the work? Normally I say that we estimate how long time the team will use on it, how long will it take us to implement this feature? Often someone know something the others do not and this makes this person able to perform the task faster. This does of course create an even wider gap between the people in the team. By estimating together with the planning poker cards we open up for others to more easily try themselves on tasks they normally would not be able to get because someone in the team where better at that type of technology than they are. By this I mean that the estimate opens up for other people to have a chance on making it within the estimate. This makes the team much better suited for the day that one team member leave the team or call in sick. We are then actually still able to perform the task with less problem than if noone had ever touched a similar task or that specific technology.

Questions I want people to think about is:
How long time does it actually take? What is the estimate used for? Do we need the estimate?

These questions put a big questionmark behind the word estimation. Normally in our case the estimate is used for giving the customer a rough idea of the cost. Can this really be turned around as many people talk about in the "agile community", are we able to get the customer to come to us and tell us how much they want to use on the new functionality. Do we have enough trust to deliver what we can in the time we have available. With the Scrum approach we surely would be able to do the important tasks first, but is it enough?

Another question that shows up is how long does the estimation take? Maybe much of the estimation we do should be considered as a waste of time. David J Anderson has some nice words regarding that perspective here.

Test-Driven Development Momentum

Tomorrow I have, what we in Computas call, a competence-block with the new employees. These blocks contain information that we think that most employees in the company should know something about. Mine is about Test-Driven Development (TDD).

It all started last week when I was reading up on various blogs. Then I read "Learning The Holy Ways of Consulting" from Thomas F Nicholaisen and it spurred the idea of doing a TDD course for my two new project members. I started designing a course much like the one Thomas had and when I started talking about it at work people wanted to have such a course themselves as well.

Even though I have tried to implement this in my project before and not having much success (see: this post), I wanted to try again with the momentum of two new people. What I have now is an even better possibility, to show all new employees TDD and it's benefits. I mean it is extremely important that a company which not only produces code, but also maintains code has to use all quality-increasing tools available. Since we often maintain code for several years after the initial release anything else would be shooting yourself in the foot! For a good post as well as an example of old code renewal through TDD see Anders Norås' blog and his Ending a Legacy post.

Ok, let me get back on the actual subject of this post. The course will be held in two sessions. These two days being Monday and Tuesday from 9 to 11:30. During Monday I will go through some of the theory of Scrum, TDD and show them how to make a sprint log of the items I've made in Jira (thanks for the tip Thomas!). From there on, it's all practical. The task at hand will be the famous bowling assignment from uncle Bob as I'm using much of his ideas on TDD in the theory part of the course.

Lets hope that I will win them over to TDD and by doing this start something wonderful in our company. Maybe this is enough to create a critical mass of people to win over the rest? We will also of course make this competence-block available to all employees when I'm done with this prototype.

I'll tell you more later!

Agile and Post-Agile?

What is really agile? I've touched upon this topic earlier, but I have come across a few blogs on the topic again that are interesting. Especially David Anderson, Agile Management Blog where he asks the question "Are you part of the Post-Agile movement?". He also asks the question of what agile is and points further to Jason Yip and his Agility is not the point post. In this post Yip compare the so called Agile elements to those of Lean and he does a good job of it.

As Anderson says, we need to keep pushing.

To me it does not really matter if it is agile or not, as long as we can improve the way we perform our craft and deliver better solutions. Agile for me right now is to implement Scrum and see if this improves our abilities. When this process has settled I will keep pushing. Will you?

Are the customer involved enough?

A while and several blog drafts since my last post now, but here it is.

The question is really, are the customer enabled to be involved enough? While we are quick to think if the customer are participating in creating the backlog or the sprintlog. By this having ownership in the decisions made. Not long ago on InfoQ Little and Spayd gave their views on agile and organisational change and they mention the importance of the customer being part of the agile process if the deliveries are to be successful. This is very true, but are they ready in their organisation to handle the deliveries?

As the Agile Manifesto principle states: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This assume that the customer are able to handle these deliveries at the pace they are coming. Further the manifesto claim that Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. If we are to adhere to these principles we have to enable the customer to also become agile in their process of receiving the delivieries.

To take a practicle example of this I can relate to my current project which is in the process of implementing a more agile approach. Agreements have been met and deliveries have been delivered, but the receiving end are not able to handle the deliveries at such a pace. They lack both the manpower and the routines to test the deliveries thus bringing us back to how it was before. The team cannot keep on delivering while the tests are not being managed and we have to set a new pace. A good article on Agile Journal describe this scenario as candy coming faster on the conveyor belt, it creates trouble handling them.

This shows that agile processes sets new demands to the organisations not only where the deliveries are being produced, but also in the receiving organisation. Now you have not one, but two organisations that has to adopt agile. The question is are the customer involved enough to make that change?

Scrum - something for maintenance projects?

Phew.. Been a couple of busy weeks. I have just become the project leader in a 5 person project. I've been in this project with various roles since I started in May last year. This is a great opportunity for me to be part of something and to change it to something better if possible. Not that you always need change, but I tend to think that change is good in so many ways that some changes should be made in order for people to stay with a project over a long period of time. I really wonder why so many people do not want such a job. The possibility to be a change-maker!

The challenge in our project is that it is an "old" project by IT standards and it is in maintenance phase. The project consists of 5 people in a good blend of experienced and not so experienced. Me being part of the latter when it comes to my new role. What I find interesting is the energy I feel about this! I've always felt that I put out the questions to my surroundings. It now seems that I will be put to the test myself and have to do action based on others questions and requirements.

Hopefully I will be able to change some elements in the project so that we can work in new ways and see change bring new energy in to the project. I have a dream about an energic group of people working together to make the best they have ever made. When we deliver we should be proud of what we have done and feel that it was worth it. This is a bit childish and naive, but I think it is possible if one can create the right circumstances. It can happen! I really look forward to work with the people, the environment and the product from within this role.

With this perspective I have looked to Scrum. I see elements in Scrum that can be usefully applied in our project. These elements being the product backlog, sprint backlog, daily scrum and burndown charts. Especially the sprint backlog as this will allow developers to focus on these issues and then the burndown chart to see the progress and make it possible to feel that we are moving toward a goal.

Our project is in maintenance phase which I find exiting for this kind of "method". This means we have bugs being reported as well as new functionality into Jira. This will be our starting point when we begin to work on our product backlog.

So there you have some of my thought on change in our project. Maybe someone have seen Scrum used in maintenance projects earlier and would like to give a comment?