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!

Smidig 2007 and vacation

Not long ago there was an agile (no: smidig) conference here in Norway, Oslo. The conference where really a great success. The success happened because of as I see it two things.
1. Active community already, with many people motivated for the topics in agile.
2. Use of Lightning talks and open space consept.

These elements created a very constructive environment and people shared experiences in a much larger scale than ordinary conferences.

Let us hope that more conferences will adopt these techniques to help people share knowledge!

On the issue of vacation: I'm leaving for Dublin and then backpacking in Thailand from the 7th of December and will be away untill January 1st.

Enjoy christmas!

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.