Value Stream Mapping SIPOC

I was this week in a workshop where we were introduced to a nice set of lean tools. 5 x why, fishbone and kano model were visited briefly, but most of the time we concentrated on value stream mapping. To share the knowledge I will tell you about it in more detail.

We used SIPOC model. The abbreviation comes from the words

• Suppliers
• Inputs
• Process
• Outputs
• Customer

In this example we were creating a breakfast toast for one of our family members. So customers in this case were husband/wife or child.

Outputs can differ if the different customers (or customer segments) have different needs. In our case the child wanted a toast with jam and special attention that the toast isn't burnt. Spouse wanted a cheese sandwich and all the facilities need to be cleaned. No crumbs.

Inputs are all the things we need in the beginning. In the toast example we need a plate, knife, jam, cheese, butter, bread (two different types) and heat.

All the inputs have a supplier. In this case we were thinking where in our kitchen they are located. Not really who made the knife. But the knife is in drawer, butter and jam in the fridge. Heat is provided by the toaster and plate in the cupboard.

Finally, when these pretty evident things are covered we can start to think about the process. WHAT activities are needed in order to create the desired outcomes? We first make a line of post-it notes that define the activities. We can label the different activities with different colors. In our case we used green for processing, yellow for transportation, blue for storage and red for inspection.

Each WHAT phase is broken down into HOW parts. For example toasting phase can be broken down into activities of setting the temperature, putting the bread into the toaster, setting the toaster on and the bread being heated.

We used heart shaped post-its to mark all the value adding phases. In any process there are activities that add value, activities that are necessary but not value adding and thirdly activities that are waste. By identifying these we can measure how much of our activities actually are value adding compared to the whole time used. This performance indicator is known as Value Added Ratio (VAR) or Process Cycle Efficiency (PCE).

PCE = Customer Value added time / Process Cycle Time

As in our example the spouse explicitly wanted to have no crumbs, we tracked all the parts where crumbs could be produced. These phases were connected with a string. This way we can only concentrate on improving those parts to minimize the amount of crumbs.

Finally it makes sense to identify your customer touchpoints. You can goof off in many parts (well, better not to too much..) but you should make sure that you handle the customer touchpoints with care. Think about what happens before, during and after the touchpoint. How does the customer feel?

There you go. A crash course to value stream mapping using SIPOC method. If you want to learn more, I encourage you to find a lean consultant or simply try it out. I know I will.

Leadership

A person starts to lead when she takes responsibility of something greater than just herself. Before this, she needs to learn to lead herself. This means she needs to take responsibility and make a decision to sit on the drivers seat. It is quite easy to blame someone else when something goes wrong. It takes courage to admit that I had the choice, I made the decision and it turned out to be wrong. But it's a necessary step towards leadership.

Leader should be vulnerable. Admit your mistakes. Say you are sorry. Ask other professionals for guidance and be willing to change your opinion when you see better facts and hear better arguments.

Don't try to be something you are not. Even if you have a few rough edges it might be better to show them than act. People can see through facades. But if you are rude, it still might be wise to polish your manners.

Empathy is a core leadership skill. But even empathy can be learned. Think about how your actions affect others. Or, better yet, ask them! And listen to the answers.

One dilemma in leadership is that many believe in leading by example. I do so too. But in expert organization that isn't usually a choice. The people in your team are better in their craft than you. So another leadership style kicks in: stay back and let other people shine. Support them. Clear obstacles from their path. And boost their confidence by telling them how much you respect them.

Inhale blame, exhale credit to others.

I'll open this up. You are the leader. You take the blame. Period. It doesn't really matter what happened, it can be discussed later (and should be analyzed with maybe 5xWhy?), but right there in the moment when shit hits the fan you take the blame. No excuses. Then, when the dust settles, you stop for a while with your team and have a retrospective. You learn and you try to make sure the same doesn't happen again.

And the credit part. When something great is achieved it is usually a group effort. Leaders many times get to represent others in events, but when positive feedback is given, make sure you remember that it is for the team. Thank them. Thank them in public. And celebrate the successes in private too. Raise toasts or have a bun together. (bun intended)

All pictures from Gratisography.

Resilience

I was recently in a one day refresher training about coaching leadership. About one and a half years ago the original training was longer, couple of months. It included lots of assignments and pair learning with my supervisor colleagues. The training was organized in house and participants came from different departments of my company. Actually, this was one the most powerful takeaways from the training: I got to meet and network with people who work in very different environments. But we all have something in common: leading people is our day job.

Our everyday realities differ. It's diffrerent being in sales or in the frontlines of customer service than in the R&D or doing software development project work. But in the end, for leader the goal is same: your job is to help your team members succeed.

Photo by jesse orrico on Unsplash

The training was implemented in such a way that there were numerous pair and group conversations. One topic was resilience, the ability to overcome a disruption (for example an organizational change). With a quick poll it seemed that almost all participants thought that they were very resilient. They were able to work under stressful conditions and stay sharp. Afterwards I began to think that

Is high resilience a precondition for a successful leader?

But which way does the causality work? Was it a precondition or had these people become more resilient after being in the management position? Maybe worth researching a bit more.

At least it would be a benefit. That in today's stormy waters (of corporate life) you can stay calm. But it's not only about you. Since even if you can get over things quickly, others might take longer. And if you forget this, you may move too fast.

• Give your people time to adapt. 
• Offer them opportunities to discuss and reflect. 
• And use your gift of keeping your head clear to help others.

Photo by Dane Deaner on Unsplash

Developers - Cost or Asset?

When things get big enough there might be functional silos that concentrate on specific activity. These could classically be something like sales, development, support and marketing. Of course these functions should be made as efficient as possible taking into account the whole. Customer value is usually built in co-operation between all the functions, not by a single unit.

Metrics can be a double-edged sword, if they are applied to functions instead of taking into account the whole value chain. Sales funnel is quite easy to quantify. You have numerable amount of possible clients. You can count how many units you can sell to this market, thus getting the absolute limit value for your cash inflow. It's easy to measure how much a single sales person or sales unit can close deals and bring in money.

If you sell development hours, it's also quite easy to measure how much a developer generates turnover or how big the billing rate is.

In typical cases salaries are even easier. There's usually a fixed sum of money that is paid to the person monthly. This is the cost of a developer (plus hardware & licenses too).

But it’s much more difficult to quantify the financial benefit of an in-house developer who works in R & D. One could make a rough estimate about how much an equivalent consultant would cost. But this doesn’t take into account the subtle knowledge that is accumulated over time or the internal relations. Possibly this person is the glue that keeps the team together, the humorist that keeps people in high spirits or the oil that lubricates the internal cogs and makes things happen. Not impossible, but difficult to quantify.

Without visibility and understanding, one can draw wrong conclusions about the situation. Classic would be rewarding sales department for bringing in the money and cutting costs in operations by sacking people.

 

"What should I do then?"

To remedy the silo problem and optimizing parts in expense of the whole, you should concentrate on metrics that measure the whole value chain and are difficult to gamble. Some examples:

• NPS. How the customer experienced your service?
• Lead time. How long it took your organization to meet the customer’s need?
• Profitability. Do not concentrate on (just) how much sales you make. Pay attention to how much it costs for you to develop, deliver and market the product/service.  

 

 Photos by "My Life Through A Lens", Spenser H, Fabian Grohs and Mike Wilson on Unsplash.

Employee Turnover and How To Avoid It

In the current market situation, software development professionals are the ultimate scarse resource. I'm not exaggerating if I say that these people, for example talented architects or data scientist, don't need to look for positions. They are being actively approached by headhunters and hiring managers.

They are neither easily replaceable, like cogs in a machine. Usually they possess knowledge that has been accumulated over a long period of time. Into some extent this information is useful in other environments, but it's most valuable in the current setup. That is why the existing employee is most valuable to their current company.

The cost of employee turnover

Losing a member from a well welded team has a significant cost that can be divided into (at least) the following parts:

1. Team loses a member and thus his/her direct contribution.
2. Team needs to reorganize and learn to function without the lost member.
3. Recruitment takes time away from development.
4. When the new team member is found, he/she needs to be oriented and inducted.
5. Team needs to reorganize again to function with the new member.

Sadly, I feel that many times people only think about the first bullet. And maybe if there's been difficult recruitments, also the third one. But all of these have a cost.

For the above mentioned reasons companies should do all possible efforts to keep their employees happy. I understand this is not possible for all company roles and it might be viewed as unfair. But it's really as simple as the law of demand and supply. With the rise of banks and other companies digitizing their services the demand is bigger than ever. (Almost) all companies are becoming software companies. And there's rather limited supply of software engineers.

Few tips on how to keep your employees

Compensation is one parameter in the puzzle. It should be on a decent level, but it isn't everything. Benefits that either have monetary value or make the life easier also count. I think the latter ones are more effective in retaining employees. Generally people are lazy (at least I am). Autonomy in choosing your own tools and ways of working increases happiness. If your work has a higher purpose or meaning to the society, it's a plus. For people who work with their brains, right amount of challenge is expected. And finally, you should be able learn new things.

There's a cost for keeping your employees, but usually it's smaller than losing them.