Book Review: How Google Works

I've been a google fan for a long time. I've read some books earlier about how they work, but when I heard that Eric Schmidt and Jonathan Rosenberg have been giving their name and content to the book How Google Works, I had to read it.

Book takes a broad view on how the work is been done at Google. In many times it does spent time on talking about values, but ideas of the values are then clarified with concrete examples. Overall the book is comprehensive view to Google as their high management sees it.

Book is structured quite nicely. It starts with culture, goes through strategy, talent handling, decision making, communication, innovation and then finishes with the moonshot ideology. Other that the just the high level themes there are concrete ways of working for each section.

I found the book interesting and important. Everyone in the product development industry would benefit of reading it. Every company can't work like google, they do have special possibilities due to such a strong position in the web, but still there's lot to learn to many companies.

I highly recommend this book to everyone interested on making companies better.

Written by +Henri Hämäläinen

Book Review: Peopleware: Productive Projects and Teams

I almost feel ashamed that I had missed this book for so long. Peopleware (3rd ed.) from Tom DeMarco and Timothy Lister is a book about soft side of product development and creative work overall. It goes through using many studies and examples why it is so important to take good care on people.

Book explains Human Resources, office environment, recruitment, growing productive teams, taking care of people and most importantly having fun at work. It's impossible to highlight all the important things they raise in the book, because there are so many. The main message is that people are the most important asset of many companies and too often people are not given good enough support and office spaces to get all the benefits from them.

I especially liked the office environment part. I've worked and seen so many bad offices where there are too much noise, too little light, too many interruptions and inadequate space and time for getting to the flow state. Most often there are stupid policies that prevent on creating workplaces that would actually suit to the needs of the workers. And then in worst cases there are some guys proud of saving money on small office. That's just sad.

But the book is not only about working environment. It discusses lot about teams and how to form great teams and what are the common ways to ruin good teams. Team development is something I've been interested for a long time, but still they were able to provide good new information and ideas to myself.

I honestly am bit ashamed that I didn't read the book earlier. When reading books, I always mark down parts that I will come back later and this book got most markings ever. It's a great great book and even really easy and fun to read.

This book is a gem and every manager and knowledge worker should read this. It gives lot of ideas and background information for building better teams and workplaces. I highly recommend this book.

Written by +Henri Hämäläinen

Role of the line management in the future - is there one?

Line management has a long history and quite often a special place in organizations. Line manager position have been something people are going after. Things have been changing, role of line management has been fading and even in some case going away. Still all organizations have some kind of line management. There's someone in every organization who is the boss.

Role of the line management in the future organizations is a difficult question. In one hand line management has it's role of bringing comfort and safety for the people, but then on the other hand it can slow down work, create competing priorities and even demotivate people. Especially difficult it is when line management has ties with operational responsibilities and company size grows over one team doing it all mentality.

In the past line management have had lot of operational responsibilities. Line manager used to be responsible that his or her people did their jobs properly. Also line managers did have content and operational responsibilities. They had to make sure right things were done and also in the right ways. That still seems quite natural, it's quite hard to guide if they can't also affect on the work their people are doing.

Then line managers started to get more and more responsibilities of the soft side of people. How people are doing? How they are developing themselves? And what worries they have? At that time there started to come more operational and content related guidance from other sources and line management didn't have that much to say about the content their people were working with.

Nowadays line management in many occasions have become almost totally HR function. Line managers arrange the one to one discussions with people, focusing on personal development and in some companies also to set targets.

Future of line management

Do we really need line management in the future organizations? What if we wouldn't have line management at all. No one couldn't tell people what to do and people would need to figure out themselves. I bet this would work in many cases. There are even examples of self guiding organizations, where people just make things happen. No guidance needed.

This sounds like an optimal approach. No one would have boss whom they would need to report to and no one would ever come to say what to do. Even though it feels like an utopia I believe organizations could work without any line management. From content point of view I don't believe people need to be told what to do, they can figure things out themselves.

So is there anything line management is still needed then? I can see two important points. First people need safety. People need to have someone they can count on in case there is something they can't figure out themselves. Things like this can be about company functions as pay or healthcare or then about how people behave. Once in a while there are misconducts and then it is important that there is line manager to help.

Second important point is personal development. It's rare that people would be that good on analyzing their own competences and the improvement needs that they wouldn't benefit from having a good teacher or coach to help them. This is what line management has a proper place in organizations. Line managers can help with competencies and guide and push people to develop their competence to right direction. They can also work as enablers to get training, coaching and peer learning from other people.

Both of these activities, safety and competence development doesn't actually need people to be bosses. The people responsible for these in organizations do need to have certain authority to do these jobs well, but they don't need to be supervisors in the old sense. I believe role of line management can actually be a service in the future. Many aspect of line management already are handled as a service, but maybe all of it could be.

So do people really need just one supervisor to help them. Why they couldn't have a small group of them working as a service guiding and helping people on in all the necessary ways. Somehow I feel this change wouldn't actually be that big to the ways many companies are already working. The change would be mainly mental. Line manager wouldn't mean your boss anymore, it would almost mean that you would be the boss and line manager would be the servant.

Written by +Henri Hämäläinen

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

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

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

Work Needs to be Fun - Happy people are more Effective

We spend every week around half of our time awake at work or travelling to work. Already from that perspective work needs to be something you are happy on doing. At least in my thinking being happy every day is something I wish from life.

That's still not all. There's research backing up the facts that happier people are more productive at work. Study from University of Warwick showed that happy people are 12 percent more productive than others.  That's of course just one study, but there's more data for similar results. In Gallup's State of the Global Workplace study (over 200 000 respondents) they found that companies which had engaged employees had significantly higher productivity, profitability, and customer ratings.

Even though I believe we need lot of other studies on the subject to be really sure about how the causation goes, there is definitely something in happiness at work place. Happiness at work place also might have a positive effect on company image and that way make it easier to recruit new talented people. On top of the previous one's there's also evidence that happiness has a strong effect on intrinsic motivation. And intrinsic motivation affects productivity.

My purpose wasn't in going to the academic discussion about what is proven and what is not. From personal experience, from my own workplaces and places I've seen as a consultant, this correlation is true. The happier people are, the better results the company will get.

In the State of the Global Workplace study, the engagement level in companies was surprisingly low. Overall in the world in average only 13% of the people were engaged to their jobs and 24% were actively disengaged. That's quite huge. Almost two times more people are disengaged than engaged.

In my interests there's of course the numbers of Finland. Here the numbers where 11% engaged and 14% disengaged. We were almost the worst in Western Europe, only France and Netherlands behind us. Maybe it tells a bit about our overall nature of being unhappy about almost everything, but still it's really worrying and we should do something about it.

I unfortunately don't have a list of "5 things that will improve your work place happiness" in my mind. There are lot of good articles about the subject existing and I recommend to read some of those to get the ideas. What I think is important is first to approve the fact that this actually matters. Happiness and engagement are important in productivity of the company. I believe these are not something that HR can do (at least not most of it), but this is something that operational leaders and other key people in organizations need to take under their radar.

Written by +Henri Hämäläinen

Estimates or #noestimates

Everyone working is Software industry have been involved in estimates in a way or another. Most of the people have known for ages that the one thing that's sure for estimates is that those are wrong. More complex the software or organization creating the software, more difficult it has been to estimate how long creating software takes.

There's been buzzing around for some time the #noestimates movement. The basics of it, as I understand, is that software teams should get rid of making estimates, since those do more harm than good. But I think there goes so much discussion under #noestimates, that I'm not fully sure what all it contains.

I've seen estimates to do lot of harm in many organizations. Estimates have caused poor quality, unhappy people and lot of unnecessary waste on creating those and reacting to those. But then on the other hand, I couldn't see organizations to live without any estimates on software.

Value of estimating versus the time used to it

Value of the estimates versus the time used on creating the estimates is one of the key questions on estimating. Too often estimating takes lot of time. People use hours or easily even days to figure out how much time creating some software takes.

I guess it's not valuable to discuss too much about what's wrong with estimating. People are known to be terrible at estimating. One excellent source to understand more is Nobel prize winner Daniel Kahneman's Thinking, Fast and Slow which introduces at least WYSIATI, anchoring effect and lots of other reasons we can't estimate. So I'm not going to use more time on arguing about the subject, but use is as a given fact that people are bad at estimating.

So what is the reason estimates still exist. Why estimates are still done, even though those are always thought to be wrong. I believe estimating goes to the same category as planning. As Eisenhower said: "Plans are worthless, but planning is everything", there's something similar with estimates. Estimates as such are not accurate, but the journey is valuable and some figures are always needed.

Sometimes the time spent doing the estimates doesn't match the value that estimates can give. Estimates should be used as a tools for decision making. Most often the decision is that should something be tried to do or not. The decision should be about the start, not about the completion. That's what Agile and iterative thinking should help on, there should come multiple decision making points and clarifications about the completion when knowledge increases during the development.

Companies can't live without estimates

Liked it or not, companies can't live without estimates. Most of the companies have limited resources in developing software (and everything else too). Those few who currently seem to have unlimited resources, still need to serve their customers quite often to keep their positions.

In real life, there are customer commitments and internal commitments that need to be handled somehow. Most of these are based on estimates, things that are most probably not accurate. Still those don't change the fact that sometimes these commitments need to be given. Think about yourself, would you be willing to purchase a house building project, if your contractor would say that we don't really know how much it will cost, when it will be ready and what it will contain. Of course you want to get an estimate, or even a fixed price with fixed timeline and features.

Many companies actually are in estimating business. They estimate the costs of development, they estimate their sales, they estimate the timelines and then take known risk with price and profit margin. This is how most of businesses still work. The luxury of making fixed profit is with fixed hour rate businesses. So basically some of consultants, lawyers and couple of others. There the risk is in not getting clients and not in making bad estimates.

Other than actual businesses relying on estimates, many companies have internal dependencies to SW development estimates. Product marketing for example, can't wait for product to be finished before marketing activities can start. They might need easily few months head start to get all the activities ready when product would be ready to ship. There easily are tens of these dependencies inside companies to the software team estimates: sales , marketing, documentation, hardware creation, operations, training, partners and so many others.

Software estimates, as much as software teams hate those, and as much those are wrong are mandatory part of all businesses. Those of you who still hesitate, think about Lean value stream map. For customer, software is just a small part of product. Even a plain software product. I can't even invent a software that wouldn't need other activities to go parallel to software creation to shorten the full cycle.

What's the solution then

Estimates are problematic. Sometimes estimates cause waste, sometimes lack of estimates cause waste. When sales uses SW development estimates as promises, those can create business, but at the same time those might cause quality issues, stress and unhappy people. So what could be done to estimating, when to do estimates and how.

I can reveal already now, that I'm not a believer of black or white solutions, so I don't think there is a one solution for all. But here's couple of thoughts how situation with estimating could be improved.

Estimated targets and predictions

One possible solution is to go towards having targets from early estimates and then predictions separately. At least when estimates are not in the team level, but in the project or feature level, it would be beneficial to have a target and then constantly update the predictions based on progress. Both of these figures should be always visible and that would give to everyone else idea what is the real situation.

In this approach there are many potential problems also. People tend to keep the first estimated targets as the goals and then predictions as a follow-up of the situation. This might give the feeling of failure, when the first estimates will most often be wrong. Still this approach should give everyone the idea, that decisions are made with something that will most probably be wrong.

Software aided and fact based estimating

As discussed, people are terrible at estimating. In a way it's easy to say that computers can't be worse. Saying this, I've never seen a good software that could do this properly. There are quite many variables that needs to be taken in to account to have a proper estimate. Still I believe that it would be possible to create framework that would give rough estimates of projects or features.

This framework should benefit from the historical data that has been stored to many software tools that has been used in the organizations. As an input, the framework would need to get software components that require changes. Then based on throughput times in past and historical progress of projects estimating software could give an idea how long something will take. Even thought these estimates would be quite rough ones, still it would give valuable data for human made estimating. And I believe it still would be closer to the truth than many other estimates. As said, unfortunately I haven't seen system like this yet in place. I would be surprised if there wouldn't be any software projects ongoing in this field. I just haven't bumped in to those yet.

It's ready when it's ready

There are few companies who have been good on preventing the harm what bad estimates have on markets. Apple is the prime example of this. I'm hundred percent sure, that even the guys in apple are bad at estimating. They concentrate on the product quality, so they can't guess when they are ready. They have taken the approach on telling when things are ready when those are ready. In Apple case it works for their benefit, but many other companies need to be able to have some timelines beforehand.

Still the approach it's ready when it's ready has something to learn from. It starts with understanding, that estimating software project length is difficult. When this is realized, then companies should build their activities based on this. Sales shouldn't be selling exact dates too early, handovers and dependencies between different teams should be minimized and people shouldn't be rewarded or punished because the estimates they have given.

Software, even the minimum viable product, won't be ready before it's ready. There isn't any amount of estimating activities before hand which can tell for sure when the ready will be. Activities in companies need to be able to react to each others timelines and not work with fixed timelines.

Summary

Estimating is a key aspect of business in software business (and basically in any other business). There are too many aspects and ideas to improve estimating for a one blog post. Some people believe in time boxed development, others think Minimum Viable Product will help and some believe tools will be the thing that will fix the issues. I don't believe there is one solution to fix it. I see the key thing to be that people start to understand that estimating is really hard and people are bad at it. Most businesses need estimates and can't live without those.

As a feedback to many of Agile and Lean discussion ongoing in different forums, I have to say that too many people forget the business behind software. It's so easy to talk about no estimates thinking, Agile practices or Lean values without understanding the effects of it to the businesses. Software is a key part of many businesses, but it won't make money without the other activities in the companies.

Everyone involved in the estimating processes should acknowledge what is the decision estimates are used for. Minimum Viable Estimate could be a good guidance for everyone. What is the minimum level of estimate we need to know in order to make the decision in hand. And as reminder to everyone, estimates don't get better with estimating, those get better with implementing.


Written by +Henri Hämäläinen

Peer training inside organizations can be very effective

In one organization I was working with, there was a desire to improve overall coding skills. The guys had used some external training sessions, but as most often those were in such a general level, that those didn't give much value to the environment they were working in. We started to think about solutions for the problem.

Team had couple of people who were thought to be gurus, who could easily train the others, but as always, the gurus were also the busiest guys in the organization. Creating a proper training takes lot of time and effort. Anyone who have ever created tailored training sessions, know that it takes at least 5-10 times more time to create the training than keeping it. If the training is for 2 hours, you easily need 10 hours of work on creating it.

So the answer didn't lay on the gurus. We also did have a look for external tailored training, but there wasn't much of a budget prepared for this. And also, the external trainers are never as effective as internal ones. So we decided to try peer training. We decided that everyone in the team needs to keep one session to everyone. At that point, we came up with an idea of taking few valued books of the subject and divided chapters from the book to be the subject areas people had to make their training sessions.

In addition there was created a good template for the training. Template made people to explain the basic theory from the book and then it was made mandatory to bring examples from their own production code as a reference learning for the training.

Exercise was successful. Of course people were hesitant in the beginning, but the feedback after the sessions was good. One of the best ways to learn is to teach. When you have to teach others, you have to know the subject much better than you will ever learn from any training sessions.

This example was from actual coding, but in can easily be taken in to use in different professions. I believe the ability to take learning from a valued book and consider and show the examples from organizations daily life is really beneficial. Experienced external trainers are excellent in keeping the atmosphere and proofing points, but they rarely know enough about the daily life to actually be able to make a change to stick.

I have experience in doing tailored training sessions. I've kept close to 50 sessions during change projects inside companies. Even though I normally know quite much about the companies, the challenges people have and the practicalities, still I've seen that my teachings are much more effective when there is internal experts backing me up.

I highly recommend this practice to all teams. I can guarantee it works. It might work differently than you think, but it will definitely make people to learn and find ways to improve.

Written by +Henri Hämäläinen

Agile State of Mind has been lost in the journey towards Agile

First statement in Agile manifesto is “Individuals and interactions over processes and tools”. When people talk about Agile SW development, much of the talk is about processes and tools. If they are not talking about Scrum or Kanban, then it’s about code reviews or Test Driven Development. Too often the basis for all of this is forgotten.

I think there has been a clear vision of all of this. Back in the years that this movement started, Agile Manifesto was written with careful thinking. Somehow the message got lost in the way. Currently there are so many different methodologies and processes, that have been introduced under the Agile umbrella, that what really is Agile is unclear.

In team sports, there’s always ongoing trends on playing tactics. In football, at the time Barcelona and Spain was dominating, many teams wanted to play like them. What often went wrong was that teams and especially the players didn’t seem to understand the ideology behind the tactics well enough. They were just mimicking the ways others play, but didn’t really understood the reasoning of why to play like that. This lead to the problem, that in a second that there came a problem which didn’t have ready made solution, players didn’t know how to act. This was all because they didn’t understand the reasoning why they had done some of the things in the field like they had.

I believe this same is happening with Agile. People are happy and productive when everything is going like the books have told. At the moment there comes something unexpected, people don’t understand the logic of making choices. Making choices in SW development is never easy. For example in Backlog creation, there needs to be done many guesses and estimates on items when prioritising it. Creating user story items or what ever we call them, is never exact science and always needs judgement from the person in charge.

Focus in many organizations should go towards how to successfully create SW products with Agile State of Mind. That’s at the end what SW development is all about, creating SW for customers. Being Agile in SW development means, that focus should be on creating more value to the customer with improved ways of working. Not just to improve the ways of working.

Written by +Henri Hämäläinen

Book Review: Implementing Beyond Budgeting by Bjarte Bogsnes

Budgeting has been a subject I've wondered for a long time. I do understand how budgeting works, but I've never really understood why it is there. Implementing Beyond Budgeting by Bjarte Bogsnes didn't explain to me why budgeting should be done, but it told, why it shouldn't be done.

This is essential book for any modern organization. Traditional budgeting will slowly fade away and there will come new ways to lead companies and handle costs. Bjarte says that he might be too hard on some aspects of traditional budgeting and make some things too black and white. I didn't really feel like so. I believe budgets make so much harm in organizations, that Bjarte could have been even more strict on the effects of those.

This book isn't a how to do Beyond Budgeting guide, but a story about the underlying principles and two journeys towards the ideology. Stories and ideas will give a good guidance how to start implementation, but there is definitely lot of thinking needed.

What I love in the book is that tells realistically about the change. Implementing change needs lots of discussions, persuasion and time. Creating a new process or guidelines doesn't really change anything. The mindset behind actions needs to change. Bjarte tells about two organizations that have been on this journey. He admits that other journey was still ongoing as the book was written. The change started many years before, but it was still continuing.

I highly recommend this book to everyone interested on improving the companies they are working at. This topic needs much more attention. There are some valid reasons behind budgets, but most of the reasons are just barriers for creating value to customers or constrains making people unhappy at work or pure waste. Changing traditional budgeting is important topic and this book was a good peek to the topic.

Written by +Henri Hämäläinen

Life as a Consultant - Hard part of letting the process to live the life on it's own

In the past years I've worked ans still work as Product Development Improvement Consultant. I've worked with interesting companies in past years. I've been given the privilege to work with them on finding better ways to organize teams and roles, plan the work better or improve the efficiency of daily work in product development or product delivery.

The one thing I hate is the moment of letting the process to live the life on it's own. As a consultant, there always comes the time to let go. In some cases, companies have let me be there to ensure that process actually gets up to speed as planned, but in some companies they've wanted to take the ownership right after the training's or pilot (or whatever the implementation method has been). In any case there always comes the time, that process or practice needs to be taken in-house and I must leave. That is the difficult time for me.

I admit, that I'm sort of a perfectionist. When I have a vision of how something should go, I do work hard to achieve the vision. As a consultant it's in one way easy to persuade people. It's easier to bring new ideas from outside than inside, but it's then much harder to actually get the people to accept and adopt the new ideas from an outsider than from insider. As an outsider, you need to sell the ideas to everyone and be always willing to discuss and adjust the idea to match the reality that people inside the company work with.

When you've done a long journey on persuading, discussing and inventing the new ways of working, there comes the time you need to let go. I almost feel like a parent at that point. You leave your child to walk on it's own. The benefit of being a parent, rather than a consultant, is that with your kids, they keep in touch and you see how your parenting went. As a consultant sometimes you don't see. In good cases you keep in touch and even come back to improve the things even further. But in some cases you don't work with them again, and you don't even hear how it actually went.

I think this problem isn't that unique. There's many people who work on short term contracts with specific topics. It would be nice to hear am I the only one with this kind of pain of abandonment. I don't really lose my sleep over this, but I admit I think about previous project quite often. Did it go well, are people happy, are the planned benefits happening. I'm wondering am I just strange or does other have these feelings too? This question is the reason I sometimes think, that maybe I would be better working in product development companies directly, rather than a consultant. I currently love my job, but I hate these goodbyes.


Written by +Henri Hämäläinen

Hiring new manager is not only solution when there is too many things to manage

In past years I've had the luxury to work with few companies growing from being small to becoming middle sized. It's been great to learn from them and also give something back to them.

One thing that have happened in all of these companies, is that there becomes too many things for certain person to control or manage. That's natural, when companies grow there comes more and more business or product related questions someone needs to solve.

The problematic question is that how to cope with that situation. Often the first solution that comes in mind is to hire a new person to handle the increased workload. Too often this is also the only solution companies know off and decide on hiring a person to handle that workload.

Recruiting in many ways is the most important factor affecting long term success of companies. Companies tend to hire too fast, incompetent people and to wrong roles. For some reason universally it seems to be easier to get the permission to hire more managers or other supporting persons than actually the people who do the value work. In the simplest possible setup, companies only need to have product development guys and sales. Everything else can be questioned.

There are other solutions to increased workload. The first solution to think, should always be, are all of the increased workload really valuable work. Could some of the work just be dropped as a waste. Every company has lot of waste work, meaning things that never have any affect to the end product or to the value customer gets or efficiency overall. Everyone knows in their heart, that they've done some waste work sometimes. Most will do some waste work every week.

Second solution for increased workload is sharing the responsibility. When one can't handle all the things they should, they should first think, how to make sure that all of the necessary things could happen without adding a new person to the group. With proper planning existing people can most often handle all of the necessary things in time. Sharing the responsibilities and giving a good direction most often helps. Most people are willing to take the extra responsibility when given a possibility.

I've never faced a company that would have too few middle management. I count Product Management, Marketing, HR and these kind functions to middle management. Few companies I've seen could have benefited from having some people working for internal tools and processes, but never from having more managers to manage business.

Of course companies need to hire new people when they are growing. Once in a while there is a true need for person to the middle layer. Companies just need to be really careful on hiring them. People in middle layer will come busy and can keep themselves busy. There is always more work than can be done. Key is to know when that work is actually valuable to the company and needs a new hire and when not.

Written by +Henri Hämäläinen

Book Review: Management 3.0 by Jurgen Appelo

Management 3.0: Leading Agile Developers, Developing Agile Leaders by Jurgen Appelo was one of the books that I've planned to read for a long time. The positive thing about reading it now and not earlier, is that I was much more ready to understand the book than I was few years ago.

Management 3.0 is an excellent book. Even though the name might promise a one more management model to learn, Jurgen Appelo tells that there isn't a model that would suit all. To be more precise, Jurgen tells that all models have their flaws. He does say that models are important, but we need to remember that all companies, products, people and environment are different in every case.

Jurgen does give his view on what is important in Management in the future. His model has six major themes, which start from energizing people and go all the way to improve everything. He goes all his themes through with very extensive walk-through of underlying knowledge on each of the areas. He explains things thoroughly, but still interestingly.

I really liked the book. It was excellent reading and widened my view of the importance of people in companies. It does discuss about many of the same issues that other Agile books, but it does add lot of new ideas to the discussion.

I recommend this book to managers in product development companies and others who are interested on how the whole companies should be organized. It's a great book and I promise you won't be disappointed.

Written by +Henri Hämäläinen

Book Review: The Fifth Discipline

This time I had in my reading list one of the business literature classics The Fifth Discipline: The Art & Practice of The Learning Organization by Peter Senge. It's a book that introduces systems thinking as we know it know.

Book is well written, but even more importantly the contents of it are really valuable. I had read about systems thinking before and I had been given so many recommendations about this book, that I had high hopes for the book. Luckily it matched my expectations.

The idea of the book is that organizations should become learning organizations to stay in business and have a good future. The book introduced a fresh way of seeing organizations as whole systems. It gives lot of value to personal development and human values ensuring that organizations learn to improve themselves in the long run.

Book introduces five disciplines of learning organization. Also it introduces eleven learning disabilities that prevents learning organizations to form. It has a lot good examples and it is easy to learn with this book.

I highly recommend this book to everyone working in organizations, small or big ones. So this would be a good book for almost anyone. It's a bit longish with over 400 pages. That's a pity, since it might scare few potential readers away from it.

It's great and important book. Many people have read it, but still only few organizations live to the values of the book. Learning needs understanding. Hopefully many more will read the book, understand the teachings and share the knowledge.

Written by +Henri Hämäläinen

Book Review: Agile Software Requirements

I did read this book a while ago, but I somehow had forgotten to review it. I recently took it from my bookshelf to check few things and decided to write a review about it.

First of all, I think the book title sucks. Dean Leffingwell's book is named Agile Software Requirements, but it is all about the Enterprise Agile model called Scaled Agile Framework (a.k.a. SAFe). I don't understand why that couldn't have been the title of the book also.

I have hands on experience about SAFe model, when it was invented (at least partly) at Nokia. I was heavily involved in taking it in to use in Multimedia area. I don't want to talk too much about SAFe model this time, I try to concentrate more on the book side. I have to say I'm not a huge fan of the SAFe model, but it does make many good points and definitely adds value to certain kind of organizations.

The book as such was a disappointment. It does have some good insights in many of the different chapters, but it is way too long. Everything about the book could have been said in around 200 pages. There is lot of repeating the same basic things in many different chapters.

Maybe it's just me getting bored, but I'm not sure if all Agile books need to repeat the how Scrum works and all the other basic things. I guess we could get over that part on the future books. I do realize those are easy to skip, but I don't easily skip chapters, because authors have wanted those to be there.

What I liked about the book was that it shows that software development affects to so many different parts of organization. There needs to be well planned mechanism to have proper amount of guidance to write the actual code.

For those who have no idea how to scale Agile software development to larger scale organizations, this might be a good book to read. It gives one view how scaling can be done, but it is too strict for my taste. I don't believe there to be one size fits all solution. I think I've heard Leffingwell to say the same thing, but the book forgets to tell about the other possibilities.

I'm not sure if I would actually recommend the book to anyone. Scaled Agile Framework is definitely worth of checking at, but you can get almost the same level understanding from the SAFe webpage. It didn't raise to be any of my favorite Agile books.

Written by +Henri Hämäläinen

Book Review: The Essential Deming: Leadership Principles from the Father of Quality

This time I got my hands on the book The Essential Deming: Leadership Principles from the Father of Quality. I have to admit that I wasn't really excited to read the book. Demings thoughts have been coming up from so many different directions, that I wanted to give him a shot. I'm glad I did, his thoughts were marvelous.

This book isn't really a book and neither it is written by Deming. This book is a collection of Demings writings, personal notes and speeches from throughout his career. It goes through all the main thought Deming was talking about in his books and his teachings. It tells those in a bit shorter format, but I think it was enough for me.

The book goes quite far back to 1950's and 1960's in telling what has been the problems with companies back then. Strangely the problems haven't really changed that much from those years. Of course many aspects have changed, but the underlying problems are the same. Also many of the solution proposals hopefully suit to current organizations as well.

I mark to books pages I will come back later for reference or future investigation. From the books I've read this might have had most markings done by me. There were quite a few good thoughts and sentences that will come handy in the future.

I have to admit that Demings thought were not totally strange to me. I've read those from multiple sources beforehand, but this was the first time I read his own words. That might have helped me a bit on understanding this book. It's not difficult book to read, but it needs some thinking to understand.

It was an excellent book and I enjoyed it. Even though it's old, thoughts are valid and valuable. This is a book which many if not all the the people who care about their organizations improvement should read.

Written by +Henri Hämäläinen

Separate Testing is Waste

Thinking very Lean, testing is waste. Testing takes time and doesn't bring any value to the customer. Most of the it only provides information, that product works as expected. Only time testing brings value to the customer is when errors are found.

Testing is seen as an important activity. There is lot of focus on improving testing and the coverage of testing. More and more people are working testing products and creating test cases. These activities, do improve the product quality a bit, but it isn't really a way forward.

Testing is a wide subject, and I'm talking especially on the cases were testing and product creation are seen as separate activities. There might even be separate test teams and separate product teams. Product teams do test to some extend, but the main responsibilities are given to test team. This is the big problem of testing. Separate testing should only be about knowing the risk level of releasing, not about increasing the product quality.

The aim should be to decrease the amount of testing and increasing the the product quality during the product creation. In the long run, the thing that matters is the product creation quality, not testing quality. Of course some of the product creation quality comes from testing, but this is not separate testing, but assuring the quality while creating something.

I don't believe any organization can get rid of testing. Some amount of testing is always necessary to know the risk level of releasing. Amount of testing needed should be analyzed thinking the costs and effects of fault in product release. In some businesses fault could mean bankrupt, in others, few annoyed customers. This analysis should tell the amount and scope of needed separate testing.

Testing and product creation should work together to ensure quality of the product. Organizations need to learn to build good quality products from the start. Every error should be analyzed and corrective actions should be made. Unfortunately this is utopia in most of the companies. Errors found in testing are seen as normal way to ensure quality. In the long run this will start hurting organizations and cause more and more errors.

The only way forward, is for management to start taking errors seriously. Especially having an eye on why the errors have been introduced in the first place, not why the errors were not caught in testing. Blame is often put to testing, even though it's an activity that shouldn't be done separately at all.

Written by +Henri Hämäläinen

Book Review: Sand Hill Road by Timo Ahopelto

Sand Hill Road by Timo Ahopelto isn't a type of a book I would easily select myself to be read. This book interested me due to the background story. Timo Ahopelto is one of the founders of CRF Health and this book follows loosely the history of first years of the company. The reason CRF Health interests me is that I've worked as consultant with them for more than a year. Some of the people of this partly fictive story still
work there. That said, my review of the book is bit biased since I know bit more about the company than regular reader will.

CRF Health was founded to solve the problem of using paper and pen to get information from patients during medical studies. Most of us have at some point answered some medical questionnaires in paper and this company has focused on using tablets and mobile phones for this data gathering. In this book there are many medical companies mentioned, but it doesn't go in to too much details of how the stuff technically works. This book tells more about the mental side of building a start-up.

Timo Ahopelto writes in quite living way and story goes forward really rapidly, almost too fast. Some times I found myself wondering what happened to this and that which was mentioned earlier in the book. There are few loose ends in the book, which I would have liked to get an answer at some point. Book is fun to read, but it mixes serious things with comical aspects so that I got bit lost about the idea behind the book. At first I thought it as teachful real life story, then bit as guide for new start-ups, also  at some point it takes a bit political viewpoint and at the end it turns more to the the fictive side.

I enjoyed all the sharp observations and opinions about start-ups and business life what Timo Ahopelto brings up in the book. Those small, one or two paragraph mentions, were really good additions to the book. I would like to read more of Timo Ahopelto's thought about business life and start-ups.

I recommend this book to at least all the Finns interested in different businesses and companies in Finland. It's hard to say what percentage of the book is fictional and how much of it is true. Still I believe it gives good view on what it might be to create successful company. It's an entertaining story, so it's easy and fun to read. It's a story of Finnish start-up success and that makes it important for so many.

P.S. I believe the book is currently only published in Finnish and I read it in Finnish.

Written by +Henri Hämäläinen

False security of documenting everything

People have this inbuilt instinct of keeping stuff in case those are needed later. In work life this is  seen so, that everything needs to be documented in order to use it later. In some companies this grows to be part of company culture. There are thousands of notes waiting for further use.

Documentation as such is not waste. There are many things that should be documented for later use. The hard part is selecting what is important. In many cases this selection is not done, but almost everything gets documented for further use. This starts to increase waste and eventually become a real burden to any organization.

This kind of company culture enables fire and forget mentality. It enable important issues to be set aside, because those are documented and will be handled later. This gives the false security that because I documented this important thing to the list of important things, it is not my responsibility anymore to take care of it.

This fire and forget mentality connected to high documentation culture creates environment where people get frustrated, start to blame the organization and even become bitter in the long run. As an example I've heard so many times, that someone proposed something to the documentation system and because no one took care of it, this problem now arrived. Even them saying something like the example, they don't understand the fallacy they have fell in to.

Organizations which rely less on documentation and more on individual responsibility, will actually get things done. Offering ways to move responsibility to documentation systems creates waste. It creates the false security of having things under control.

Written by +Henri Hämäläinen