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.

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

The value of search engines

Before we were able to find solutions to our technical problems by asking people at work or to read a manual. In the last 15 years the search engines have taken over this responsibility. I'm a huge fan of engines like google.com to help me when I'm stuck on a technical problem.

Often that is my first respons when people ask me about a technical problem.
"Have you tried to google it?".

This brings me to another side of the search engines. It can really be hard to find the answer you are looking for if you do not know how to make your search good enough.

Take this problem I just had on my lovely Dell XPS m1330. Dell have been really stupid and added their own software thats connected with one of the buttons on the keyboard. So for me that have Ubunbtu Linux installed instead of the prepackaged windows, it creates a huge problem. When I press the button, the laptop cannot start the operating system again.

There is virtually no documentation of how the Dell Media Direct program works or even how it is installed. Because when pressing a "special" button on the keyboard the laptop tries to start Dell Media Direct. This crashes my normal ubuntu install and destroys what is called a MBR. This MBR is what enables me to actually start any operating system on a pc.

After reading alot of forumposts and various blogs I finally find one that helps me out.

If I accidentally hit the MD key, my partitions gets fudged and I have to repair them manually.
Response:
Have you tried pressing the button a second time? I notice if I press it it ruins my partitions as well, but if I press it again everything is perfect again... Not sure what it actually does...

This solves my problem and voilá I can boot into ubuntu linux again.

To find this forumpost, I had to tweak my search and narrow down the findings to an amount that I could actually be able to read. It took me about one hour to find this little piece of information.

But at the same time as doing this I read a lot of other interesting things too. Maybe the search engines not only helps us with the problem at hand, but helps us to know more in general? It reminds be of the work we are doing in the company on semantic web and the use of this technology to find information.
I wish there was an easier way to tell the search engine what I am looking for.

Work Engagement

In my last post I talked about fear as an obstacle to be productive in development of a software project. Knowledge can conquer this fear, but there is also something else that can make people forget their fear. Engagement!

If you are really interested and motivated in your work you might just not be afraid of the huge codebase and the possibilities of errors and bugs when you do a change to it. In my opinion a motivated person often learn faster and are quicker to pick up on positive changes in their environment.

I often feel an "energy" when doing something interesting and it keeps me motivated. I read different blogs and I buy both management and system engineering books. This keeps me interested because I am constantly learning something new. But it is not what makes me actually tick, what does it is the actual tryout of an idea. Even if you only read it in a book or a blog. Does it work? If it does work it spurs me further in to the idea and I get motivated to continue to try new ideas.

How does one motivate others in the same way? To some extent I think it happens automatically when they are close to, or are working together with a person that has this energy. But is it enough?

My advice is to bring your colleagues or friends to the spot where you get your motivation from! Be an enabler and the motivator. Do not be afraid to bring new things to the table. Enable for others to bring new ideas into the work environment.

A day that nothing new is tried out can be a wasted day.. Can work be performed better for you and your company in any way?


Some of my favourite places to get ideas and inspiration:
The Practice of Leadership
Management Skill Blog
Management Craft
Agile Leadership
XP Meetup
*Technical*
Uncle Bob
(++)

Workshop: Legacy Code

It's true. We got it! We got legacy code..

To best describe legacy code I turn to one of the guru's on the subject, Michael Feathers:

[After all, there is an emotionally neutral definition of "legacy code." Legacy code is code from the past, maintained because it works. But, for people who deal with it day in and day out "legacy code" is a pandora's box: sleepless nights and anxious days poring through bad structure, code that works in some incomprehensible way, days adding features with no way of estimating how long it will take. The age of the code has nothing to do with it. People are writing legacy code right now, maybe on your project.

The main thing that distinguishes legacy code from non-legacy code is tests, or rather a lack of tests.] ( full article and book )

We now have more than 180 000 lines of java code in my project. To me that is a lot of code. How can you have knowledge of the code to safely say that your change will not break any existing functionality? You can't!

There are many reasons to why you can't know for sure. Let me give you an example. One of the classes is almost 10 000 lines long and has methods that contains more than 500 lines of code. If we get a bug report and go in to that class to change something you can be sure that there is something in there waiting for you to mess it up. The class is impossible to change and it will take forever to fix this bug. And by fixing the bug you may actually introduce another , because someone was expecting that specific value in another part of the application.

The reason for expecting the bugged value can be many, but you can't know for sure if it will break something. Without a test, we can never know if that other functionality break when we change something.

Even with tests you can't be sure not to break anything. But at least your tests will lower the risk of not finding the bug you created with your change.


The tests help us have actual knowledge of the application. Not only can we read the tests, but we can actually get feedback from them when we do something to the code. This helps us to know more of the dependencies and the relations in the code. It helps us to understand the code better. But when you have 180 000 lines of code, do you really want to add another 100 000 in tests? No. But I do want to have tests around the changes i make and take small steps to create a safer place to work. Because it is fear that keeps us from attacking this monster class with our refactoring and our changes. Get rid of your fear by learning more about the code with tests.

In this spirit we have scheduled a small workshop for tomorrow to handle that fear. We will delete unused code and we will write tests for the code we are moving out of one of our biggest classes. We will discuss and learn about our code. With this knowledge of how to handle legacy code I hope that we will conquer our fear of changing code in horrible places.

This is knowledge in action!