Implementing Communities of Practice - In Practice

Lately I've been suffering from a writer's block, because I stumble to the fact that I've already written about the topic I have in mind. I've already written about Communities of Practice too, but now I have a different angle.

I'm currently working as a People Manager in a big finnish software & telco company. Title doesn't probably tell much, but in practice it means that I'm an administrative supervisor for ~30 persons. My closest colleague has a team of about same size, but we are strongly trying to operate as one big team with two supervisors. And to do it so that every person in our teams could discuss with either one of us and things would simply work.

At the same time I want to underline that we are serving the people, not the other way. In our field it's the experts who create all the customer value. They are the rockstars or boxing champs. We are the coaches and managers who make sure they can concentrate on where they excel.

But this is just the foundation. My duty is making sure we have the right staff and that there aren't any major impediments. I don't really manage the daily work, that guidance comes from the self-managing agile teams.

Our teams each serve a few customers. That enables us to get the benefit from working together for long enough to reach high performing state, and on the other hand, enough flexibility and variance so the work doesn't get boring. Teams are headed by a Technical Product Owner who handles the team's backlog.

With our team based organization structure alone we carry a big risk of slipping into silos. Self-managing and self-organizing teams are great, but really big benefits materialize when we can learn from each other. This is why we need the communities of practice (or in short CoP).

Before we reorganized ourselves into the current form, I headed the Technical Product Owner team. We had a community of practice. And I'm really proud to see they still have one even after I stopped facilitating the meetings. As a side note, it's a perfect way to acid test your coaching results. What happens when you're not around? If everything halts, you should maybe look into the mirror.

We have also other CoPs. One for designers, one for testers, one for architects and so on. Most of these communities are headed by a Technical Lead. These people are our most superb technical experts who are tasked with the goal of making our people competitive in the long run. They coach and mentor others in their technical field. It's actually a great opportunity for a younger professionals to grow.

And actually some of these communities extend beyond our unit boundaries. Our company has thousands of employees and our unit has sister units in other divisions. With similar organization structures we have been able to extend the sharing of knowledge. This work is largely unfinished, but already for example the designers have weekly meetings together and testing is coordinated across the whole company. Personally I'd like to grow our Agile Community, but without concrete shared projects it's difficult to find the common ground. But maybe we arrange some event together and see where it goes.

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