Being a coach is more than listening and giving advice

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

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

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

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

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

Maintenance - Repay the debt

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

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

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

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

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

From Complexian
Register.java: Complexity is 38

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


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

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

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

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

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!

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!

Make it better

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!

Presentation skills and feedback

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

Team Learning

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.

What about a stereo?

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