Mar 1, 2015

Book Review: Run Less Run Faster

I try to read couple of sports books every year. I've heard from couple of different sources that Run Less Run Faster is an excellent book for busy runners wanting to develop their run.

Idea in Run Less Run Faster is easy, concentrate on your key runs and make sure you stay healthy. Book advises to get rid of junk miles, meaning the runs without specific purpose. Also it explains that three runs in a week is enough when it's supported with proper supporting training.

I do agree with the thinking in the book. I've run maximum of three runs in past years and I've been able to run much faster than previously. I've also discovered that key to improvement is different kind of runs and pushing yourself to the limits. So I do think book is good and valuable for many people.

Book also gives quite good exercises for runs and strength training. It is a good source for knowing what speeds to use in different exercises and what should be the amount of rest in different intervals. Also for strength and flexibility training it explains the basics.

What I worry with this kind of guidance to training is that it kills the joy of training. When every exercise have specific meaning and you need to watch you clock all the time, you easily lose the joy you can get from exercises. Everyone, including myself, should once in a while remember why they are training, for themselves or for some other reason.

The book in itself is easy and enjoyable. Especially for the runners who don't do enough different kind of exercises, this is a must read. For the people who already have wide range of training in their program, this might not be be worth of reading.

Written by +Henri Hämäläinen

Feb 24, 2015

Why Change Fails - 4 Key Findings

I've worked with several companies as a consultant helping and leading change projects. Also I've experienced changes from the inside and heard many stories from other companies. Based on that experience, here are the four things that are the main reasons for change to fail.

1. There is a plan for the change, but not a vision for the change


Organizations detect needs for changes easily. All the time there comes ideas from the inside or outside for the change. Once in a while change idea gets to a proper group of people and they have the power to start the Change. Then starts the short planning phase. Budgets or people are confirmed, timelines are created and benefits of the change are communicated. What often is forgotten is the underlying reasoning for the change and especially the vision of how the new model should work.

This becomes a problem when there will become changes to the Change. And this always happens, the Change will never go directly as planned, but there will be needs for re-planning. This is acceptable and normal, because there will always be learning happening during the Change. The problem arises, when the vision why the Change was done in the first place is forgotten and changes to Change project will actually turn the ideas to the wrong direction.

An example of this kind of behavior could be streamlining error handling process to cut time from error reporting to error fixing. During the change process, the team finds out that there is company level KPI of the error severity and the change would mess that measurement. So instead of removing some states of the process they decide to create an automatic ranking and assignment system based on the error location component, reporter and SW version. Then for each person handling the errors they'll advice to make sure the error ranking and assignment is correct. In the end the error process actually got longer due to the automation of one part of the process.

Even though the example is simplified and might sound silly, this kind of things I've seen to happen often. The idea behind the change is slowly modified to something else during the change process. The only way not let this happen, it to have few people to have clear vision of the backgrounds of the change and to empower them to lead the change.

2. People are not actively involved early enough


What I've learned with changes is that people do not that much like to be involved, but they hate if they are not asked to be involved. So it's not that important to get everyone involved to the change early, but it is essential that all relevant people are notified about the change early.

In many occasions I've seen people to come later to say that they would have liked to give their opinions earlier. For that reason, I've tried to involve as much people from the beginning as possible. Most often people actually don't have much to say and are not that interested to participate after all, but they are more friendly towards the Change because they were asked early.

So the learning really is, involve all the relevant people from the beginning. Don't take them in to the core group, but ask for their opinions in one to one interviews or targeted questionnaires when the group is larger. This is essential part of success of the Change. It will cut down the possibilities to be against the change later on.


3. There isn't enough time given for the change


I come from the software world, where everyone nowadays start to know that estimates always fail. Projects rarely get done on planned time frame. Still with Change Projects, these estimates will fail much more. Organizations somehow always forget that they have their daily business to take care on.

This happens always, organizations fail to estimate how much they have time and capabilities to use, to properly drive a Change through. Getting on hold of people and finding time to secondary activities in organizations easily take weeks.

Then in the long run, people will get frustrated about the speed of changes and some of the changes will die because of slow progress. There needs to be realistic schedule for changes and people who selected to drive changes forward need to empowered for the work. These feels like basic stuff, but somehow these seem to fail in many occasions.


4. Change resistance are not handled correctly


There is two types of change resistance: late adopters and the people actually against the change. Late adopters are people who take time to understand the value of the change. They often ask good clarifying questions and are valuable part of making the change better. Then the other group is the people who for a reason or another are not willing to accept the change. In some occasions they have valid arguments, sometimes they have their own personal reasons not to play along with others.

With both groups it is essential to talk with them often. The worst thing to do is to ignore them. This will raise even more resistance and it might cause a movement against the change. Best thing to do is to confront them. You don't need to agree with them, but try to understand what is the good intention they have in mind. This is the essential thing again, people need to be heard, not necessarily agreed with.

My tip is to confront change resistant people one to one. When talking to change resistant people in a group, they will never change their mind and lose their faces in front of the group. Talking with them one to one makes it possible for people to change their view. Still when talking one to one with change resistant person, the goal shouldn't ever be changing ones mind. The goal is to understand why they are against the change. You don't need to change your own mind and they don't need to change their mind, but the goal is that you both mutually agree each others view. After that there are several alternatives forward, but before mutual understanding, there isn't almost any.


Summary of my tips to successful Change Project 


Change project are difficult, but not that difficult. The approach for change often is too pragmatic, there's too much planning of communications and steps to take. There should be more focus on discussions with people and having enough time for the change.

Other key thing is to remember why the change is done. Even though it sounds ridiculous, I believe many changes fail because at some point no one remembers what was the actual problem the change was suppose to fix.

Last but not least, people working on change easily forget, that the change isn't the most important thing happening for the others. For many change is just one of the many things ongoing at daily work. Changes need active communication and involvement. It isn't enough to publish information available, there needs to be active feedback loop in making sure that the messages actually gets delivered.



Written by +Henri Hämäläinen

Feb 15, 2015

Book Review: The Lean Startup

The Lean Startup by Eric Ries was a book I had heard about so many times that I had to read it myself. I had heard about Lean Startup methodology and read about it in many blog posts, but I hadn't read the book. In a way the topic was familiar even before starting, but still there were learning to gain from the book.

Ideology of Lean Startup is really valuable. I believe there's some truth behind what Eric Ries is talking about. The main idea of Lean Startup is that is valuable to measure the ideas in the market and be willing to learn from the results and pivot the course if needed.

I especially liked what Eric wrote about what actually is an MVP. In my own believes I often seen MVP to be much less than companies are themselves thinking it to be. Also validated learning, innovation accounting and the whole build-measure-learn loop were valuable parts of the book.

What I didn't like was that the book wasn't anywhere close to minimum viable book. It was utterly too long and once in a while even boring. I believe the ideas of the subject could have been delivered in 100 pages. That would have proven the value of the thinking. Now it was as any other ordinary book, lengthened to almost 300 pages in order to seem as a "normal" book. I just hate that approach. When there isn't that much to say, why to waste so many pages on it.

I feel bit bad to criticize the book since, I think that everyone should learn about the Lean Startup methodology. It is valuable and would help many companies and startups to succeed. I believe the book just isn't the best way to learn about the subject.


Written by +Henri Hämäläinen

Jan 29, 2015

Story inside Nokia - Creating SW Solution in Enterprise Agile

Symbian has been long enough dead and Nokia has moved on from smartphone business, so maybe it's time to tell a story from inside. I was there in Symbian Multimedia for 6 years. This is a personal story about how hard it was to create new software using many existing assets of the company.

It was the time teams had been using Agile methodologies for some time. Some teams used Scrum, others Kanban. At that point there was going on a huge transformation towards Enterprise Agile. One of the main concepts was Epic based development. That basically meant that Epics (you can think those as big user stories or projects) where created to describe the customer value regardless of the organization or product limits. So the idea was excellent, to be able to exploit the software and product assets of Nokia for customer benefit, what ever needed.

Story of Epic and 113 people


So I got appointed to be the Epic Owner for one of the first Epics trying this new process out. Epic as such wasn't my idea and the contents of it are irrelevant for this blog post. In short basic idea of the Epic was to combine Entertainment and new social technologies. So it was a perfect example for the Epic thinking. It used existing SW assets, needed bit of code on top those and would create a new kind of value to the customers and new business to Nokia.

There was a small team gathered around this Epic. I can't recall exactly, but I think there was 5 of us in a team. My role was to work similarly as product owner to keep the vision of the Epic in place and make sure our team could actually accomplish the thing.

After the start, first things was to get to see the codes, API documentation and stuff like that from different SW teams. Those would help us creating the solution we were after. That already needed lot of internal selling. I flew around and had quite many online and face to face meetings to convince the involved teams to let us work with their code.

After we had everything in place to start, we were able in less than two weeks to have a well working prototype about the solution. It wasn't in the sales quality, but good enough quality to show around. At that time we started to do more internal selling to be able to actually make the final solution, which wasn't that complicated in the end. That was the point we hit the big organizational wall.

There was tens of people who wanted to have their say what was needed to take in to account before releasing the solution out. Some of the people had valid points, since releasing to basically all the countries in the world was not that easy. And all the others were still doing the job they were hired to do. It was exhausting. We had a solution, but getting it out from the company was near to impossible.

One evening I was flying home from one the internal selling sessions, when I started to count that how many people who haven't contributed anything to code I have had to agree with. The number raised to 113 people! There had been 113 people who I had to talk with, in order to get a solution that took 4 developers less than 2 weeks to prototype, to get approved and released.

It's not an extreme case


Some of you might think this is extreme example of how things can go wrong. I'm sorry to say that's not. I've seen some other product development companies to have this problem too. In many cases creating the software isn't the hard part in creating the solutions. It's all the internal sales that need to happen on top of the solution. There needs to be, even in smaller organizations, tens of people who needs to approve the plan before something can actually happen.

There's a good intention of course behind all of this control. People often mean well. They have their own view to things and they want to control that something that is under their radar get thought properly. But that is exactly the problem, companies shouldn't be build on control, but on trust. But that's a different story.

More and more organizations have extensive SW or Product Portfolio. One of the things I hear discussed in many companies is, how to leverage the existing assets better to create new kind of business in the future. This definitely makes sense, it at least these kind of solutions could and should bring competitive advantage and to be even lot cheaper to create.

Unfortunately organizations rarely are ready for this. For example internal cash flows (meaning budgets) can make cross team work harder or even impossible. Also layer of product managers looking after their own products is a common show stopper for these cross product exercises. But there are lot of other hurdles in the way and this post's purpose wasn't to go in to too many details about that one.

Overall the problem is common. Big organizations should have all the assets to compete against the smaller ones, but most often the only way to compete it to acquire the small ones. For many reasons, big companies can't create innovative product easily. My example is just one from many different barriers.

Final Words


As a final words I have to say Symbian organization in Nokia was at the time really advanced in Scaling Agile to Enterprise level. There was lot of good practices in place and lot of competent people driving those forward. In order for the Epic thinking to actually work, it would have needed years of cultural change. This change was started, but as all of us know, Symbian was left burning and change never got to the end.

Written by +Henri Hämäläinen

Jan 20, 2015

Book Review: The Sports Gene

David Epstein's The Sports Gene was exciting read for me. I follow many different sports and I've been intrigued about how much success is about nature (genes) and how much about nurture (training, etc). This was the first time I got some concrete facts about the subject.

David Epstein isn't a scientist, but a sports journalist, who has made a long learning journey to be able to write about so technical subject. I believe this book is better, when it's written by a journalist and not by a scientist. Book goes quite deep into the genes and biology, so it's better when it's written in bit more understandable way.

Book tells stories and facts about athletics, basketball, sprint running, long distance running, cross country skiing, baseball and many others. It really tries to look for patterns behind athletes and their genes. For certain sports there are definitely genetic differences that make some athletes to have a superior change to succeed to others. Still success always needs lots of training.

In one way book is depressing for some sports. As an example, with current conditions in the world Kalenjin Kenyans will rule the marathon and long distance running field for some time. But actually not that long ago, Finnish people used to rule the long distance world (Hannes Kolehmainen, Paavo Nurmi, Lasse Viren) , before we got richer and didn't run that much anymore. So in a way we Finns still might have the genes for it, but our environment and training doesn't support those anymore. The same might happen to the Kenyans at some in the future.

The whole book bounces between nature and nurture. What is certain is that there are no genetically perfect athletes, because no one doesn't have any good ideas what genes actually are needed for which sports. There are some genes found which might prevent success in some sports and some genes that are common with the elite athletes in that sport. Most often still, the genes of elite athletes can be found from thousands of other who still are not elite. So there is no one answer for nature vs nurture debate.

One other thing that interested me was the trainability of people. Different genes actually mean that people develop differently. Populist journalism often tells that training like this and that will only give results. The fact is, people acquire skills differently. The famous 10 000 hour rule, isn't exactly true, but then on the other hand it gives an idea of the ball park people need to train. People need to train the way their body and mind adapts. That's the most important lesson of the book.

I highly recommend this book the everyone interested about sport training or coaching. It felt bit longish at some point, but reading this is time well invested.

Written by +Henri Hämäläinen