Thommy's KMblog - Moved to http://agileinoslo.com

New site is up!

2009-09-06T12:38:00.002+01:00

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

2009-09-04T21:02:00.008+01:00

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

2009-08-15T13:21:00.004+01:00

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

2009-08-10T16:46:00.003+01:00

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

2009-07-08T13:02:00.005+01:00

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

2009-06-19T01:00:00.001+01:00

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

2009-06-18T17:25:00.004+01:00

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!

2009-06-11T09:22:00.002+01:00

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

2009-06-08T07:15:00.000+01:00

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

2009-06-07T13:09:00.003+01:00

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?

2009-06-04T19:13:00.007+01:00

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

2009-05-07T21:28:00.003+01:00

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

2008-11-29T11:15:00.002+01:00

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

2008-11-17T14:58:00.002+01:00

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

2008-09-10T18:56:00.004+01:00

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

2008-07-23T22:19:00.002+01:00

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?

2008-07-18T09:08:00.002+01:00

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

2008-06-24T08:58:00.004+01:00

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

2008-05-14T16:20:00.004+01:00

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

2008-05-03T14:10:00.005+01:00

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

2008-03-09T09:37:00.003+01:00

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

2008-02-13T20:33:00.004+01:00

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

2008-02-10T15:22:00.000+01:00

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

2008-01-27T19:52:00.000+01:00

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

2008-01-16T19:49:00.000+01:00

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

2007-12-05T14:25:00.000+01:00

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

2007-10-06T13:30:00.000+01:00

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.

Agile @ JAOO 2007 #2

2007-09-25T22:40:00.000+01:00

I should actually call this post; SCRUM @ JAOO because that was what the track was called. But anyway it was not only information on scrum that I am left with after the second day of the conference.

Key elements
Rythm is important. - Let it be the heartbeat of the team.
Roadmap is still important even you are doing agile.
Do not overload the experts, especially on multiteam environments.
Architecture is allowed! Abstractions and interfaces are a very good way of doing this. (Coplien had some really nice slides on this)
TDD is both good and bad (according to Coplien its only bad, but there where alot of discussions on this).
Domain is important. -It creates the bridge between developers, customers and users.
Retrospectives - Important for learning and communication (Prime Directive)

Wish I had more time to go in to detail on all the issues, but I will have to do that at a later time.

Agile @ JAOO 2007 #1

2007-09-24T22:09:00.000+01:00

Yes, I'm attending the JAOO Conference in Denmark at the moment. Today I have seen most of the presentations in the agile track and I'm quite satisfied with the amount of information that has found its way through my ears and eyes to my brain. This information is now in a process of being mixed with my own experiences and thoughts. Hopefully on wednesday I will be able to go home and create knowledge by acting upon the informaton I now have.

I'll cut the chase and tell you. Agile Retrospectives by Diana Larsen was the last presentation on the track and its the one that still sticks in memory (The rest is written down in notes). The presentation was a small summary of Diana's experience regarding the facilitation of constructive discussions and retrospectives. One of the things she mentioned was that there is no blame in such a retrospective. The meaning is to find out what went wrong and fix it or to find ways to improve and not to finde someone to put your finger at. It is a team responsibility so there is noone to blame. Diana claims this is one of the key elements of a good retrospective, a safe environment where one can share thoughts and perspectives without handing out or be blamed for what went wrong (or right for that matter).

A second thing she mentioned was the amount of actions you should focus on for the improvement in the next iteration. This should be one or at the max two actions. These should be followed up in several ways. In the daily standing meeting was one, another being in the planning of the new iteration (ie put it on the sprint queue).

Diana Larsen inspire to a deeper look into retrospectives and from the feel of it, I think that my autumn books might be on the subject.

Have a nice night and I'll be back tomorrow with another tiny bit of the JAOO Conference

Friction and slow delivery

2007-09-16T18:18:00.000+01:00

I was just reading up on my favourite blogs when i came over a interesting post on the From where I sit -blog. Michael S. Hyatt describes what he sees as friction when visiting a bookstore. The idea is to get the purchase happen fast enough so the customer does not change his mind or as in Michael's case, leave the shop because it took too long to get the purchase done.

Could we not draw parallel from this to our development of software and project practice? The customers want a new feature in an already developed software. We receive the request and we specify it further with the customer. We estimate the time it will take to develop the new functionality. Customer gives us clearance to start working on it. We work on it. We finish the development on the new feature and we test it. We do not deliver it, because we have more things on our list to do in this release. The customer knows this so he is patiently waiting for us to finish this as well, because he also wants the other changes. We test the other changes, we might find a bug and work more on the issue. Then we hand the release over to the customer so he can test it, this is 6 weeks after the order was placed. They find a bug which get reported back to us and we start fixing it. We deliver a patch for the release and they test this. All is well and the testing is over, the release goes to production. The users finally see the new feature which they wished for, maybe 3 months ago.

What if the process where a bit different? What if we develop the new functionality and test it and deliver this to the customer. The customer tests the new functionality while we develop the other requests on the list. The customer find no bugs in the functionality and we release it to production. Or if the customer finds a bug, he reports it and get a new release from us with the fix and maybe more new functionality in it. Maybe some of the other things on the list was finished and tested in time to get it with the fix for the new functionality. Customer gets the new delivery and test it again, now with additional functionality. It goes through and we release it to production, maybe 3 weeks from when the users wanted the new feature.

To me this sounds better than the initial way of doing things. If the functionality that gives value to the customer is done, give it to them! If the users want changes, make the change and deliver it to them as fast as you can. No need to wait.

There are of course issues around this. One of them being the ability of the customer to actually receive and test the new functionality as fast as you deliver it. Another might be that the initial software is used 24 hours a day and a production release will hinder them in their work and cost money. But I urge people to think on this and ask their customer if they really cannot receive and test small parts rather than big chunks of functionality. Do they really want to wait that long for something they ordered? Why should they order and add all these orders in to one delivery? Does 15 minute downtime on their production system really cost that much versus having users waiting for functionality for months? Do their lack of motivation towards the use of the system cost less?

In this post I have not even started talking about the cost of long feedback loops on the delivered functionality. I'll save that for another post sometime.

TDD momentum continues

2007-08-15T20:21:00.000+01:00

Just a small update this time. The TDD course seemed to go ok and many of the participants now have an understanding of how to actually write the tests first and then move on to the production code.

I got good feedback on the theory of the course, but the practical part was a bit unorganised and some found it difficult to think as proposed in TDD. This was great! It shows that we are truly not used to think this way and hopefully it will inspire to more.

I will refine my course to be even more streamlined when it comes to the practical part and hopefully with other employees we will not have the issue of an unfamiliar IDE.

For the .Net guys out there I came over this CruiseControl.Net demo today. So no excuses for not having continuous integration on your platform either!

I'll be back with a longer post on management issues when faced with delays which is out of your control. (promise!)

Test-Driven Development Momentum

2007-08-05T17:44:00.000+01:00

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?

2007-07-28T10:31:00.000+01:00

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?

Rationale for the change

2007-07-22T21:51:00.000+01:00

Change can happen in many ways and there is so many factors involved. As mentioned on my favorite leadership blog: Leadership in Practice, change fails when employees dont grasp the rationale for the change. By rationale meaning the why in the change. Why is it happening? Does the change only happen because some leader have found out that this should be better for the employees or its the latest hype? Head over there and read the post, it's a good one.

As i commented on George Amblers blog, it is more than just the rationale in change. It's the what and how as well. Many of these decisions should be taken by the employees afflicted by the change. They should know best how to perform changes. At least most of the time.

Maybe its naive to think that way, but to believe in people make them do incredible things.

Are the customer involved enough?

2007-07-11T10:16:00.000+01:00

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?

Code review: increased quality and knowledge sharing

2007-06-17T11:44:00.000+01:00

In my earlier post "Make it better" I said we were starting with a more TDD similar approach. We have tried this now for more than a month. We have tried writing tests first, but this seem to be a futile attempt. Arguments used are "I tried, but it took too much time to make the test" and "It is too difficult to make the test and it was only a small change in the code". To these arguments I can say that they are true in our case. Much of our legacy businesslogic has been placed in beans which in our case are difficult to write tests for. Hopefully we will be able to make more tests totally new businesslogic rather than trying to make it for the old code.

This said, I would say that we have in this process learned a lot about our own code and its limitations. Placing the business logic in beans is not good for the ability to test the code. We will try not to blindly do as the one before us did. I figured a way to try to compensate for the lack of writing the tests and introduced mandatory code review before any code can be checked in to the subversion repository. This forces the developer to argument and discuss the code before it become a part of the solution. It gives the developer another perspective and thus enable both the sharing of knowledge and an increase of quality. As in TDD the idea is that one would think differently before coding because we write the test first, we in this case do the code review after the coding but still enable the developer to get comments on both the code and its quality.

At the last xp & agile meetup in oslo we had Robert C. Martin (uncle Bob) present his thoughts on craftmanship and ethics where he mentioned that if we checked in code that was just a little bit cleaner and better than when we checked out we would eventually increase the quality of the code. The code review is a good incentive for this practice.

To quote uncle Bob: "Never check in bad code!"

Motivation at work. More than money?

2007-05-20T15:32:00.000+01:00

A process is taking place in Computas these days. It is the annual company negotiation of salary. The process is an interesting one where we have a comitee of members in the worker-union (Tekna) and non-union-members, agreeing on our demand regarding this years increase in pay.
These people sits down and discuss the economy of the company and bring a broad perspective of worker-opinions to the table. When the comitee have reached a proposal, it is presented to the workers in the company and if no one objects, the leader of the group delivers this to the company leadership. The delivered document is then the official demand from the workers. This is where the process gets interesting.

During a month the discussion goes back and forth on what is acceptable and various arguments are put on the table. Some may claim that salary is what keeps them motivated and other may claim the opposite. I tend to think that money is really not what is motivating me at work but as Susan Heathfield so elegantly tells us, it always include money.

The salary I get goes to paying my bills and it enables me to live the life I have today. With this said it is apparent that I need more than just to enable me to vile my life outside working hours to keep me motivated. Buying a flat in Oslo will not keep me motivated at work for a long time. It will of course enable me to have a better life in the sense that I will have my own space and thus hopefully have a better economy than now when renting a flat. It would feel much better to pay for my own flat rather than paying for somebody else' flat.

I am insinuating that salary is a cornerstone in work-motivation, but its role is an enabler. This meaning it has to be there to be able to motivate on other areas (as I've mentioned in earlier posts).

And yes I am very curious on how much this years pay increase will be.

To be agile or not to be agile, is that the question?

2007-05-14T21:09:00.000+01:00

What is really agile? Are we really agile or has it become a hype?

These were questions that was brought up on todays xp.meetup without coming to any conclusion, but nonetheless a fruitful discussion inspired me to write this post.

One of the issues mentioned was related to technology and how agile you can get. Many agrees that technology influence our way to work and thus how agile we are in our work. And it was in this context that J2EE was mentioned as something that really held you back from working agile. This might be well and true, but isn't the question really "How agile can you get" and at the same time deliver what the customer want with the agreed quality?

Many projects today deal with legacy technology and different aspects of the past that impose restraints on our solutions. Would it not be possible to say that one is agile in the way they are dealing with this legacy technology? Be it test driven development (TDD) with or without behaviour driven development (BDD). The world is full of legacy..

Make it better

2007-04-10T18:00:00.000+01:00

Easter vacations are over and we are finally getting back to work. I have a few exciting things happening this week as my role as project leader is getting more familiar. One of the things is a full day unit-test workshop with my project members.

Testing we do today:
1. Your own testing when you have written the functionality
- Verifies that you do not have any obvious errors
2. Someone else tests the functionality after your description of how to test it
- Verifies that you have not skipped the testing? Sometimes people do different approaches here..
3. We run a robot-test on main functionality of the solution.
- This ensures that we do not have errors that stops the solution or influence the core functionality.

After this our solution leaves the office and is delivered for testing by the customer.
This approach would work great if it had not been for the time between our beginning of the programming/coding and the time we get feedback. It has a high risk of creating a gap between what the customer wants and what he gets. To help with this gap, we have iterations in the implementation phase which is highly influenced by customer feedback.

All well and good so far.

The issues start showing up in Jira (our bug tracker) some time later. This might be issues connected to integration or even several years old code. The amount of code lines and the number of integration points are increasing every day. To avoid the problem of having feedback this late I think we need to increase the release cycle and write unit-tests before we code. The "write the test first" (or TDD) rule will enable us to think differently before we start coding. As well as seeing implications earlier and taking these in account when implementing our functionality. One of our goal is to increase the quality of both code and functionality and this will work as an enabler. After doing this a while we will hopefully be able to start with nightly builds and catch more bugs this way.

Oops..This post got a bit more technical than planned, but anyway thats the main thoughts.

You might ask "why we need a 1 day workshop on this?". The keyword is ownership and engagement. If I just say that we are from tomorrow writing tests before we code new functionality, who would do it?
By doing this together we lower the barrier for something new and we increase everyones competence by working together on the different problems that comes up. We have focus on this for a whole day and might actually remember it.

The ultimate goal is an increase in quality and pride in what we deliver. Even if we work with legacy code and others mistakes, we can make it better! And we will!

Small note on reflection

2007-04-03T22:23:00.000+01:00

Just want to point you to a small post over at The Practice of Leadership blog . And hopefully you all will take some time away to reflect and relax during this easter. To keep the motivation up one need to reflect on what has been accomplished as well as what has not.

Happy Easter everyone!

Presentation skills and feedback

2007-03-24T14:37:00.000+01:00

I've had a few presentations at work, but often I feel that they could be more focused and clear. Recently I also got feedback that I was saying some words as "Hmm. What is it I'm going to say..." or similar. And today I came across the stop, start, continue technique over at Dwayne Melancons blog.

People should be better to give feedback to people that holds presentations. In this way one might be given a chance to improve instead of making the same mistakes again and again. This is in a sense knowledge sharing. The have a different perspective on the whole presentation that you have. Things you find easy can be difficult for others, but it is often difficult to get people to actively participate in the presentation. Lets hope that when I next time pull out my paper with the stop, start, continue notes on it, people will laugh and point out when I do the mistakes. Hopefully I will then learn more and even get the audience to participate in -at least- some way

Scrum - something for maintenance projects?

2007-03-22T18:58:00.000+01:00

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?

Work Environment

2007-03-03T16:28:00.000+01:00

On Friday we got a presentation at Computas by Sintef. The topic of the presentation was work environment and workspace. By this meaning office layout and its implication on efficiency, productivity and identity. They had an interesting perspective on how we where behaving in different workspace solutions. One of the points i picked up was the difference between a workspace geared for communication versus concentration. Cell offices works best for the latter and they had seen increase in communication with open office solutions. This created reactions in the audience which today have cell offices, but often with an "open" space between their offices. The offices are also occupied by people working on the same project. It was mentioned that the walls toward the open space was made of glass. Only that most people sit with their back to the door and the glass wall and the open space between the cell offices.

I think moving around is healthy for your own motivation and inspiration. I also think that open office solutions is one of the better solutions for knowledge workers. Here is what I wrote in my master thesis on the subject:

Work Environment
As an important facilitator of knowledge sharing Davenport and Prusak (1998) mention the work environment. They claim that changes in the work environment may cause loss of knowledge and it can also disrupt the existing sharing process. Knowledge has a tendency to thrive only in the environment it develops. Elements mentioned are, “organisational size, focus, management and intangibles as trust and atmosphere.” In the previous section organisational structure and size was described as an influential element to the way a knowledge worker performs. Knowledge workers often collaborate in different ways and use communication tools as well as face-to-face communication.

Office environment needs to facilitate the collaboration and exchange of tacit as well as explicit knowledge, Davenport (2005) mentions meeting spaces and conference rooms as a minimum. He goes further and suggests, based on findings by Thomas Allen (1984), that knowledge workers who need to communicate should be located physically close to each other. Becker and Sims (2001) claim, “The more open the environment, the more frequent the communication and the shorter the duration.” In addition to this they say that the communication in such an environment is “not viewed as interruptions, but these short, frequent interactions provide very fast feedback and shortresponse times, allowing work to move forward overall.” The data from Becker and Sims’ report also suggest that more visual contact actually contributes to fewer unwanted interactions, by “changing not so much the frequency as the timing of serendipitous communication.” By this they mean that by having visual contact the workers can see if the others are busy and not interrupt. On a more organisational level Allen (1984) claims that knowledge workers work environment should have aspects from the departments that work with Human Resources (HR), Information Technology (IT) and facilities organisations. These aspects together can create a thriving working environment with elements important for atmosphere, communication and the use of process supporting tools.

References

Davenport, T. H. and Prusak, L. (1998) Working knowledge : how organizations manage
what they know, Harvard Business School Press, Boston, Mass.

Davenport, T. H. (2005) Thinking for a living : how to get better performance and results
from knowledge workers, Harvard Business School Press, Boston, Mass.

Allen, J. T. (1984) Managing the Flow of Technology, MIT Press, Cambridge.

Becker, F. and Sims, W. (2001) Offices That Work - Balancing Communication,
Flexibility and Cost, October, Cornell University.

Being a change-maker

2007-02-28T18:11:00.000+01:00

"I always wonder why people do not understand what is good for them". The phrase is a common one.

Many of us have surely read books on culture and knowledge sharing, but find it difficult to implement the theories in practice. It is difficult and rightly so. Culture is about people and handling people is difficult, much because we are individuals with a different viewpoint, background and desire. These three elements may seem obvious, but why is it then so often forgotten?

Viewpoint
People involved in different work have different viewpoints, they see issues related to their context. How can I have any use of this in my work or situation.

Background
Often people that work together have different background and experiences. They might have had different work-experience or even a totally different upbringing.

Desire
Most people have an idea of how they would like to work or how their work should be performed and organised. Many feel that they do not want anything to change because they are comfortable with the way things are now.

In my daily life I find these three elements important to think of when handling with people. When trying to change something in your workplace, these elements will help you getting started on the positive side.
If you know the viewpoint, background and desire of a person which is involved in a change process, they will help you to find a way to influence this person positively. Apply to the desire by highlighting the benefits that can fulfill the desire. Use models, images or stories that can be related to their background so the person can identify with it. And use examples that is directly connected to their viewpoint.

There is of course a lot more to be said on this subject, but could bee a good starting point for creating ownership for the change-process in the individual.

Management Style

2007-02-24T14:46:00.000+01:00

My previous post about Team Learning put requirements on the management. How can one manage people that know the job better than you or even work in their own way.

Management style is often influenced by organisational structure and reflects in what way the workers are coordinated. On the note of managing people Drucker (1999) mentions “that one does not ’manage’ people, but the task is to lead people.” And the goal is to make the specific strengths and knowledge productive of each individual. The more skilled and proficient a worker is in his work, the harder it is to manage this activity according to traditional management methods. A direct supervision approach requires that the supervisor have more knowledge or is more skilled than the worker to be able to know what the worker is supposed to be doing to get the wanted result. Due to the mentioned change towards more knowledge work in organisations today, Drucker claim that one does not need supervisors(13), but a leader –or put in terms of today- a coach(14).

Both Drucker (1999) and Wenger (2004) describes that their view of knowledge management begins with managing oneself as a knowledge worker. Take an active role towards your own learning and increase of knowledge. Peter Senge (1992) sees managing oneself as personal mastery, and by this meaning to developing one’s own proficiency. “Personal mastery is likened to be a lifelong journey with no ultimate destination.” He tells us that such a journey consists of processes whereby “a person continually clarifies and deepens personal vision, focuses energy on it, develops patience in seeking it, and in this way apparently increasingly views reality objectively.” This ownership and involvement leads people to do positive things towards achieving personal vision. Further personal vision is described as a calling of intrinsic desires, not a purpose to pursue. Senge claims as result, “People hold a sacred view of work because work now is valued for itself, rather than posing a chore that needs to be done as a means to some other end.“

People with high personal mastery “tend to be committed and exude initiative, have a broader and deeper sense of responsibility” in their work, and as Senge claims of key importance, they learn faster. This gives strength to the belief that answers to organisational inefficiencies lies not only in technology. Technology has often been seen as solution to efficiency and automation of traditional repetitive tasks. Furthermore information technology has enabled new ways of communicating and changed many of the traditional crafts and professions.

*13: Mintzberg (1983) claim that direct supervision requires close personal contact between manager and the worker, with the result that there is some limit to the number workers any one manager can supervise.
*14: Coaching has been used in sports and has become increasingly used as a management style in business the recent years. More on coaching see: http://en.wikipedia.org/wiki/Coaching

Motivating Workers

2007-02-24T13:01:00.000+01:00

I've always ponder around how to motivate people. To me it seems there are a few guidelines in general, but as with much else you need to tweak it to fit with your context. Kathy Sierra wrote a few interesting lines on passion for work here. And when reading it I found a few other blogs that where interesting. One of them being David Maisters blog and another being Christopher Marstons blog, both giving good ideas on how to "manage" people. They are all well worth a look!

Team Learning

2007-02-19T18:41:00.000+01:00

The previous post trigged a wish to share some excerpts from my master thesis with you!

In many organisations today, people are organised in groups to perform specific task. These groups are often called teams. The team can contain knowledge workers that acquire, generate and share knowledge. They work and learn together. Senge (1992) calls this team learning. Flood (1999) claims that often the aim of team learning is to achieve alignment in people’s thoughts and energies. This brings us back to the notion of mental models and that the mentioned alignment in thought is a shared mental model, or at least a similar mental model with common elements or schemata. If we have people that work with the same tasks within a similar context it could be that they have in some sense similar mental models regarding the task, thus a common understanding (Senge, 1992). Davenport and Prusak (1998) mention that without a common understanding of terms, knowledge sharing might not occur. Sometimes multiple and contradictory meanings for fundamental terms exists in many organisations and create barriers to consolidate information and knowledge. In support of this, Senge (1992) claims that discussion and dialogue are the most important practises in a team. He argues that discussion and dialogue are necessary counterparts in a quest for consensus. This consensus can be seen as alignment in the mental models between the knowledge workers.

Davenport and Prusak (1998) notes that the traditional management attitude is “Stop talking and get to work!”, while the advice to a knowledge worker should be “Start talking and get to work!”. This communication and alignment in energy and thought can result in what some organisations call best practices, where people learn from each-others’ success. The sharing does not only occur within the group, but it also influences other groups in the organisation, meaning the groups are not disclosed to influence from the outside. Team learning and knowledge sharing within a team enables us to act with today’s knowledge instead.

Another perspective posed along the same lines is to understand tacit knowledge sharing in a team, as people “following rules by being members of communities, with the disposition to reciprocally adjust our use of signs to that of the rest of the community” (Gerrans, 2005). This means that a community has its own rules and we act accordingly.

Interesting Answers

2007-02-19T17:26:00.000+01:00

I have been quite busy at work the last week, but I did ask some questions..

And it seems that most questions can be asked without starting any problems for yourself or put you in a bad position. At least that was my experience during last week at work. The question opens for a dialog and create social relations between the people involved. I asked the questions because I where interested in the answers. This dialog has showed me perspectives from another part of the organisation and it has even influenced that part of the organisation to think a little different (at least it feels that way). A difference in perspective is natural, but with dialog we are able to direct the perspectives and the mental model of both parts involved towards a common one or something you can call an agreement. Or at the very least an understanding of each others viewpoints.

It reminds me of a motto I have: "If you do not tell the person what you think is wrong, how can that person do anything about it?" This meaning that if a person is not aware of his "wrong" behaviour, it will stay that way for a long time. If we have a dialog and talk about the issue we might both gain an understanding of why this behaviour is wrong. It might also be that it is right for him and wrong for you, but from knowing his perspective you can understand his actions.

I will end the post with a few words from Davenport and Prusak (1998), "Start talking and get to work!" (instead of the traditional "Stop talking and get to work!")

The importance of questions

2007-02-04T21:10:00.000+01:00

To ask questions is imperative to innovation and when sharing knowledge. As I have mentioned earlier in my posting, Ricardo Semler writes about how they work at Semco. He mention that Semco companies promote people to ask questions in their work. By this enabling known truths to be questioned and open the possibilities of better answers than the ones you already know.

This way of thinking can initiate a lot of change in an organisation. If I was to ask about why we never see any documents or an agenda of the leader-meeting in the company i work for (Computas), the answer would probably be something like "We discuss important issues that is handled by the leaders" or something similar.. This would then generate a new set of why's .. These are questions that can open up the organisation and create trust between management and the rest of the workers.

I will make next week my WHY-week at work and note what answers i get.

Share the information

2007-01-30T20:40:00.000+01:00

I have to mention a situation I experienced the other day when riding the train for work, like I do every day.

I am waiting for a train which is announced to be "delayed" ,but decide to move to another platform and try to catch another train. This train also stops at my destination and is scheduled to depart in five minutes. Train arrives and I get in, but when I had been sitting in this train for about ten minutes there is an announcement on the radio, telling the passengers that the train is actually waiting for the train-employee that actually "drives" the train. I thought my decision to change train was still a good one since my first train was probably coming in very late. Minutes came and went.. Another train passed the platform, this third train also stops at my destination, but I then thought that I would not make that one. And I was not about to run out of the train again to catch the other train.

A while after the third train left the platform we where still waiting for our chauffeur and the first train arrived the station. I did not want to move back to that platform either, afraid of loosing both trains while running between the platforms. Ok.. That train leaves as well! Now I was actually getting irritated and wanted more information. The train started moving in about 10 minutes after this. I had spent more than 30 minutes waiting. When the conductor comes for the tickets I ask why we where so late. She said the train driver had been on the first train I was waiting for.. Just this tiny and crucial piece of information could have changed my choices during my wait. (if they had this information earlier themselves of course)

I can just imagine when one is in business situations and that little piece of information is not available to you. All the difference it could make. Projects has to reinvent the wheel because the information is not found or provided to them. You waste both time and motivation on doing tasks that can be done faster and probably easier if you had the right information.

Bottom line is: Share the information!

Semco, Semler and interviews

2007-01-28T10:00:00.000+01:00

In the book, The seven-day weekend, Ricardo Semler writes about how they interview applicants for a job at a Semco firm. They do not have a dedicated department for doing these things although it seems that they do have a HR manager. After dividing the applications between the volunteers, which was usually department managers or similar. They would then read the applications and pick what they thought would be the best persons for the job. Later these applicants was asked to come to an interview. Sometimes they had individual interviews to be able to shorten the list of candidates. When they where down to a manageable number they would arrange for a new interview with all the candidates at the same time. For this interview the employees in the hiring department would be able to come and ask any question they may have. In the book they emphasise that this enables the employees to have ownership in the decision of who gets the job. In addition they would actually know the person that gets the job. This is also apply when they are interviewing the position as their new boss.

This is really an interesting way of conducting interviews! It creates a democratic way of choosing who is the best suited person for the job. A process that does not only rely on grades from school and an interview with people your never going to see again (and people your never going to work with). It seems such a logical and intuitive (if there is such a combination) way of conducting interviews. This enables the other employees to accept the person and base the choice on what they value in a fellow worker. Their the ones that knows what it takes to do the job, not necessarily the recruiting department or even the manager.

I am trying to see how I would react to such a process if I had applied for a job. I would meet the "competition" and be openly exposed to them and the employees in the interview. One of the thoughts i get is that I would be pushed in to a competing mode. On the other hand I would find out if this is a job I really want and what it is all about since I talk to the employees and their questions mirrors the requirements for the job. In addition I would find out if I would fit in and be able to work together with the other employees.

This being said, the way it is handled seems very important for the result. It could easily end up on the other end of the scale, like Donald Trump's show The Apprentice.

The seven-day weekend

2007-01-21T13:16:00.000+01:00

I just started reading a book called The seven-day weekend (excerpt from chapter 1) by Ricardo Semler. Looking forward to see the thoughts behind the success of his company Semco. So far I've read alot about responsible adults and how people use their time differently when employed by Semco. The have really taken the idea of flexitime to another level. Semler mentions that one of the important goal is to have motivated employees. The example that is often referred to is answering emails on Sunday's and watching a movie on Monday afternoon. Freedom to think and to enjoy life, be it while working or fishing. It reminds me of what I read from Peter Senge when doing my masterthesis. Senge proposed an idea of work being meaningful to yourself and be connected to your own personal goals. Work is integrated, your life and your time not divided into spare time and work time. It also seems that Semler have ideas similar to those from Peter Drucker about workers are able to manage themselves without supervision and control.

I will come back with a full review and more thoughts when I have read the whole book. While waiting you should head over to CIOinsights and read an interesting interview with Semler here.

What about a stereo?

2007-01-18T20:24:00.000+01:00

Today I got myself a stereo with loudspeakers and the lot. It was great and I can now enjoy music in a new way. Even found my old CD's to play!

But when doing the work of setting up the different parts as DVD player, amplifier and loudspeakers the thought struck me again as so many times before. How much had I not learned about loudspeakers and amplifiers while searching the internet for the right price and something that suited my "needs". In the process of searching for the "right" components for me I learned a lot about the technology and how it was to be used. When I now have the technology here in my flat that information that I earlier read of the web is transformed into knowledge by me actually acting upon that information. This information have enabled me to have a mental idea of what to expect and what to do with the different components. I have somehow an understanding of how the whole system works.

I've been reading the manuals with a genuine interest in how things work and what I can get out of it. Imagine if we could inspire this kind of engagement in schools and other learning institutions. Creating an interest that goes beyond that of getting a good grade or just "because i need it for my work".