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

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.

Customer Value Through Lean, part 1

I haven't blogged in a while so let's do some blogging! I recently saw the below image in Twitter:

I'm not (yet) familiar with William Glasser's work, but I'm willing to believe this. Maybe that's actually one reason why I write this blog: to learn. So, let me try to teach you something about Lean. And this is somewhat personal and subjective lesson, not a result of sound scientific research. Hopefully the facts are close to reality. If you find an error, consider dropping me a comment.

Origins

Lean has it's origins in Japanese car manufacturing. Specifically Toyota had developed a very well performing production system which later become well known as Toyota Production System (TPS) and people from different countries have tried to copy. But it is not as simple as taking the separate practices and rolling them out in your environment. It's the whole package. (You might want to check The Machine that Changed the World by Womack et al.)

Some essential topics in Lean are Continuous Improvement, maximizing the flow of value and respecting people. (I'm not anymore sure about what is Lean, what is Kanban, Scrum or just good way of doing things. I've read too much about processes and methods and my mind has started making it's own synthesis...)

Wastes, Support work and Value Adding work

Many people who aren't that familiar with Lean, are at least familiar with eliminating waste. Waste can be characterized as everything in your chain of actions (value chain) that the customer is not willing to pay for. This includes waiting, unnecessary movement, time spent for finding things, defects, producing too much of something, over processing and inventory. Also I like the idea of adding underutilized employee talent to this list.

Minimizing the inventories is also closely connected to the notion of a pull system. Let's say you have three baskets. From the third one you sell products to your customers. The two first ones represent some work stages where you add value to the end product. If you want to minimize your inventories, you can wait until customer buys something from the third basket. This creates a vacant spot in the basket. At the same time it triggers you to finalize one piece of work from the second basket and move it to the third. While you do this, there will be a vacant spot now in the second basket which you can fill.

You would probably also want to aim for a one piece flow. Large patches are usually typical source of waste, because you have too much money tied in your inventory and you might end up producing things your customer doesn't want.

But the main thing is not really about eliminating waste. It's also about identifying which parts of the value chain are value adding. And with value adding I mean things that add value from the customer's point of view. Observed separately from your internal point of view they even appear as waste. Good rule of thumb is something that the customer is willing to pay for.

Third category of work is the mandatory non-value adding work. These are things that do not really add value, but are necessary. Many support functions like bookkeeping go into this category. You cannot totally squeeze them out, but you should try to minimize the amount of time spent on them.

Processes

Another key Lean principle are well defined processes and accompanying metrics. If you can't measure it, you don't understand it. You get what you measure. You can't improve if you don't know where you currently stand. There are quite many phrases about measuring, but I guess there must be something behind them.

Once the processes are defined, you can start improving them. In Lean jargon this is called kaizen. Radical changes have a different term, kaikaku. Big organizational changes definitely are kaikaku rather than kaizen. In software development if you are applying Scrum or Kanban practices, you probably already have working practices for continuous improvement. For teams the events are Retrospectives. In my own role as Release Train Engineer I hold retrospectives that span beyond team levels.

Usually processes will always have a bottleneck somewhere. This means a limiting value for the flow of value. And when you remove it (with some awesome kaizen practices), the bottleneck will be somewhere else. But you will never get perfect. You can always improve.


I need to get back to this subject later. There's much more. Slack, queue theory, WIP etc. Really interesting...

Practice Makes Perfect - Release Planning Day 3

It's an amazing feeling to notice that something you have deeply invested in has started to become routine. Not for you, but for the organization. I had the pleasure of experiencing that today.

We had our third Release Planning Day. I've told more in detail about the previous two times in my earlier posts. This time the agenda was pretty much the same as on the previous try. Day began with a look at our markets and business. I like to see how things are connected. It's easier to justify your daily work when you can fit it into the big picture. What ever actions we might take should in my opinion bring us closer to our Vision. The message was delivered by our Chief Portfolio Officer. (SAFe model suggests getting some high ranking executive to signal the importance of the meeting. I think we've already seen the usefulness of Release Planning but it doesn't hurt to have powerful people involved.)

Then our five Product Managers presented their updated Product Roadmaps. Most of the contents in the Roadmaps were pretty much the same as last time. This makes sense since the Roadmaps should cover long term development needs and shouldn't maybe live as much as the Backlogs. There were some comments which I hope spawned even more lively conversations after the meeting.
One impressive moment was when I realized that we have around thirty people sitting in Helsinki and the PM presenting his Roadmap from Asia over Lync. And you really could not tell much difference from a case that the person would have been there live. Except for the fact that one couldn't see him. :)

After the Roadmaps I gave brief instructions on what I expected us to achieve during the rest of the day. Then people simply disappeared. Almost before I had even finished talking. But that was good. They knew what to do and were determined to do it.

During the Team Breakout session I wandered around our premises. That was the second time a slight smile suddenly appeared on my face. There were groups of people here and there discussing the coming Release. Exactly those necessary conversations that need to take place! What should we do? Why should we do it? How should we do it?

Later in the afternoon we gathered back to the meeting premises and went through the Draft Plans. Each team had come up with a list of topics they will start to work on in the next Release period. Already many cross-team issues were identified and the plans were well in line with the Product Roadmaps.

Tomorrow we will go through the finalized plans. I'm not anticipating any big changes so we will probably just go through the main changes compared to the draft phase. But all in all, everything has worked so far just as well as one Release Train Engineer could possibly hope. But of course next time will be even better. Continuous improvement!

Knitting Processes Together

Interfacing is hard. Even if you take a simple example, (well, maybe not really that simple) a software development team and think about how the information flows from the original customer requirement to an implemented feature. Here I'm assuming that there is one Scrum Team developing one product.

First there is an interface between the customer and the Product Owner. The Product Owner interprets the requirements and maybe writes them down as a User Story in the Backlog. Then the Development Team starts working with the requirements and refine them with the Product Owner's assistance. Finally they implement a new piece of functionality. Something that is hopefully close to what the customer originally wanted.

Probably many have experienced cases where everything didn't go according to the customer's plans. Product or service did not meet the expectations. Fortunately this earlier mentioned development process can be improved by collaborating and working closely with the customer. But still, things tend to get a bit harder when you scale.

Depending on how you (or some others) choose to shape your organization, you might have a set of small start-ups where every team can do pretty much everything. But quite often your operations are modelled by separating different functions and processes. And I don't think it's always bad. I'm not really that into accounting, so I prefer someone else doing that for me. Or even thought I like interacting with customers, I'm perfectly fine with someone else closing the deals and me just providing some cool new functionality.

In addition to the different functional roles, there are processes applied in these functions. And these processes interact. In sales function there's the sales process and in R&D the software development process. One of the most common pitfalls in process oriented companies are the interfaces.

Even if you apply the idea of Continuous Improvement, you are usually just optimizing one process. And even if you have a state-of-the-art software development machinery it makes no difference if you cannot get the products to customers. Or if your sales or marketing cannot find your customers and make them aware of your superb new products.

The approach I have recently been involved with is the so called Value Chains. Instead of concentrating only on the individual processes, you take a helicopter view and think about the whole chain of actions from customer need to customer satisfaction. And then examine closely also the interfaces between the processes.

Of course this approach requires a healthy amount of collaboration between the functions. And maybe someone to pay attention to the whole. Quite often we tend to just stay in our little silos and see everyone outside as, well, outsiders. But get past that! Go to lunch with your buddies at sales or go have a cup of coffee with some people working in customer service. Or if you don't know anyone there yet, go and make some new friends!