Walking Through a Process

I've recently started working part-time as an internal tutor in my organization. I could best characterize the tutor pool as having internal (agile) coaches available for different continuous improvement activities. Main focus is on process improvement and facilitation.

I think the tools and techniques are quite sophisticated. If you are familiar with Lean, you probably know the fishbone and 5 times why. This time me and my colleague facilitated a process walkthrough using the OPERA technique. We scheduled a three hour time slot for the event.

Fishbone

As we are both really new tutors, we went through the exercise before with our mentors. The person responsible for the development of the particular process was also involved in the preparations. The ultimate goal was to update the whole process. But for our session at hand we set our goal on better understanding the current status.

My colleague had done a very good script for the session with timings. We started with a short introduction (15 minutes). The participants also listed their expectations for the meeting. All the expectations were surprisingly well aligned: more understanding about the current status.

In OPERA technique people first write down their own ideas (O) on post-its. Everyone was instructed to write 3-5 things that currently work and similarly topics that could be improved. For this we gave them 10 minutes.

Time-Timer

Next, the participants paired up (P) and discussed their ideas with their pair. For this we gave them 15 minutes. If you visualize the passage of time, people can self manage their timing and you don't need to hurry them. If you can get your hands to a Time-Timer, that's great, but if you don't have one available, you can use for example Online Stopwatch. The countdown works well and you have an alarm in the end.

After the pair work, we collected the ideas on the whiteboard and the pairs explained (E) their findings to the others. For this phase we had reserved 35 minutes. In addition to positive findings and improvement topics we also had a category for ideas.

After collecting the ideas on board we discussed possible themes that could be identified. In 'by the book' OPERA we would have had ranking (R) and arrangement and actions (A), but in our case we pretty much skipped those.

Opera, not OPERA

From the results we crafted a sort of hypothesis for what the current status was. To test this hypothesis, we needed to go check things in practice. In Lean, you would use the principle Genchi Genbutsu or do a Gemba walk. In our case we will examine the current status by interviewing the process actors.

We had done a lot of ground work with the interview questions, so this part didn't take long. But if you start from scratch, be prepared to spend considerable amount of time on this. With a predefined set of questions you get better data can identify patterns from the answers.

The interviews will take a lot of time, but during the meeting we decided who were going to be interviewed and the team split into pairs. Scheduling the interviews were left as an action point and we only agreed on the deadline date. We will have another workshop session when the interviews are done and we can look at the results together.

Photo by Artur Rutkowski on Unsplash

SAFe Evolution

I have been involved with SAFe for about five years now. We first started by taking inspiration from Dean Leffingwell's Scaling Software Agility book. Then we bumped into the SAFe big picture. I think it was something like version 2.1 back then. There were still HIP-iterations in the end (H stood for hardening) and the model was talking about Potentially Shippable Increments and Releases.

SAFe 2.5, Leffingwell LLC

Originally I fell in love with the simplicity of having on one level sprints and on another über-sprints. We were building new releases of our product a few times a year and wanted to speed up. Also, we were having quality issues due to scope extensions and schedule slippage. Our story has been presented in this case study.

Version 3.0 made it more clear that we don't have a separate value stream for architecture and business. I guess it was also due to popular demand that the hardening was dropped from the end of the release period. I still think it was quite realistic and would be for an enterprise that is new to agile. Things don't become fully automated over night. I became certified SAFe Agilist during the 3.0 version.

SAFe 3.0, Scaled Agile Inc

I had mixed feelings about version 4.0. I was really happy to see the Customer in the big picture for the first time, but adding yet another layer (Value Stream level) seemed like too much. That was probably mainly due to the fact that I weren't involved in such activities where so many layers would have been needed. In a way, I think it would be possible to add even more of these levels. After all, we are talking about scaling.

SAFe 4.0 was very handy when you hid the Value Stream level. Of course you need to make decisions based on economics in all cases and you want to apply agile architecture, but you can do it even if you don't have it in the big picture. Communities of Practice were also a welcome addition. You probably want to have some support groups for people who serve in similar roles. That's how you can benefit more from organizational level learning. During the 4.0 era I got certified as SAFe Program Consultant (SPC4.0).

SAFe 4.0, Scaled Agile Inc.

As with previous changes and additions, the new version SAFe 4.5 brings both welcome additions and things that seem to be added mainly because they are current hype. The ability to customize your big picture: Essential, Portfolio, Large Solution or Full SAFe is really good thing. I bet many companies can do with Essential or Portfolio SAFe. But it's a good thing that the more complex versions are available too.

SAFe 4.5, Scaled Agile Inc.

Then what I don't really like (this is my personal opinion), is the fact that SAFe is getting more bloated. I think in the core things are about scaling, cadence and transparency. The power triangle that makes a distinction between content, process and technical quality authority (PO, SM & Team or PM RTE & Architect). I see no need to add DevOps practices, Lean UX nor Lean Startup practices here. They are fine practices that I appreciate and use. But for example in teaching Leading SAFe course, they make things more complicated. Also, due to the fact that the slides covering those aspects don't really include much of instructor notes, I kind of feel those topics are still in an early phase.

Special rant from many of my trainees: THERE ARE WAY TOO MANY ABBREVIATIONS! MMF, WSJF, CoP, FAB, RTE, STE, CoD, CALMR, MTTR, WIP, CI, CD, CE, BUFD, MBSE, KPI, ROI (...maybe you get the point). Some of these are industry standards, but if you bump into these for the first time during your Leading SAFe class, you have quite a mouthful.

As an end note, I feel SAFe 4.5 is great, but there should be a clear separation between the core practices (regardless of configuration) and such additional practices that simply underline that SAFe is a collection of different IT industry best practices. Which it clearly is.

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