New site is up!

http://agileinoslo.com is the new site for my blog! Remember to change your bookmark and RSS reader!

All posts and comments are already moved to the new site.

Being a coach is more than listening and giving advice

Socrates is one of my heroes from the history of philosophy. The idea of asking questions instead of giving the answers or well meant advice, has always been an inspiration to me. It might be my curious nature and that I want to know more about people and their thoughts on the world. But I have found that asking questions works really well.

"To solve a problem, it would be broken down into a series of questions, the answers to which gradually distill the answer you seek." [Wikipedia: Socratic Method]

The importance of questions is often mentioned in popular coaching methods and it often has the purpose of understanding a challenge or problem that someone has. It often opens up the conversation and you become an active part in the conversation instead of only being passively listening. Although this is a good conversation it is often important to ask the questions in a way that it is not possible to answer them with a simple yes or no. In this way you do not close the conversation and the person you are asking will often need to think more and differently before answering. This pulls the person out of the blind alley they were in.

If I am the one being asked the questions I feel inspired by it. There is a person that is actually listening to what I say. That person challenge me to go even deeper in my thoughts on the subject by asking all these questions that I am not able to answer with a simple yes or no. I'm forced to think and someone told me once that thinking is important.

Next time you feel compelled to give advice, maybe you should ask a question instead.

Visibility is important for motivation

People always say that visibility is important, but often they fall short when asked to give examples.

I thought I'd give you an example that is fairly obvious and can easily be tested. That's if you have a newer kin of Nokia mobile phone..

http://sportstracker.nokia.com

The sportstracker gives you a few data about your training trips, but it also give you motivation trough it's functionality.

You can have your own training buddies connected and then you can actually see what your friends have done. The application is actually quite simple using your GPS on the mobile phone and registering speed and altitude in your workout (cycling/running/walking++).

More important is the web site that creates the link between your buddies and you. This creates a sense of competition between you and your friends. I find it inspiring to see that a friend of mine has done a 10km track in an hour last night. I suddenly find myself wanting to do some running.

Maybe this can inspire you to do some of the things you do at work visible to others as well. Maybe it creates a small sense of competition and fun. Maybe it motivates you and your co-workers?

It surely motivates me! Too bad you can't use the mobile phone when swimming..

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...

Smidig 2009: Påmeldingen er åpnet

Påmeldingen er åpnet for Smidig konferansen! Jeg tror årets konferanse kommer til å være like fantastisk lærerik som i fjor!

Smidig på twitter
http://smidig2009.no

Do the rights things at the right time

Yesterday I attended the oslo xp-meetup with an expectation of hearing some inspiring thoughts on software developing using xp and agile techniques. What I did get was a very good presentation of lean startups and how to do the things that matter the most at the right time (like in xp and lean).

It was Kent Beck who presented his new ideas on what he defined as "the flight of a startup". The analogy used the different phases an aeroplane is in before it's cruising at 30.000 feet.
1. taxi
2. takeoff
3. climb
4. cruise

Kent emphasized the need to be careful about spending cash (if it was limited) in the taxi and takeoff phase. The most important issue that I noticed from my perspective was during takeoff where you actually remove functionality thats not being used because you want to get better scalability. I'd call it reduce the risk of cluttering up your good ideas with the bad ones. But as Kent said, removing features are not easy and often we tend to let them stay in there. Another interesting statement from the re-inventor of TDD was that you should ALWAYS track usage in you applications.

I will start to do just that. I will start putting in functionality for tracking usage in my applications. This to be able to get actual feedback on what is being used in the application and what is just waste. Then we have an actual map of the used functionality and with this we can start doing some real work. Removing functionality thats not being used will be removing code that slow us down.

If he is doing this talk somewhere near you, take the trip and listen in on the ideas. It's good stuff.
Another very nice post on startups here

I have a brain!

A friend of mine is writing his masterthesis on frequences in an MR machine. This machine scans your brain. Yesterday he asked me to help him out with his last scan for his thesis.

Do you have a brain? Use it! :)

Communication and Context

What about it? We all know that communication is important and most of us also know that the context of where or what the communication is about is just as important.

Consider some of the pictures i took while in China. They show a will to communicate with you as an english speaker, but they do not always make sense. Anyway here are a few of them:


The next one is harder to understand the meaning of.. Mingtien means tomorrow, so maybe they mean tomorrows language café? or language coffee?




Think about the context when you communicate with someone. They might not understand what you are trying to communicate even though they understand the language.

Motivation and Attitude

Most of our life we stick to some basic values. Sometimes we do things we would usually not do because someone or something motivated us to do so. Its the attitude to be open to change that is one of our most important traits.

It is time to start motivating for change. Its your life and it should be you who decide what you want to do with it.

Have a look at this movie from the HOME project. It speaks of motivation for change on a global scale.

http://www.youtube.com/homeproject

Mockups, what is it good for?

Some people like to think in terms of text and others prefer diagrams or drawings. I am a huge fan of drawings. But I prefer drawings that do not draw too much attention to details that are not important in the context. When looking through some old favourite blogs I found this post about the level of detail in a demo. Its a great summary of what not to do when you want to show ideas and get creative feedback.

And guess what? I've been in a discussion with someone about this before. In the discussion someone mentioned a tool that gave you the possibility to make mockups fairly quick with a look of a sketch. I've now tested and even bought the tool for my self to use at work when making backlog elements for further specification. Since my drawing skills are rather lacking the tool helps me to make some really nice sketches. The tool (Balsamiq) is really easy to learn and I use less than 5 minutes on the sketch below.

The level of detail enables us to communicate on the content instead of the details of the dialog window like colors and text size.

And as Kathy mentioned at CPU; it does not give the customer the idea that we are almost done with implementing it, because it looks almost finished on the openoffice slide!

This is because the details that really doesn't matter right now is not there. I would go as far as to say that this is good enough for specification purposes in most cases. It will get changed later in the development iteration anyway, when the customer sees the real screen during development he will then ask for new or altered functionality. The important part here is that this sketch often contains enough information to start developing the desired functionality. This removes the waste of making too much spesification. And did I say that this sketch is so much easier to change than a photoshop picture?

Balance

You need to have balance.

If you want to do things right you need to be in balance. Being in balance in taiji (tai chi) means that you have practiced doing the movement many times and you are able to have control through the whole exercise, thus never loosing balance. It does also imply that you have the mind in balance.

But what does it mean to be in balance in a project? I would say it is the same thing. The project should have practiced doing things slow enough to gain full control and enable the people to be in balance. If you run fast and you do not normally run that much, what do you think will happen? You either run too fast and not be able to finish the round because you are exhausted or you are maybe running so fast that you loose your footing and fall? These are the visible problems we easily notice if you are not fit enough to run that fast, but there are others that are more subtle indications like your running style. Maybe you are running in a hurtful way and if you continue to run in this way you will harm your body, but not see it before you have been running for a long time.

To run fast you have to run well. To run well you have to practice. To practice well you have to practice slow. Did the sprint go bad? Maybe you ran too fast? Slow down and be in balance whereever you are. When in balance you are always able to change your direction.

When a project is in balance it adapts to whatever comes down the road. It runs well and it runs fast.

Vacation

I am sorry for the lack of posts these last months, but time has been too quick to pass on me. The reason for this post is to inform you that I will be going on vacation for the rest of the year. Maybe there will be some posts during my backpacking in China, but I do not know.

I have a lot of ideas for great blogposts in the new year, one is an experience I just had in a project that suddenly had new stakeholders and I got some opinions on coaching in the agile environment (+even on being your own coach). But all this will have to wait till next year if I do not get bored down in the far east.

Merry Xmas and a Happy New Year to you all!

Video from Smidig2008

The videos are here! http://smidig2008.confreaks.com/
It's in Norwegian I'm afraid, but its all about agile. I promise!

Smidig 2008, 9-10 October

Smidig 2008 is soon here! http://smidig2008.no

Last years conference was a great success and I had good experience with the openspace discussions that I attended. This year it is even better! Since I had such a great time last year I thought that this year I could help out with the organizing. And I am!

This year we will have a even better location with more space for discussions and mingling. For you guys out there that does not understand Norwegian, do not despair. I will give you some of the lightning talks wrapped in my perspective after the conference..

More on Age of Conan and priority

It looks like someone at Funcom has found that communicating with the "product owners"/customer is a good thing. Here you can read about a Funcom employee asking for a list of bugs and new ideas.

Lets hope they keep things like that going and make AoC a great game

Maintenance project?

In software engineering, software maintenance is the modification of a software product after delivery to correct faults, to improve performance or other attributes, or to adapt the product to a modified environment.”(ISO/IEC 14764). [Wikipedia]

I have been bugged by the term maintenance project for a long time and it is time to vent the frustration here. The project I am working with has two parts, one for development and another for maintenance. While the project is called a maintenance project we actually do produce a lot more new functionality than correcting fault and adapt the product. Many projects are in the same environment and it is unfortunate that they are called maintenance project when they actually should be rid of the term maintenance. We do maintenance as well, but not to the extent that it should be reflected in the name.

The reason I bring this up is because maintenance is not a popular word and people start to get all kind of ideas when they hear the term. People often say that maintenance projects does not use any new technology, they do not do anything exciting (from a developers perspective). Well this is in our case wrong. We do new functionality every day and we make use of some of the newest technology out there. Our code grows and adapts with new technology.

Let me mention some of this years improvements to the code and environment:
New platform: Moved from IBM Websphere to JBoss.
New JDK: Moved from IBM JDK 1.4.2 to Sun JDK 1.5
EJB2.1 to EJB3
.Net1.1 to .Net2
New EpiServer version
RAD to IntelliJ
..and a lot more!

I think one of the important tasks in a project is using new technology, not for the sake of having new toys, but to be able to move forward. The changes we made in the project have made new functionality possible in new and better ways for our customer.

So my suggestion is to stop using the term maintenance when the project delivers more than 70% new functionality instead of maintenance as defined at the top of this blog. Make room for new technology in you project not only for your own motivation, but also for the sake of your customer.

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 #2

As promised, here is the picture of the new screen! At the moment it shows our builds, news from the wiki. tests and test coverage. We downloaded the add-on for firefox that gives us a slideshow of the different tabs.

People might think that this would be great for your own screen, but the resolution is not nearly as good as a monitor.

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.