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.

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.

Problems in Working Together

Maybe from my posts people can get a false idea that everything always goes as planned. Well, it sure isn't like that. In the following story there's plenty of lessons to learn and things to improve.

Two Teams

There were two teams working on a legacy product, let's call them team A and team B. (There were other teams too, but these teams are starring now.) Team A was working on the very core services and low level functions that other teams, including team B, depended on. Due to the fact that automated code coverage was not on very high level and the code base was really complex and not in mint condition, there were many times moments that things broke down even though all automated tests passed. And because team B was working on the application layer, they often found these problems. And they suffered.

Team A did mistakes. But they were always keen to correct their mistakes and open about development ideas. Approaching them was easy. You could walk into their team room and just state your business or ask for help. And they would help you out for sure.

The working model for the teams consisted of fixed deadlines. On a specific date things were to be done. Prior to this date was a so called stabilization/freezing period that was dedicated for bug fixing and testing that all parts of the complete system worked. One can imagine that closer to the deadline pressure was increasing.

During the stabilization period team B was blocked by some defects. They didn't proceed in testing because they didn't want to test same things again after the fixes would be completed. Unfortunately team B didn't make things easy. Usually they approached team A with JIRA issues. And we are talking about teams that handled plenty of issues a day, so prioritization and keeping track of all changes was a challenge. So sometimes it happened that the issues did not progress very rapidly.

At the time of deadline team A was done with their testing and didn't saw major blocking issues. Team B was about halfway done and still had issues open. And they were complaining that team A was blocking them. In the end both teams ran out of time and the common product was not releasable in time.

In Hindsight

Both teams made mistakes. One of the major ones was communication. In a small organization it should be more than ok to use the Adidas-method: walk to your colleague. Don't keep things in a desk drawer. Let the other person know about the problems in a timely fashion. Don't rely only on the tools.

Another major mistake is relying too much on automated tests if you have low coverage. I think it's a sure recipe for disaster. If your code coverage is 35 %, it means there's still almost two thirds of your code that needs to be tested manually. It is laborous, time consuming and demotivating, but it's a must if you don't want to give out buggy software.

In our setup cutting scope is possible. The rule of thumb is that schedule and quality are fixed, but scope flexes. This principle was not obeyed and the scope was not adjusted in time. And quality debt had been accumulated during development resulting in big amount of late bug finds.

Finally the whole fixed schedule model can be questioned. Is it the practice that creates most reliable and high quality software? Of course continuous attention to quality, vigorous testing and cutting the scope in time will make a big difference. But most of the time people are weak and things tend to take all the available time. I have started to lean more and more towards concentrating on getting things done and letting the schedule flex a bit.

Another text book answer would be that if something is difficult, you should do it more. If it's hard to keep three month deadlines, cut the time in half or even shorter. Then you will iterate more rapidly and get better faster. I'd like that too.

Importance of Environment in an Agile Transformation

I attended today a SAFe 4.0 event arranged by a Finnish training company called Nitor Delta. As a guest speaker they Michael Stump from the Scaled Agile Inc. The event was also a good meeting place for SAFe practitioners. I must say that I saw quite a few familiar faces. And met many new people who I can hopefully later exchange experiences with.

After writing a case study, my company has drawn a lot of attention from other (potential) SAFe adopters. I have a bit mixed feelings about it. Of course I'm happy and proud about the attention, but being a Finn, it's difficult to handle the situation. And then again, since I see all the daily difficulties we deal with, I sometimes feel tempted to say "..but we still face these difficulties". But maybe there's no need. I guess everyone understands that things are in reality much more complex than in theory.

From http://finnishnightmares.blogspot.fi

But from the conversations that I participated after Michael had finished his presentation I learned that environment matters a great deal in SAFe/Agile adoptions and transformations. First I was somewhat against the idea of training everyone at the beginning of the adoption process, but maybe my first impression fails me there. In some cases I think even training is not enough, but some people should get their brains totally rewired. I mean, if you have done something in the same way for decades (or even years), it could be overwhelming to modify your daily routines.

If I think about possible factors why the transformation was successful in our case, I could easily list at least a few. There was a big management support. Previous and current heads of R&D were supportive for the idea and also the Chief Quality Officer. I think also the CEO saw potential in the new practices.

We had already been trained in Scrum when the big organizational change was initiated. All developers had received training in Scrum essentials and every Scrum Master and Product Owner was certified. Scrum Master and tester Communities of Practice were also formed right at the start. So good practices had distribution channels.

Release Process was established even though at first we didn't plan the releases. But the decision to shorten the release cycle was made. Release Manager, a person who would facilitate the release planning and execution was also appointed right away.

Then I think a big deal of the change can be credited to a couple of champions. People who were in key roles (RTE, Owner of Software Development Process, Chief Portfolio Officer, line management of R&D) made big contributions. Having a vision of how things could be done was important, but just as important was the support from these champions. And finally the support and engagement of employees. Everyone wasn't eager to embrace the change at first, but enough many were.

During the conversations with other companies I have realized that there are other, more subtle things that supported the transformation. Some that I had never even thought of since they are rooted so deep in the culture and operations. The organization is not flat, but there are exceptionally good possibilities to access information, suggest new ideas and to participate in the decision making. Also the developers are treated as experts. And there's one company value that I hold in the highest respect: Enjoy Working Together.

In the development money is not an issue. I mean, there's no unlimited budget, but people in development get to fully concentrate on the contents. If something is considered worth doing and there's clear potential, it will be done. There's no sharing of the blanket between different business units. (I have never needed to worry about CapEx or OpEx.)

As a conclusion, I think there were quite a few things that made the transformation possible. Some are such that people living inside the system do not even perceive. In a way I'd be tempted to say they don't realize how lucky they are. So let me conclude my post with a few pictures.

Office Breakfast

Foosball table

Hackathon trophy

Lean Oven Beets

I wanted to make some oven beets (beetroots) for lunch. The process for making those was simple and I wanted to make it as lean as possible.

Raw material was a bag of beetroots, about 30 pieces. It will represent the supplier. Then there are two necessary working phases which add value to the customer. The beetroots need to be first peeled. Then they must be sliced into bits. Finally they go into the pan.

Process Flowchart.

The production plant could be set up in different ways. But in order to eliminate waste, everything should preferably be close to avoid unnecessary motion and transportation. With only two work phases there's not many places for inventories, but one possible place would be between peeling and slicing. If you first peel all the beetroots, you need to keep them somewhere before the slicing. But if you work in a one piece flow, you don't need any extra storage between the phases. Then there's also no over production, because one beetroot is always enough to enter the next work phase.

My factory had only one employee who needed to task switch between the phases. There was also some need to move. With two employees this could have been avoided. But unfortunately recruitment for housework is sometimes really hard.

Factory setup: Sink, Work Phase 1, Work Phase 2, Pan.

Keep things tidy and in order. When the equipment is on their places they are easy to find. Keeping your gear in good condition (knives sharp) makes your process more efficient. With tools fit for purpose, like my peeling knife, you can not fail. You can cut off just the skin and no valuable beetroot is lost. In lean this mistake-proofing is referred as Poka-yoke.

Proper peeling knife. Poka-yoke.

Fortunately the supplier had provided me with so good material that there were no defects. Quality control happened visually before the peeling phase.

Because the employees were both trained in continuous improvement and empowered to make changes to the plant layout, they came up with a slight process improvement after the first half of the work. The need for movement was decreased by moving the pan closer to the slicing place.

Factory layout mark 2: More compact.

When the materials ran out, the plant was simply shutdown. No capital was left in inventories. In the end, the customer received a pan full of sliced beetroots. As she had ordered.

After shutdown and clean-up.

In the text above I have tried to identify different types of waste and write them with italics. One could argue this wasn't a process, but a project. If the work would have continued, there would have been a need for a proper disposal of beetroot peelings. They were simply piled and thrown to garbage after the work was completed. But how to do this properly in a continuous process is left for the reader as homework . ;)

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!

On a Ride with Heroes (or Bad Apples)

I went back to work today and read two interesting articles. First one was about "bad apples" in teams. Probably quite many are familiar with these people. At least I can admit that I have seen these.

It is very odd that when the company is going through a challenging period of moving from old way of working into a more Agile way, some of the most senior people see as their divine right to protest. In the past these people have been the heroes of the company: solving the impossible problems at the last minute, making that needed fix in no time and knowing almost everything about their domain.

Somehow these company's finest become anti-heroes. They start to undermine the Agile adoption process by not sharing information with their team members. We often call these people "cowboys". And because of their superior knowledge (especially when dealing with complex legacy software), just showing door to these people is not the option that management is eager to take.

In my opinion, the option the company is left with is to motivate these individuals. Try to see what makes them tick and show them how Agile can work for them. And maybe pipe down about the process talk and concentrate on how they can maintain their status as experts also when working together with a team. But it is not easy for the team. That I can assure you.

The second article was about Ericsson adopting agile. It is always soothing to see others have some similar challenges and we are not alone with our problems.