Designing an Organization

In software development there's a common phrase that you should employ the best people, treat them well and get out of their way. What is many times forgotten is the fact that even the best people need direction.

If I think about a company/department/any organizational unit, I'd like to know what is its goal. (One could maybe also call it a Vision.) What is it trying to achieve? What is the purpose for having such unit? It's not mandatory, but beneficial, if the purpose for existence is noble or somehow larger than an individual.

Once you have found your purpose, share it with everyone. Talk about it continuously. Make it clear for all who are involved. Next, think about what matters would be needed to pursue the shared vision. What kind of organization would be most capable? What roles should different people take?

Then staff the organization. For each person, make it clear what is their purpose. How do they help in reaching the common goal? Do it in a transparent way so that others will also understand. Now you can let the magic happen. If you are in an expert organization, each person should know best what they should do. Or at least better than their bosses.

And don't think you're done. You will never be. Even if you don't like it, the world around you changes. You will need to adjust your goal. And your organization. Rinse and repeat.

Team Agility

I'm not really much of a manager. Probably a slightly better coach, but mostly I'm a leader. I can give people direction and help them find the path. I don't like to tell them exactly what steps to take, just where I want them to end up. And when possible, I can walk in front of them or with them depending on the situation.

But I have a problem when I don't know where we should be going. Usually the company Vision and Strategy give guidance. But when the strategy work is still ongoing, one needs to make do without one.

In uncertain conditions it might be good to go to basics, identify the 'axioms'. When there are many unknowns, what can you rely on?

What can you rely on?

What me and my team decided to do was to improve our own group work. We are a loose group of people who work in the customer front in different roles. We are also guiding the work of others as project managers and team leaders. If we can work together seamlessly, it benefits the whole unit.

We decided to work more in pairs and coach each other. Some wanted to expand their profiles, some wanted to still concentrate more on their current role. We also decided to invite each other to our retrospectives and to arrange sessions specifically for sharing knowledge. Then we decided to change our work planning meetings (that had previously concentrated on resourcing) to sessions that combine resourcing, ongoing projects and new sales cases to get a better visibility to where we are and where we are going.

Add visibility. Prepare for changes.

These changes will increase staff liquidity, our visibility and our ability to respond to changes (which I call agility). Regardless of what the new strategy will be, these changes will help to implement it.

This post originally appeared in my LinkedIn profile. Feel free to check it out too.

Lean Morning Routines

This post was inspired by dear wife. She called me lazy. Partially that's true, but I prefer to think that I pick my battles. One of the things that I'm really efficient in is my morning routines. After I wake up I make the bed, wash my teeth and other bathroom stuff, eat breakfast, walk the dog and then commute to work for about 30 km using public transportation. Guess how long all this takes?

Well it takes 1h 10 minutes from the alarm bell ring to the point I hit the office. This including ~30 minutes travelling time using train and tram. For the routines at home I use 25 minutes. This is a result of quite a few kaizen activities standardizing. Let's next look at the timeline.

Timeline

5:35: alarm bell rings (my phone). I hate all kinds of snoozing functions. I simply get up and make the bed. Bedroom is in the second floor so I walk down as silently as possible (other members of the family are hopefully still fast asleep at this time.)

5:38: I dress. I usually leave my clothes on a kitchen chair in the evening so they are waiting for me. Then I prepare the oatmeal. It's simply flakes plus water and cooked in the microwave oven for 3 minutes. Usually I've set the oven to 5 minutes and I stop it before it says bling! (And wakes up the kids.)

5:41: While the oatmeal is cooking, I go to toilet and do some standard activities I'm not going to share here except that I wash my teeth and put on some deodorant. Then I go back to kitchen to take the plate out of the oven. Then I pour myself a glass of milk and usually put some sugar on top of the oatmeal. The glass and spoon have standard locations. :)

5:50: After I'm done eating, I put the plate to the kitchen sink. A bit depending on what kind of workday my wife has, I either feed the dog or she will do it later in the morning.

5:55: I go to vestibule and put on my clothes. Jacket, shoes, gloves, cap and scarf are waiting on their places the same way my other clothes were. After I've dressed, I put my dog on the leash and head out. We don't usually go very far. She has learned to do her chores rather efficiently too.

6:00: Time to hit the road! I walk down the hill to the railwaystation. It's maybe about 700 meters. Then I wait for the train.

6:10: Train leaves to Pasila, Helsinki. It takes about 19 minutes. Usually I read during the trip.

6:30: Getting out of the train in Pasila. Walking to the tram stop. This is frustrating part, because the station is currently one big construction yard and I need to circle a long way although the shortest distance normally would be only tens of meters.

6:33: Tram to Kaarlenkatu. The trip takes about 9 minutes.

6:45: At the office. Time to get some coffee and get to work!

Some remarks

• I usually wear really simple clothes. I don't wear suit to office. My standard outfit includes t-shirt, college and jeans.
• I've got rather short hair and I don't use any gel, wax or other stuff. I don't spend too much time in front of the mirror. (Don't know if that's good or bad.)
• Just like in any lean factory, there are standard places for all the things and nothing extra. Also, I like to keep the house clean. The kids can have a mess in their rooms, but the common areas are in neat order.
• Oatmeal isn't ambrosia, but it's healthy. :)
• As much as possible, I try to avoid extra movement. I've planned my route in such a way I don't have to return to rooms too much. Shortest possible path where possible.
• I'm not in a hurry. If I were, I would wake a bit earlier. Actually I could squeeze out maybe 5 more minutes, but I like the "slow morning". :)

Defining and Documenting Processes

I have previously been a process owner. I've improved existing processes via different tools and techniques. Audited practices and interviewed actors, even chopped down the activities to a value stream map. But never before (that I can recall) have I been involved in the definition of a process.

In this case the actual process exists (people do actions in a certain order and with a desired outcome in mind), but it isn't documented. There are neither no metrics defined to see if the process is working fine or not.

To be honest, there is documentation. The problem is that there is too much documentation and it's scattered around different places in the intranet. So, in this case I'd be willing to abandon the old documents, try to extract the current process through interviews and workshops and write it down as simply as possible. Fortunately there are very nice tools available in the parent company that can be utilized.

Some general tips to avoid pitfalls (that seem rather common):

1. Keep things simple. Don't go too much into details.
2. Integrity. You don't want to have 18 different ways to describe a process flow.
3. Visulization is power. Figures clarify the message.
4. Somebody should have ownership of the documentation. That will help keep it alive.

 The list isn't exhaustive. But it will get you started.

New Agile Framework

I have been involved in agile software development for quite a few years now, and for the last couple in various process oriented roles. So, I was really excited when I was involved in defining a new agile methodology. The first thought was that why do we reinvent the wheel? Why not simply use Scrum, SAFe or something else? But, taken into account the environment (which I'll soon explain), it could be feasible to come up with a new one.

In this case we are not simply working in a product development organization. Many times the job sizes are so small that they don't require a full team. And by far not big enough to use Scaled Agile Framework. There are multiple smaller customers and work includes both development of new solutions and maintaining old systems. Very complex setup.

Dealing with multiple customers in different software development lifecycle stages is a very complex problem.

Some basic principles that were not to be negotiated:

• Teams. There needs to be some basic unit to share the work with.
• Autonomy & self-organization. The teams need to be able to organize their work. And the developers decide HOW things are built.
• Ownership. Teams need to own their results. This is why a large amount of craftsmanship is needed.
• Transparency. Everything should be open. In my experience transparency always improves quality.
• Backlog management. There should be one person who has authority over the job queue. The same person will represent the voice of the customer.
• Continuous Improvement. Teams need to examine their working methods regularly. Measurement enables feedback and thus learning.

In practice there are two types of teams. Some handle the larger customers. Mostly one team can serve a couple of bigger clients. This way they can have internal job rotation (which is refreshing) and still there's continuity in the customer relationship. And even if there's a slower period with some customer, the team can focus more on the other. The knowledge is kept alive and there's flexibility to answer variance in demand.

The team members will learn to know each other and work together. Increasing the level of trust will enable better working methods and slowly but steadily one plus one will become more than two. Restrospectives will help the team learn.

For the smaller customers and new gigs there's a special team. In a way the work with bigger customers is easier and you can have more junior colleagues learning the ropes from the seniors. But when there is a vast number of customers in maintenance mode, you can only cope with seasoned professionals. And you need to maintain a decent level in documentation. When the panic strikes, there's no time to start looking for instructions. You need to have clear plans and a solid map to navigate the environment.

All in all, although SAFe was developed for big and complex environments, I feel the problem with only one production and mostly one product is much easier to crack than the one I'm currently dealing with. And that's why it's so interesting!

SAFe deals with a relatively simple problem: one product.

One concrete challenge when you introduce something new is the unlearning of old ways. Many times people are biased, even if they don't perceive it themselves. And of course it's tempting to accuse the new framework about all surfaced problems. But recovery can only begin after admitting the facts.

By the way, I have written another blog post about this new framework in Elisa Hub (unfortunately only in Finnish). Feel free to check it out too.

More Lean Cooking

In the series of daily life inspired posts, I return to one of my favorite subjects: cookery. This time I was making some vegetable casserole. I needed to peel and shred some carrots and I fell into the age old trap: big batch size.

As you can see, I had in advance decided to use more than six carrots. While I was peeling them, I was aware that I should have peeled end shredded them one by one, in a one piece flow. But against my own good, I peeled and cut the heads off from six in a row. I was convincing myself that it was more efficient (although I was creating extra inventory).

After peeling the six carrots I finally started to shred them. Only to find out that by cutting the head off I had made the work more cumbersome. And now the fault was multiplied six times. If I'd done a proof of concept (gotten one carrot through the whole pipeline), I would have only had one faulty carrot. Fail fast!

I faced another problem later. I would have been well off with only three or four carrots. But since I had already peeled six, there was no turning back. Now my costs were bigger than they needed to be, I could have saved some veggies for the next time.

The same phenomenon is easily found in software development if you use kanban board without proper WIP (work in progress/process) limits. It's easy to pile up too much work that is waiting for testing or merging to the main branch. The flow is far from optimal, but perceiving the problem is far more difficult due to the fact that the material is less tangible, in most cases information.

The final result was quite edible despite the faulty process. :)

Lean Berry Picking

In Finland we have a rather nice concept called freedom to roam (jokamiehenoikeudet). It grants a big bunch of different rights that you can utilize while wandering in the nature. For example you can camp or pick berries or mushrooms (excluding backyards, gardens etc.) My next story is just about that: picking blueberries.

There are two main ways to pick the berries: by hand or with a berry-picking rake. Picking with a rake is by far faster than handpicking. But there are other aspects to consider. Blueberries are soft. The rake will break at least some of the berries. Also, they will be accompanied with a lot of extra leaves and other rubbish. That's why the method will require you to clean the berries.

From lean & quality point of view there are a few problems. First, you will need to have extra storage space. You need to keep the clean and dirty berries in different containers. And the batch size is really big. All the dirty and clean berries need their own space. Second, you will need to move the berries. In lean methodology this is considered waste. In reality, all the extra touching will also make the berries sticky from their own juice.

With handpicking you can pick straight to the final container. You don't need any extra space and there's no extra movement. This also means that the berries will stay in better shape. As a downside, your hands will get blue.

But as in any other things, you should think about your priorities. Largely it's quality versus time. If you are not in a hurry, I'd suggest handpicking. You will achieve a one piece flow. From the forest ground straight to a freezer ready form. But if you are trespassing on someone's backyard and want to get away fast, just use the rake a flee before someone will shoot you. You can then live to clean the berries at home. ;)

One should also note that this isn't as black and white with other berries. For example cowberries do not get as sticky even when you use a rake. And most of the time you don't get as many rubbish either. So there the quality is almost the same with both methods, rake is superior in speed.

Lean thinking is an interesting (and many times rewarding) thought experiment and can be applied also in ordinary life.