Zsolt Fabók

Context and Perspective is Everything

2013-05-14T00:00:00+02:00

Have a look at that shape. Take your time, there is no need to hurry. Which side of that shape is in the front? Is it the one which top left corner is the as the top left corner of the shape? Or, is it the one, which bottom right corner is the same as the bottom right corner of the shape?

Did you move your head to see the shape from a different perspective so that you can see the different sides? Did it work? Do you have a more suitable answer now than a minute before? Most probably not, but here is an interesting idea: what if I tell you that the shape is not a cube.

You were thinking about a cube, weren’t you? But it can be a two dimensional shape with lines, triangles, rectangles and other shapes. I didn’t tell you that it was a cube.

That simple shape - I’ll call it a shape, because we don’t know whether it is a cube or not - teaches us an important lesson about context and perspective, how important they are, and how bad we are at interpreting them. They fill in the gap between appearance and meaning.

The brain is a complex, but efficient organ. It must be efficient, because our life can depend on the speed of the decision making, and we’d rather make a fast, but wrong decision than a slow, but right. It is the basics of the survival. Or, was for a long time, but nowadays the situation is different: we need to slow down and be effective, and not just efficient.

So, when you were reading the first paragraph for the first time, in order to be efficient you - or more precisely your brain - used a well known context, in which a shape like that was always a cube. Therefore it was a cube. The questions about the sides justified your belief about the “cubeness”, the only thing you failed to accomplished is to answer the questions about the sides. The idea that is it not a cube at all, changed this context and now you most probably looked at the picture differently. You needed an external help to see the problem in a different context.

The changing in perspective didn’t happen automatically either. Without bringing up the sides the shape was an ordinary cube that orientation didn’t matter at all. But after the side related questions, it became the most important thing about the cube.

If you think about the picture, it doesn’t matter whether it is a shape, a cube or a sheep drawn by a very avant-garde artist, because it is just a picture. However, when you see something on the street or at the workplace and you decide to act the context and perspective does matter. Simply because you’ll act and the result depends on the amount of information you have.

Here is an example. Let’s say that I have to solve a problem at my job, and the fastest way to do it, is to ask for help from a senior co-worker. She says no, and I’m about to escalate the situation to my boss, because I want my problem to be solved and I don’t take no for an answer. Is there something missing from this story? Do I know anything about the context and perspective? Not really. What if the senior co-worker has something more important to do? I didn’t ask her about it. I just assumed that she is there to answer my questions - wrong context. Did I try to understand her point of view? Not really - unknown perspective. Practically, I don’t know anything, and yet I’m about to escalate to the boss, because I want my problem solved, but most probably I’m making a huge mistake.

Not everything is as simple as the shape that started this article, but the principle it teaches us is general: context and perspective matters. We should slow down and learn as much as possible about the context, and see things from different perspective, because at the first look, the appearance and meaning may differ.

About Flows and Infinite Queues

2013-04-30T00:00:00+02:00

An infinite queue is a column on the Kanban board somewhere between the Queue and Live columns, one that doesn’t have a WIP limit and into which one can put many work items as one wants. A column without a WIP limit sounds like a bad practice, because if there is no WIP limit what will ensure that the work items are moving - being pulled - forward? Nothing really, so having infinite queues may not be a good idea after all. However, there are situations when we need them, because they have an important purpose: they connect flows. It was said before that an infinite queue cuts the flow into two pieces, but I argue that it connects the two pieces rather than cuts them.

Wait a minute. Until now in the previous kanban related posts, I have been talking about the flow (singular), and now I’m talking about flows (plural). What has changed? Nothing has changed, but until now, I’ve been talking about the flow on the meta level - it was easier, don’t hold it against me -, however that meta flow may consist of other sub-flows. It is not ideal, but this is how it is in the real world. One goal of the Kanban method is to find these sub-flows, merge them, and then optimize the whole by using incremental and evolutionary change.

It is easy to find the contact point of two flows. The first contact point is where the work items are handed over. Do you remember the times when the developers had to hand over the features to the test team so that they could do the testing? Of course you do. In this case we were talking about the development flow and the test flow. We don’t talk about handovers between developers and testers any more, but this doesn’t mean that we don’t have this phenomenon: we still hand over work between departments within an organisation. The problem is that the work items tend to disappear during these handovers. Actually, they don’t disappear, they end up in a hidden inventory, which is actually an invisible infinite queue. In this case, the first step is to make that queue (inventory) visible.

The second contact point is where the expectations are changing. For example, most of the teams I know are expected to deliver features continuously, but the customers or release managers expect the deliveries to happen on demand or periodically. In this case we are talking about the development flow and deployment flow. This setup is common in the software domain, for example one can observe the same phenomenon between design and development. In both cases the queue is visible, which is good, but the problem of how the work items are getting out it is still unsolved.

The ultimate and best solution is to introduce the WIP limit, because it makes sure that the work items are moving forward (it is not that simple, but good enough for now). However, it is a large step (kaikaku) and we believe in small continuous - evolutionary - steps (kaizen). One can ask “why is the WIP limit a large step in the context of infinite queues?” Before answering the question, let me share a story with you. Quite recently, we had a WIP limit of 2 on our deploy column, but our process didn’t allow us to deploy continuously, so we had to wait until it was allowed. Because of the WIP limit the work stopped after several days, which we couldn’t afford, so we increased the WIP limit. We could increase the WIP limit every day until the date of the deploy, so having it became pointless, and eventually we removed it from the column completely. Our deploy column became a visible infinite queue. The mistake we made was that we applied a WIP limit on a flow that we didn’t fully understand and wasn’t under our control. The conclusion here is that one cannot control (set a WIP limit on) something that one doesn’t understand and has no control over. Answering the question above: understanding and controlling the flow is clearly not a small step, therefore we cannot use it in this context.

We know so far that an infinite queue doesn’t have a WIP limit, so it is not clear what is actually going to happen to the work items in there and how they are getting out. If the flows have different owners, the absence of the WIP limit is not a big problem: the work must come from somewhere so the people working with the next flow pull from it. The work flows, but there is some uncertainty concerning relevance, importance and effectiveness. On the other hand, when the two flows have the same owner, the work can actually stop. It is a counter-intuitive statement, but think about it. Developers love to develop code, and they feed the work items into the limitless infinite queue of deployment, but they don’t bother emptying it, so the work items are staying in a “ready to deploy” state until somebody tells them to do the deployment and empty the queue.

If the WIP limit isn’t the best choice to get work items out of the infinite queue, what is? For example, we can use the 4th practice of the Kanban method: make process policies explicit. If you think about it, it can solve both situations from above. It is more effective to set a policy than a hard limit. Let’s say that the policy states that the queue must be inspected once a month or emptied every two weeks. Sure, these policies are less strict, but in contrast to the WIP limit, they are achievable, and more importantly, they can be improved step by step. Don’t forget that we are in the context of infinite queues - at the connection point of two different flows -, and we have to understand this context step by step (kaizen over kaikaku). So, for example, now we empty the deploy column every two weeks, and when we know more about the process, we’ll improve it, and we’ll use a one week policy.

This is exactly what we did with our deploy column if you still remember the example from above. We have a date instead of the WIP limit and we empty the column (the infinite queue) on the specified day (see the image above). We agreed that next time we’d have a closer date and when we have full understanding and control over the two flows (development and deployment) we’d re-introduce the WIP limit, and that time it would work properly. As you can see the infinite queue is actually helping us understand our process and get control over our flow. And that feels good.

Public Speaking Events in Spring

2013-03-31T00:00:00+01:00

I’m going to speak at two conferences this spring: on the 10th and 11st of April at ACCU 2013 and on the 15th of April at ACE! 2013. At ACCU, I’m going to talk about how to narrow down what to test and how to measure and manage flow:

I’ve already given these talks at various conferences like Agile Cambridge 2012 (video on infoq), Software Passion Summit 2012, Lean Agile Scotland 2012 (video on vimeo), and Lean Kanban France 2012, but as always I’m preparing an updated version of these talks.

At ACE!, I’m given a new talk about social sicenses and the difference one can make by applying them at the workplace. Until I’m finished with the screenplay and slides of the talk, here is the abstact:

The pure intention of this talk is to introduce interesting phenomena and fascinating experiments from the social sciences to the audience. These experiments have been around for a while, but we rarely apply their findings in our life. The talk won’t just explain a phenomenon like the “Learned Helplessness” or an experiment like the “Hawthorne experiment”, but will show how to use its findings for your benefit.

Being aware of the state of our minds and our environment is very important not only for Agile teams, but for any team. Let’s say that you have made up your mind about what you are going to do and are about to execute your plan. There may be several courses of action for you to take at this point, and in my experience the best way is to examine the situation, look for social science studies that match the problem at hand, pick one, and carefully apply its recommendations. The more studies and experiments you know the better your chances are to pick the right one, and make a positive difference.

I’ve also got accepted to XP2013, but the organisers have offered some unexpected and unusal speaker deal that made me considering to revoke my proposals. But this topic is still under discussion, so there is a chance that I’ll be there.

See you there!

The Empty Else Block

2013-03-27T00:00:00+01:00

I was adding a new functionality to one of my applications when I realised that I wrote this piece of code:

if condition1 && condition2
  # do what is necessary
  # ...
  # ...
else
  # I don't if when this will happen and what to do
  #
  # send me a mail anyway
end

I had no idea if that else block was going to be executed, and if yes, how often, or what to do if it happened. So I left it empty and let the application send me an email in case it is reached. If the number of emails is starting to be annoying, I’ll figure out what to do with it. This is something real options and validated learning from lean startup taught me.

Real options suggests not to commit to anything until I don’t have all the relevant information and I actually have to commit to do something. If I don’t know what shall be in that else block, I won’t put anything there. However, I have to know if that else block covers an (important) use case. So I had to learn somehow if the users wanted to use that block. This approach comes from lean startup. It’s been days since the application has been running and I only received a single email. It seems that I have to start thinking about that block, because a use case has been executed which I don’t fully understand at the moment. Nevertheless I’m happy, because instead of releasing something I have no idea about, I’ve learned that it is used, and now I have to figure out how exactly.

The Optimal Batch Size

2013-03-24T00:00:00+01:00

If you have read the coin game post (in case you haven’t, click here, read it - it is a quick and good read by the way -, and come back), you may wonder why the batch size of 6 produced the shortest completion time in the example game. Let’s find out. If we have a look at the flow of the game, we can find two major components: turning over the coins and moving them around (transfer). If you think about it, the time the players need to turn over all the coins is almost the same in each round. This action is so simple and we get so used to it that improving it during the game - in the given time frame - is nearly impossible. So, it is safe to state that the time spent on this component is constant during the game. However, if it is the case that the group finishes one round in 1 minute and 10 seconds, and another in 1 minute and 40 seconds, the variable must be the other component, which is the transfer time. It seems that there is a connection between the batch size and the time we need to move the batches around. Fortunately, Donald G. Reinertsen can explain this connection, and show us why the batch size of 6 produced the shortest transfer time and not 1 or 50.

He explains this phenomenon in his book The Principles of Product Development Flow with the U-Curve, but before getting into that, let me go back to the analysis of the turnover time and transfer time components for a while. If you have a bit closer look at the flow of the game, you’ll see three important things, not just two: the time required to turn over the coins, the time required to move the coins (both unturned and overturned), and the time a coin needs to go through all the players (lead time). I’ve already talked about the turnover part, so let’s focus on the other two. Similarly to the turnover action, I don’t see if one can improve the moving action significantly during the game. It is a simple straightforward thing: pick up the coins, push them or pull them. That is it. However, the batch size determines how often one should perform this action and that is not constant at all. The effort of picking and moving the coins multiplied by the frequency gives the transaction cost that actually depends on the size of the batch.

The last thing is the lead time. It has two parts: a turnover part and a waiting part. Let’s say that a player is turning over one coin and has one coin waiting. A coin is said to be waiting when the player is in possession that coin, but is turning over other coins. The wait can happen after the turnover or before depending on the group’s strategy (pull or push). The longer the waiting time, the longer the lead time. The connection between the size of the batch and the waiting time is linear: for a batch size of 10 the next batch has to wait 10 times as long as the time a player needs to turn over a coin. For a batch size of 5, it is only 5 times as long. This waiting has a certain cost to the group - longer overall completion time - , and it is called inventory or holding cost.

Don Reinertsen’s genius was to realize that there was a connection between the transaction and holding costs. Have a look at the diagram on the right. You can see how the transaction cost changes by the size of the batch. The more items I transfer at once the lower the overall transaction cost is. On the other hand, the more items I have in a batch the larger my inventories are, which increases the holding cost. The optimal batch size is at the minimum of the aggregation of transformation and holding costs. The aggregated values form a kind of U-shape, hence the name: U-Curve optimisation.

Here is an example: let’s say I’m using wood for heating my house. If I buy all the wood at once for the whole heating season, my transaction cost will be low, because I have to pay the cost of the fuel and time only once, but I’ll need a place where I can store that huge amount of wood. So I have to build and maintain a storage shed, therefore the holding cost will be high. On the other hand, if I’m taking as much wood as I can use - let’s say - in two days, the holding costs are going to be low, but the transaction costs manifested in fuel and time are going be high. In order to reduce cost I have to find the optimal batch size. There is an important lesson here: the smallest batch size is not always the best batch size. We tend to forget about the transaction and holding costs, but it can hurt our business.

Let’s get back to the coin game. Unfortunately, I don’t recall all the details about the example game, and therefore I’m unable to show you how to calculate the optimal batch size for that particular game, but here is another example:

The calculation is not that straightforward in software development, but remember: the group that played the coin came had no idea about the optimal batch size concept, and still managed to find it by experimenting. Nevertheless, the idea that the transformation and holding costs can help you find the optimal batch size is extremely helpful. For example: the smaller the batches, the more frequently you have to run your test cases, but you have to do less merging: high transaction cost, low holding cost. While increasing the batch size the test running time decreases, but the merge time increases. The task is given: find the batch size that produces the optimal test running and merging times.

The Coin Game

2013-03-15T00:00:00+01:00

Today’s post is about the Coin Game. It is a repetitive group game in which the players have to move a heap of coins from one part of the table to another by passing the coins to each other. Additionally, when a player receives a coin, she has to turn it over once. The aim of the game is to have the coins lay heads up after the last player has finished. Each round starts with a quick discussion about the group’s strategy: how many coins can be passed at once (batching), how many coins can be at a player at a time (WIP and inventory handling), and whether the players give the coins to the next player (push system), or the next player has to take it (pull system). They measure the time they need to move the coins and the game ends when the group finds the best strategy which leads to the shortest completion time. This game is really great to highlight the benefits of the pull system and to allow participants to practice the deliberate and data based batch size setting and inventory handling.

The game starts with the setup: the players sit or stand around a table and lay a certain amount of coins on the table to the right side of one of the players. Some of the coins lay heads up, others tails up. The game goes clockwise: the coins arrive at a player from her right and leave at her left side. The newly arrived coins are at the right side, the middle is the working area where the player turns over the coins, and the left side is where the overturned coins are kept. These are the inventories of a player. If the group is using a push strategy, the player puts the overturned coins into the right inventory of the next player, in case of a pull strategy, the player takes the coins from the left inventory of the previous player. All the coins in an inventory should face the same direction. If this is not the case, the player must throw back the coins to the right inventory of the previous player.

The role of the first player is special. The coins in her right inventory aren’t facing the same direction, so she won’t turn over each coin, however she should figure out which direction the coins should face in her left inventory so that they will face heads up in the left inventory of the last player.

We played the coin game at the first event of the Budapest Lean and Kanban Meetup (now limitedwipsociety.hu). The first round started rather quickly and the group decided to move all the pieces together. Their lead time was 2 minutes and 40 seconds. The group wasn’t satisfied with this result and had a long discussion about what went wrong. They learned that while one station was very busy - especially the last one - the rest of the group was idle, and that put too much pressure (mura) on that specific station, and errors were made: not all the coins were flipped and they had to be moved back. So they realised that they needed a different batch size.

The conclusion was a bit surprising, because most of the groups would have chosen 1 as the batch size, but this group chose 2. The result spoke for itself: 1 minute and 26 seconds. The group got more engaged in the game, and started experimenting with different batch sizes. The next candidate was 6 (unfortunately I don’t recall why). With this setting the lead time was a surprising 1 minute and 10 seconds. It was interesting that a larger batch size actually decreased the lead time. One of the group members argued that the batch size had less effect on the lead time. According to him, the group learned how to play the game and gained more experience, and that was the reason of the shorter lead time.

In order to validate his hypothesis, the team did another two rounds with the same batch size of 6 and with a batch size of 1. In the first case the lead time was almost the same as in the previous round - 1 minute and 11 seconds -, however, with a batch size of 1 it was 1 minute and 40 seconds. The hypothesis had been refuted: regardless of the batch size more experience should have decreased the lead time which didn’t happen. That member accepted the fact that the batch size matters more than the experience. It seems that data can really change opinions.

I can only recommend this game, because it is fast and it teaches the basics of the Kanban method: the pull system, the batch and inventory handling, and improving the flow with continuous improvements and experiments. You can see from the example above that a round was quite quick and the discussion about the next strategy was never longer than 5 minutes. Of course the game is an excellent opportunity to learn how to handle WIP limits and inventories. If you would like to do that, just add a constraint to the game: the size of the batch must be 1. Happy gaming!

When Will It Be Done?

2013-02-28T00:00:00+01:00

I recently had to have my watch repaired. I brought it to the watch shop where it turned out that it could not be fixed, because a main part needed to be completely replaced, but they didn’t have any spare parts. The lady behind the counter told me that she had no idea how much time it would take to get it. It could be one week, two weeks, one month or even two months. She told me that she would give me a call when it was there. I got upset: how hard could it be to know the time they needed to bring something from A to B? Most probably they had ordered something similar before. I didn’t want to make a scene, so I let it go and asked her to order the spare part.

After one and a half months, she finally called me, and when I was in the shop, the watchmaker told me that he would need 20 minutes to change the broken part with the ordered one. I was happier than the last time I was there, but he told me his estimation rather promptly and it was too accurate, so I got suspicious. I was watching him the whole time - so he couldn’t cheat -, and he did it in 19 minutes, so it was a good estimate. How was he able to do this? I didn’t know, so I asked him. He said that he had done this kind of task before, he had known all the possible problems, and in the worst case scenario he would have needed about 20 minutes. That’s something I’ve seen before. This is exactly what we do with our lead time distribution diagrams. So there are people out there outside of my domain using the same technique effectively - without the fancy tools we like to use.

I brought up this story, because last week I read Morgan Ahlström’s post titled Why my estimates don’t matter, where he concluded:

…So if predictability is what you’re looking for, don’t invest much in your estimates, instead you should make sure that your capacity is known and that quality (internal as well as external) is well understood. And that’s why your estimates don’t really matter.

If one is a service provider that might be true, but in most cases we work for somebody else, and that person, who is on the other side of the flow, wants to know when the work will be done. If I don’t or cannot tell her, I won’t get the job. She is not interested in my capacity planning or internal issues, she is not interested in half results or iterations, she wants to know when I can deliver the whole package. So people (like myself in the watch shop) want to know when they can get what they asked for, regardless of the reason why they need to know it. Therefore we cannot just stop doing estimations, because we think that they don’t matter. It matters to somebody, and it is part of the job to provide them accurately.

I assume that Morgan meant guessing instead of estimation. If this assumption is true, then he is right. What doesn’t matter is the guessing work that we tend to do under the name of estimation, because it is inaccurate. The watchmaker from my story didn’t guess. He used his current knowledge and his past experience to give me a rather accurate estimation.

There can be several explanations why we’re guessing instead of using our past experiences. Most of the cases, the “past experiences” simply don’t exist. Nobody collects them properly - or at all -, therefore people try to remember them, but unfortunately they all remember differently. After a long discussion they can find something that they remember similarly, but it seems so small, irrelevant, or useless that the guessing seems to be a better alternative.

So, if we collect data about the past, we’ll be able to provide better estimations. The best way I know to do this starts with the creation of the lead time distribution diagram:

The diagram above shows the number of finished work items (the height of the bars) with their lead times. The rightmost lead time is the best estimate for your upcoming work items based on the “past experiences”. Based on the diagram above, you can decide to go with 2 days lead time, because in most of the cases the work has been done in 2 days. However, the evidence shows that there were work items with longer lead times, so taking 2 has higher risk in being late than the rightmost 16. So if you don’t want to be late, it is wise to give that time as an estimation or prediction. Sometimes that time seems unrealistic so you’d rather pick the second from the right. Before doing this, consider that this kind of data has an expiration date. The more you learn about a domain and about the technology, the less time you’ll need to finish. So instead of taking the second column from the right, filter out the old data from your diagram and take the rightmost column.

Filtering can also be applied when you are looking for the lead time for a specific kind of work item. If you know that the work item is similar to a group of already finished work items, you don’t have to work with a global distribution diagram. Simply filter out everything else and you’ll see the lead time distribution for that specific group:

The planning meetings with my previous team took only minutes, because we were looking for these specific groups. When a new work item arrived at the horizon, we figured out which group it belonged to, and took the lead time distribution diagram of that group and picked the rightmost lead time. In order to keep our predictions accurate, in every two weeks we filtered out the old data. There was no guessing, no lengthy and exhausting planning meetings. It was highly efficient. If you want to learn more about our approach, have a look at the talk I gave at Lean Agile Scotland in 2012.

Be Aware of the Three Columns

2013-02-26T00:00:00+01:00

You most probably have seen the simplest Kanban board with three columns: New, Ongoing and Done. This setup is great for learning most of the basics of the Kanban method. I overheard someone saying that this setup was also great for teams to start their transformation using the Kanban method. Personally, I see this approach as a mistake. Although I believe that “learning on the job” is one of the best ways to learn more about a domain, I see the Kanban board as an exception.

Contrary to the popular belief, the Kanban board is for identifying areas of improvement and not for reporting status. In this context, the three columns can tell you only two things: the amount of work remaining, and the amount of work the team is doing at the moment. The first one holds some information, but the second doesn’t, so if you would like to know more - for example where the hidden inventories are -, you’ll eventually break down the Ongoing column into more columns, but by then you’ll have wasted a lot of time with the three columns and didn’t learn too much about the Kanban method, or your process.

There are two ways to figure out what kind of columns your organisation needs. The first one starts with value stream mapping in order to have a proper understanding of the flow:

The image above shows the result of the value stream mapping, and how it is turned into columns. Using those columns will show you precisely where your problems are, there is no need for further breakdown. By using this method you’ll also know more about your process. Not like with the three columns.

The second way puts emphasis on the wanted position. When you draw your columns you don’t care much about where you are, but where you want to be. For example, you want to introduce testing in your organisation: you add a Testing column to your Kanban board to the place where you want it to be, and try to figure out a way to get your work items there. The risk here is quite obvious: you must be 100% sure about your wanted position. Otherwise, you are wasting money, time and resources. However, if you are sure, the change and learning happen faster than with the first approach.

When you are about to use only the three mentioned columns - and you are not about to start with Personal Kanban -, I’m asking you to stop and consider my arguments from above. The whole point of the Kanban method is to improve your process and in order to do so you have to know it from the beginning. The three columns don’t provide too much information about it. They are excellent for learning, something like the training wheels on a bicycle. They are important to learn how to ride a bicycle, but no one enters the traffic with them, because it is hard and unsafe to use them there. Think about it and share your view in the comment section.

Parkinson's Law of Triviality

2013-01-25T00:00:00+01:00

The famous Juan Manuel Fangio had a very good year in 1957, because he won the Formula One Championship, which was his 5th win - the 4th in a row -, and with the age of 46 he became the oldest world champion. This is really impressive, however, 1957 was also the year when C. Northcote Parkinson, a British naval historian wrote a masterpiece about how organizations in his age were operating. In his book, Parkinson’s Law, he caricatures bureaucracy and how decisions were made in the public sector at that time. It is one of the best books I’ve ever read, but it is also one of the books that scares me the most. After 56 years, most of the chapters still apply, suggesting that there is really nothing new under the sun.

There is one particular chapter that became very famous and has been referenced since: High Finance, or the Point of Vanishing Interest. If this doesn’t ring a bell, maybe Parkinson’s law of triviality, or the bicycle shed discussion does. Nevertheless, the law states that “the time spent on any item of the agenda will be in inverse proportion to the sum involved”. Wait a minute! Does this “Law” really state that it is easier to decide what kind of flat to buy, than to decide which carpet will look the best there? Actually, it does, and here comes the explanation.

The scene

The chapter is a transcript of a meeting of a finance committee. The participants are about to discuss the last three items on their agenda: the budget for building an atomic reactor, building a bicycle shed for the use of the clerical staff, and finally the refreshments supplied at meetings of the Joint Welfare Committee.

The participants

According to Parkinson there are two kinds of people: those who have vast fortunes of their own, and those who have nothing at all. The members of the first group know what a million pounds looks like and what it represents. A very small part of the second group, the mathematicians and economics professors, might have never seen a million pounds, but they know what it represents, and they can make a difference between a million and a thousand pounds. The larger part of the second group, has seen a thousand pounds, but has no idea about a million, but they think it is like a thousand, and they handle it accordingly. According to Parkinson, those who are making high finance decisions unfortunately mostly come from this part of the group. And the committee, whose next item on the agenda is to set the budget for an atomic reactor, consists of these people.

Let’s build an atomic reactor

The treasurer presents the 9th item on their agenda: approve the ten million pounds budget for building an atomic reactor. He distributes the plans and the related documents, and shares the concerns of the consultant engineers who previously stated that the reactor could not be finished before the deadline the sub-contractor signed for that there were details that were overlooked during the planning. The chairman thanks the treasurer for the detailed introduction and asks whether anyone has any questions. The committee has eleven members, and out of these eleven members, four - including the chairman - have no idea what a reactor is. Three don’t know what its purpose is. There are only two persons from the rest, who vaguely know how much it costs to build a reactor. Fortunately, both of them can speak up. So the first member suggests giving the assignment to another sub-contractor - a more reliable one - and involving other consultants.

The chairman thanks him for speaking up, but he says that it is too late to involve others in this project, and a significant amount of money has already been paid for the plans. If the committee decides to re-do the whole planning phase, it will cost a lot. Several members of the committee nod. Finally, the chairman asks the other person - you remember, the one who vaguely knows how much it costs to build a reactor - to speak up.

As it turns out, he is the only one who really knows something about building an atomic reactor, and not just vaguely. He also knows that the actual sub-contractor cannot be trusted, the ten million pounds is very strange, and has no idea how it was actually calculated. But he knows something else: the other members. He knows that it would take him a lot of time and effort to teach them the basics of nuclear physics so that they have a basic understanding of how atomic reactors work and what it takes to build one. So instead of speaking up and making this effort he simply says that he has nothing to add.

Since nobody disagrees, the chairman signs the document and moves to the next item on the agenda. The discussion of the 9th item took almost 3 minutes which doesn’t include the time that was necessary for distributing the documents. They are on schedule.

The bicycle shed

The next item is the budget for building a bicycle shed for the use of the clerical staff. But before the chairman delineates it, some of the members feel bad. They are not sure that they have made a good decision, and they promise themselves that they’ll prove later in the meeting that they are valuable members of the committee. The cost of building the bicycle shed is 350 pounds.

One of the members thinks that the price is too high, and suggests building the roof of shed from asbestos instead of aluminum. The other “roof experts” jump in, and one of them even suggests cancelling the project, because the staff doesn’t deserve a new shed.

The debate continues, because most of the members are able to understand what 350 pounds represents, and almost every one of them has seen a bicycle shed before. The whole debate takes 45 minutes with the prospective result of saving about 50 pounds. Now, everybody is happy, because they feel that they did something important, something that also provided results.

Refreshments supplied at meetings

The last item on the agenda is the refreshments supplied at meetings of the Joint Welfare Committee, which cost about 35 schillings a month, which is about 4 pounds a year. Luckily all of them know something about beverages, and can imagine 4 pounds, so everyone jumps in. The whole discussion takes about 75 minutes, but there is no result, because they need more information on the subject, so they adjourn the meeting and make the clerk do more research.

Parkinson’s Law

“The time spent on any item of the agenda will be in inverse proportion to the sum involved”. It is spot on Mr. Parkinson, it is spot on indeed. Although, the scenario above is a complete fiction written about 60 years ago, I keep seeing it happen more and more nowadays. I’d love to know where the equilibrium between the time spent on a decision and the sum involved is and where is the point is when the interest vanishes. I hope that scientists are working on these problems, but until they solve them, I’ll try to keep myself away from meetings like this.

Even if it is not right, it is possible...

2013-01-16T00:00:00+01:00

I’ve quite recently had a discussion with one of my friends, Tom, who has been working for a large company - not a telecommunication one -, about the behaviour of one of his new colleagues, Jeff. Tom didn’t understand why Jeff wasn’t doing his utmost to be a valuable member of the team during his probation period. I told Tom that there might be a good explanation, and it was possible that Jeff could finish his probation period with his non-cooperative attitude. I wasn’t saying that what he was doing was right, but it was possible. I think one should consider the possible scenarios even if they look less possible in the given context, and in this case Tom had to do something about the problem, because he was the only one who had first hand information about what was going on.

For the sake of the example, let’s assume that Jeff’s attitude is part of a strategy. Have a look at the payoff matrix on the right, which shows the possible outputs from the perspective of the company. (Please note that the matrix and following chapters contain numbers I made up in order to show a version of Jeff’s strategy.) Being cooperative means doing his utmost to help move the company forward, being non-cooperative means to do a minimum and take advantage of the helpfulness of others. When both are cooperating, Tom can add 0.75 to the output, because he uses 0.25 for helping Jeff getting around, and Jeff can add 0.25, so they generate 1. When Jeff doesn’t cooperate, but Tom does, the output is 0.75, because Tom is the only one who contributes. His other 0.25 is wasted on Jeff as a teaching effort. The bottom left corner of the matrix shows 0.6. Tom adds 0.5 as a minimum in order to avoid attention to his poor performance. Since Tom is not helping, Jeff couldn’t add too much, but let’s say he could come up with an extraordinary 0.1. The last corner shows 0.5 which comes from Tom as his minimum.

According to the matrix it is the best interest of both to be cooperative, however Jeff can secretly choose a strategy where he doesn’t cooperate, because this strategy also provides results. A manager may say that a new employee will be productive after six months, and a drop in the output can be accepted, because teaching takes time and effort. So, if Jeff’s strategy is not revealed until the probation period is over, he will survive just fine. He may look like an average employee, which is not bad for someone who is not cooperating at all, while the responsibility is on Tom.

Let’s say that after the end of the probation period, the cooperation from any of them adds 1 to the output, and non-cooperation adds only 0.5, because none of them wants to lose their job. Interestingly, the game doesn’t have to change after the end of his probation period, because neither Tom nor Jeff is interested in changing their strategies. There are two reasons.

First, have a look at the top right corner of the next payoff matrix, which shows the output when Tom cooperates, but Jeff doesn’t. It’s not exactly 1.5. It is about 1.65, because Tom may want to save the situation and add an extra 0.15 (or more). It is more than double of the previous 0.75, and it is also more than the output of a good and an average employee working together: 1 + 0.5. Even without the extra 0.15 it looks acceptable in a large enterprise context.

Second, Jeff’s behaviour will attract some attention eventually, but his position is good. He won’t just be fired - you need a very good reason for this in many countries -, so he can temporarily cooperate until things quiet down. However, Tom’s position is worse: he cannot add more - he has already been performing at 115% -, and his stopping cooperating will also attract some unwanted attention. From another perspective, the change in Jeff’s strategy will have a positive effect: he is improving, whilst the change in Tom’s strategy will have a negative effect: he is doing below expectation. So, none of them is interested in changing strategies.

However, what Jeff is doing is morally questionable, and Tom is the one who can do something about it. Now, still within the probation period, Tom feels that something is going on, but he is afraid to talk to Jeff, or ask for help from his manager (this has a different root cause, but that doesn’t matter now). Tom is still convinced that one always cooperates during probation, and everything is going be to fine. I’m not saying that there are people with evil agendas out there, but considering other aspects won’t do any harm, and talking to Jeff is a must, no matter what Tom thinks. Maybe he is not as good as he looked during the interview, or there is something else going on.

A related post you may find also interesting:

Only Variety Can Absorb Variety

I Love the Smell of Outlook in the Morning

2012-12-11T00:00:00+01:00

My workplace (actually two of them) used to be in the middle of a large landscape, and when I was walking to my desk and saw colleagues reading and writing emails in the morning, I used to smile, take a large breath through my nose, and whisper “I love the smell of Outlook in the morning!”

Most of the people around me do a lot of things that I’ll never understand - most probably this feeling is mutual -, and reading emails in the morning is one of them. I saw a guy once who had been sitting in his coat for 3 hours reading emails, because he didn’t have a chance to take it off. What interesting or important things could he have been reading about that made him sit there for that long?

I can think of two possible explanations. First, nowadays working times are flexible, therefore everyone can start and end their work at different times on a given day. When they come in in the morning they are curious about what others did while they were away. Second, they usually save some discussions from yesterday and plan to read them while having coffee in the morning. Both sound reasonable, but a mail application is like the television: we cannot really turn it off after we turned it on, because there is always something new to watch, which is in our case reading and writing emails.

Every new email is like a new show or a new channel on “television”: it is either interesting, thought provoking, entertaining or frustrating, so we keep listening to it. When it becomes too much, we simply let it go into the background, but when we hear something worth listening to, we immediately turn our attention to it. I’m pretty sure that you’ve also reached a point when you’ve had enough and closed your email application, but when the “new email” notification popped up, you opened it immediately. No matter what, the email application is there, and it has our divided attention, which makes people say: “I haven’t done anything valuable today, because I was reading and answering emails the whole day.” There was a time when we called this phenomenon “Outlook Driven Development”.

Banning the television from our home is hard but achievable, however, we are certain that we cannot ignore our emails. I was interested in this topic, so I did a personal experiment, and stopped reading and writing emails. At that time the size of my team was rather small (below 7), and I managed to do my job and be a part of the team, while the number of incoming emails reduced drastically: the others learned that there was no use sending me stuff, because I won’t read and answer them anyway. The other interesting result was that this didn’t cause any changes in the personal or phone based interruptions. This meant that most of the emails I was reading and answering were never that important.

I was curious if this could work for somebody else as well, so I asked a friend to join the experiment. He was a member of a larger team and several other groups. As far as I remember, he managed to do this for a day or so. It wasn’t a complete failure though. We concluded that ignoring emails won’t work when one is a member of a larger team and/or several groups, because he will be left out from the information flow. In theory the solution would be for everybody to stop reading and sending emails at the very same time, which sounds a bit futuristic.

We didn’t give up and tried out a different approach. The “emails first, work second” order was a habit, and as such, it was changeable. We agreed that we would change the order, and we wouldn’t open our email application until we did something valuable that day. The first day was interesting for both of us: I needed about 7 hours to finish what I had planned, and my friend reported similar results. The next day was like before, but after several attempts we somehow managed to change our email reading and writing habits: we try to do something valuable during the morning, and when it is done, we open our email application. It is not perfect yet, but we can achieve something valuable during the day, and we can be an effective member of the email readers’ and writers’ society.

The Walnut

2012-12-03T00:00:00+01:00

The current weather in Finland reminds me of the nice autumns we used to have back in Hungary when I was a kid (Hungary used to have four seasons, but thanks to the climate change, nowadays there are only two seasons: Summer and Winter). I especially remember the evenings about 15 years ago, when I was cracking walnuts with my grandmother in her kitchen. I remember telling her that we had to have more walnut trees so we could make a fortune selling walnuts. One kilo of peeled walnuts cost about 700 HUF at that time, when one earned about 560 HUF with manual labour a day. We had one tree, which produced about 20 kilos of walnuts a year, and we peeled this amount in 3-4 days (mainly during the afternoon and the evening), so we made about 14000 HUF in three days. A manual labourer had to do hard work for this kind of money for more than half of a month. The people to whom we sold the peeled walnuts always wanted more (there was a demand), so it was a great business opportunity. Unfortunately, my family didn’t value this kind of business at that time, because according to them, a decent man should have a decent job and this walnut thing is not it. It was just something to gain some extra money from for Christmas.

A couple of weeks ago, I was watching an interview with György Klapka - a Hungarian entrepreneur -, who actually built a business based on walnuts. He is a divisive figure in Hungary, who has always been looking for better and better business opportunities (maybe that’s why half of the country doesn’t like him). About 13 years ago - what a coincidence - when he was about 70 years old (!) he was looking for mid-term investments, because he wanted to support his children after he was gone. He had some land and decided to grow something. His imaginary time frame didn’t give him too much choice, so he started to look for something with a low investment cost, and high profit in the mid-term. During his research he read about cherries. It really fit into the equation and there was a demand, but the cherry business was really weather-sensitive: a lot of rain could damage the goods, which made them impossible to sell.

The second best thing he read about was walnuts. The possible profit margin was lower than that of the cherries, but the walnuts are more resistant to rain and other weather damages, so he decided to plant walnut trees on his property. A walnut tree produces its first crop after 3-4 years after planting, lives for approximately 80-100 years and doesn’t require too much care. The only thing one should take care of is a fast harvest. After the walnut has fallen down, the surrounding green casket needs to be removed very soon, otherwise it will start to create a certain black fluid, which colours the kernel, which makes it really hard to sell: it looks bad and tastes awful.

Back to the present, he has been running different kinds of businesses since then, but according to the mentioned interview the walnut business is his most profitable and steady one. I haven’t found any evidence that he is a lean or systems thinker, but his enterprise is very efficient and well organized. He had a road built, because the vehicles couldn’t easily reach the facilities, he bought the best available equipment so that the harvest was going as efficiently as possible, and automated almost everything, but only those parts which were necessary. For example, almost the whole harvest and processing is done with machines, however the peeling is semi-automated. The machine doesn’t peel the walnut it just cracks it so that the internal part is still in one piece, then the walnut gets transferred to the local prison where the inmates peel it for some money. His business isn’t built on the peeled walnut - like my idea was -, but it is a part of it. He distributes the walnut in Hungary and in Europe, and since the quality and quantity is very good, he has no problem selling the crop. This is not bad from a 83 year old man. I should have pushed my family a bit harder at that time :-)

Liquidity for Kanban Systems, My First Look

2012-11-25T00:00:00+01:00

In his keynote at the Lean Kanban Central Europe 2012 conference David J. Anderson proposed a new metric for Kanban Systems, which is supposed to provide an answer to the big organizational governance question: “How do you choose where to place a piece of work or project?” The idea is to measure the pull transactions per volume (persons or units of currency) in a Kanban System, which shall tell us how liquid it actually is. There is an analogy to the liquidity of the markets from the investment banking domain: the more liquid a market is the higher the trust is. According to David:

…Measuring and reporting system liquidity is important to building trust to enable a probabilistic approach to management of knowledge work and hence elimination of wasteful economic overheads facilitating the comfort mechanisms inherent in the existing pseudo-deterministic approach to management. System liquidity provides an important indicator, solving the governance challenge of selecting the best vendor or department to process a work order…

In layman’s terms, the probability of getting desired outcome is higher if I work with the team with the highest liquidity.

Liquidity for Kanban Systems

Imagine the Kanban System as a market where the transactions are the pulls. In this context the liquidity of a Kanban System is the number of pull transactions in a given time period (which is three in the example above). There is a normalized form in which the number of pull transactions is divided by the number of team members (or currency) in a given time period. I’m going to use the normalized form in the rest of this post, but will leave out the word “normalized” when referring to it for simplicity.

At the end of his talk, David challenged the Kanban community to measure the liquidity in their organizations and collect as much information as possible to see how the idea works in practice. I was curious about it, so I took the data from my “Measure and Manage Flow in Practice” talk ([1]) and calculated the liquidity of an old team of mine ([2]). I use the word “calculated” and not “measured” on purpose: my results weren’t entirely measured so they’re not solid enough. Back then I was collecting data for a different purpose and therefore I was missing some details which I had to figure out by using calculations, and this is not the way to do accurate measurements. Additionally, I didn’t remember the entire context, which made it hard to explain the data. Nevertheless, I think the result of my calculations is good enough to start with, so here is it:

The matching CFD chart:

Towards the end the CFD shows some stability, however the liquidity is still moves up and down. I don’t have a good explanation, so I’d rather wait for the real measurements to provide more details about this phenomenon.

Unclear relationship between liquidity, lead time and throughput

At the moment I dare to state that the connection between liquidity, lead time and throughput is not clear yet. I cannot say that a team with higher liquidity will deliver faster or deliver more. For example, there was another team where we had a separate column for code review. After long discussions we decided to merge the code review and development columns and made the code review a part of the definition of done. I clearly remember that the lead time and the throughput did not change, however if I had calculated the liquidity I would have ended up with a lower number, because fewer columns on the board means fewer pull transactions.

This statement isn’t one hundred percent accurate either, because pull transactions won’t necessarily happen linearly, by pull after pull. Pull transactions can happen in parallel, completely unrelated to each other. Imagine that you have to do a work item and you have five columns on your board. This means that your liquidity will be five if you work only on that work item and finish it within the given time period (the number of pull transactions to get a task done is equal to the number of columns you have on your board). If you take away a column, your liquidity will be four if you follow this linear thinking. However, with fewer columns you can reduce the inventories and waiting times, so you may find some time to pull another item somewhere else on the board, so you might have a liquidity of five again. This works the other way around as well: if you need an extra column (like when we had to create verification and validation columns instead of a single testing column) you may increase your liquidity, but you may need more time to pull work items forward, so time-wise you won’t gain that extra in your liquidity.

Concerning throughput, have a look at the following charts:

They are quite the same, but not really. There is a noticeable gap in throughput although there were multiple pulls at the very same time. Since my data comes from calculations I don’t know too much about the context, but an infinite queue on the board can explain the difference (an infinite queue is a specific column which has no WIP limit and works as an unlimited inventory): the team pushed work items into that queue more frequently than they pulled form it. In this case the liquidity will be high because of the frequent pushes, but the throughput will be low because of the rare pulls.

What liquidity is telling me at the moment

At the moment I see liquidity as an energy level indicator. In order to keep this level relatively high, the team needs to continuously improve itself (this is the fuel which is necessary to create energy). When liquidity drops or increases we know something is happening. For example, you can spot a recurring pattern (the chart on the left) in the first daily chart. There is a calmer period, which is followed by a spike and then a drop. A little bit later, there is an almost equally large spike and a calm period again. First I thought that this phenomenon happened around the dates when we had deliveries, but as far as I remember we rarely worked that much before deliveries (high number of pull transactions may indicate high workload, too). However, we had an infinite queue after implementation - I remember that clearly -, which we emptied (first spike) when we were physically unable to put more work items into it. After that we put the implemented work items into the empty queue and pulled them forward (second spike) so that we could continue the implementation (the longer calm periods) with a clean sheet.

Calculation and measurement issues

I’ve already written about the problems that infinite queues in the middle of the flow can cause, but there are more gotchas, which may make the measurements hard to perform.

The first issue is with the expand and collapse method: a couple of times, we broke down a large work item into smaller pieces and worked only with those, but at the validation phase we merged them back together. My common sense would dictate to use the pull transactions of the broken down work items, but the breakdown process is really team-specific, which may make the comparison of teams (this is the purpose of the liquidity measurements) less possible or accurate. On the other hand, if a team can break down work items in an efficient way, then that team may be better than other teams.

The second issue appears when the team rejects work items and moves them back on the board. In this case the number of pull transactions on those work items can be easily doubled if they moved back to the beginning of the board.

The last issue has nothing to do with measurements (or calculations) directly, but may cause some trouble later: the changing number of the columns and the people in the team. I’ve already written about the issues with the number of columns, and my pessimistic half has already visualized teams arguing about having more columns just to have the chance of achieving a higher liquidity instead of improving their ways of working. Additionally, the number of columns and the number of team members were changing frequently in the observed time period (for example in my case I calculated about five column changes and six changes in the number of persons in the team), and I don’t know how this change will affect the liquidity-based comparisons in the future.

Liquidity by work item size

Finally, I was curious how the liquidity by work item size chart looked like:

It seems that the smaller the items are, the more pull transactions are in the system, but this needs to be investigated further. I’ve already written about expand and collapse and I’m wondering if there are any connections here. In theory there is one, but I’d rather wait for some evidence from measurements before jumping to any conclusions.

The first comparison

I managed to find a picture of another team, calculated their liquidity and compared it to ours (check out the chart on the right, which covers two weeks). As you can see, their liquidity was way lower than ours, but they were more trusted inside the whole organization. This might be important in the future: the measured data or scientific proof such as liquidity won’t change cognitive biases automatically. I’m certain that no matter what our team would have done, the other team had been in favor. Nevertheless, I see a great potential in liquidity for Kanban Systems, because besides the potential in comparison, liquidity provides more details about the internal affairs of a team.

Update: you can find David’s own post about liquidity on his blog.

Notes

I used the data behind the CFD (Cumulative Flow Diagram) and some pictures from the material of the talk
The pictures provided the number of columns of our boards at the time when they had been taken. I used this information to calculate the number of pull transactions, because the number of pull transactions of a finished work item was equal to the number of columns when the work item had been done. I used the lead time (done - started) to figure out when the pull transactions had happened: I evenly distributed the number of pull transactions along the working period

Chrome Remote Desktop Plugin

2012-11-22T00:00:00+01:00

I remember the good old times when if one of my relatives or friends had some problems with his or her computer, I simply went over and solved it. I was never good at phone support, because I’ve always had to see a problem in order to solve it. Nowadays, almost everybody I know has an internet connection, so I no longer have to go over, because there are tools like SSH, Skype screen sharing or Windows Remote Desktop Connection (RDC), which make it possible to provide valuable remote assistance. But it is not always that straightforward.

For example, it is not easy for a regular user to allow SSH or RDC access, and even if she manages to do it, the fact that almost everybody is behind a firewall and/or NAT, makes direct connection almost impossible. There is the screen sharing option of Skype, but it has rarely worked for us, so I had to look for an alternative which was easy to use and provided basic features such as screen sharing and remote control.

As usual, Google Chrome comes to the rescue. There is a plugin called Chrome Remote Desktop, which allows access to a remote machine regardless of its place in the network (behind firewalls and/or NAT) or its operating system. Here is a screenshot of my Chrome instance, where I’m upgrading some packages on my mother’s computer:

The tool works just fine. I was able to do everything I needed to do, and I didn’t have to explain several times how to use it. The installation and the first usage required some preparation and chatting, but the second time we needed it, my mother just sent me the login details and I was in and out in 5 minutes. I can only recommend this plugin.

A Zeno Paradox at the Workplace: Achilles and the Tortoise

2012-11-15T00:00:00+01:00

A good friend of mine and I were chatting about why teams considered as suppliers (back office) work noticeably more than those working with or for the front office. We didn’t jump to any conclusions, and we started to talk about something else, but it kept bugging me, which is never a good sign. I knew that I wouldn’t go to those teams and ask them questions (which would have been a better way to put an end to this issue), and it wasn’t really that important either, so I tried to figure it out by myself during a longer bus ride. As my current theory goes, the back office has the false belief that they don’t know enough about the domain, therefore they spend a huge amount of work on filling in the imaginary gap in their competence, but despite every effort they won’t be able to succeed. Their approach is wrong, and here is why.

I’m sure that there are cases when this phenomenon is explained by the fact that the managers of the back office are afraid that if the managers of the front office won’t see a 100% percent utilization they are going to look for another supplier. It can also be a simple cultural difference. I was generous to myself and I simplified the scenario by eliminating these and similar variations, and said that the front office looked at the back office as equal, most of the decisions were made together, and they considered the back office as a long term strategic partner. This was the case in the situations my friend I were talking about before. But even under these circumstances I spotted the phenomenon.

When the front office cannot do more work and needs help, it looks for a back office that can provide the necessary workforce (for significantly lesser money of course). At the beginning of their relationship, the front office owns the domain know-how, which is its most important asset. Both offices need this know-how in order to be effective and valuable partners in this relationship, so the back office starts to learn as much as possible about the domain. When it reaches the desired level of knowledge and sees itself as equal, comes the surprise: the front office is ahead again. While the back office was learning the old things, the front office used the same amount of time to come up with new things, and now it has an advantage over the back office again. The back office wants to be equal, the front office wants the back office to be equal, so the catching up starts again. This time the learning period is shorter, but they still aren’t equal, because of the very same reason as before. And this goes on and on. The situation is similar to one of Zeno’s paradoxes of motion: Achilles and the Tortoise. Here is the short description of the paradox from Wikipedia (image source):

In the paradox of Achilles and the Tortoise, Achilles is in a footrace with the tortoise. Achilles allows the tortoise a head start of 100 metres, for example. If we suppose that each racer starts running at some constant speed (one very fast and one very slow), then after some finite time, Achilles will have run 100 metres, bringing him to the tortoise’s starting point. During this time, the tortoise has run a much shorter distance, say, 10 metres. It will then take Achilles some further time to run that distance, by which time the tortoise will have advanced farther; and then more time still to reach this third point, while the tortoise moves ahead. Thus, whenever Achilles reaches somewhere the tortoise has been, he still has farther to go. Therefore, because there are an infinite number of points Achilles must reach where the tortoise has already been, he can never overtake the tortoise.

Although I enjoy having philosophical conversations, let me stop here and bring psychology to the table, because the fact that the back office (Achilles) won’t give up or do something else in a deteriorating situation like this, can be explained.

In school we learned that with diligence it was possible to get a good score or even the highest score, but it seems that this doesn’t apply here. I see the problem in the difference of the contexts: at school the target was fixed (the knowledge we had to present at exams) and the iterations were also fixed (the number of grade levels), but at the workplace the target is moving, and there is an infinite number of iterations (like in the case of Achilles and the Tortoise). Despite of the difference in contexts, the back office still tries to apply this “well proven and working” method to catch a moving target.

Chasing a moving target is hard, although when there are interim positive results and feedbacks, it is manageable, and sometimes there is some satisfaction during the chase. However, I’ve never seen satisfaction at the back office. I’ve seen frustration and dissatisfaction instead, because the interim positive results were missing. The brain doesn’t like to be in a state like this, so it tries to do something about it by using inherited (surviving) or learned skills. Usually, it picks the proper approach, but in this case it tends to make the wrong choice, because humans are loss-averse (another nice feature of our brain): they try to avoid losing things, which is the effort put into the catching-up in this case. Instead of giving up and trying a new way, our brain tells us to prevent this loss, so we keep doing the catching-up.

There are no best practices or world changing advices here. Wiser men have been trying to solve paradoxes for a long time with little success. Psychologists have built a very large and successful business on accepting loss and coping with it (called therapy sessions). Another friend said “Why do you care? It’s their business not yours.” He might be right, I don’t know, but I know one thing for sure: doing overtime to catch up - it’s like Achilles is cheating - won’t do any good. We did it once, managed to catch-up, but most of us got exhausted, others had family issues which caused a slowdown in our life, and we found ourselves right were started: behind the front office.

Well done Mr. Tortoise, you’ve won. Dear Reader, don’t take this post too seriously, since it is just a theory dumped from my brain after a long bus ride ;-)

(P.S.: if you have a major in psychology and/or philosophy and you happen to know that this is not the way things work, please correct me in the comments, and I’ll update the post).

Only Variety Can Absorb Variety

2012-11-11T00:00:00+01:00

I recently read the expression “only variety can absorb variety”, but I had no idea what it meant. It took me some time, but I figured it out. It is a short version of the Law of the Requisite Variety by William Ross Ashby (on the right), a pioneer in Cybernetics: “The larger the variety of actions available to a control system, the larger the variety of perturbations it is able to compensate.” (source: Principia Cybernetica). In layman’s terms it means the more flexible a system is, the better the chances that it is effectively able to react to change. For example, the more languages I know, the better my chances are to find my way in a foreign country.

Ashby’s Law

The Law of the Requisite Variety is often referred to as Ashby’s Law. Ashby once said: “Only variety (in the regulator) can destroy variety (in the system being regulated)”, which sounds like quite the opposite of what I was talking about before. This discrepancy comes from the fact that there are two ways to deal with variety: either by change - absorbing more variety -, or regulation - controlling the input as much as possible. Ashby’s quote refers to regulation, whilst the definitions from the first paragraph are referring to change, which is more popular nowadays. Nevertheless, Ashby’s quote helps understand the context where the Law of Requisite Variety can be applied: there are at least two systems, they both have a certain level of variety, and they are communicating.

Understanding variety

I’ve been writing about variety, but never really defined what it is. According to the Principia Cybernetica: “Variety is a measure of the number of distinct states a system can be in”. Although it is a result of measurement, it is usually hard to quantify precisely, but in most of the cases an uncountable adjective does the trick. For example, the variety in our team is high.

However, in my language example above it is easy to provide the variety as a number: it is the number of the languages I speak. If I speak two different languages, then the variety of my system in the context of spoken languages is two. If my friend joins me, who speaks three different languages, one of which I don’t speak, then our system’s variety in this context is three.

Communication between systems

Charles E. Osgood talks about communication between systems: “the amount of output from a system is limited by the variety possible within the system and/or the variety of input to the system. The number of possible alternative communications between the two systems is limited by that system having the fewest output alternatives and/or the fewest input alternatives.”

If my friend and I are visiting a country where at least one of the languages we speak is spoken, then most probably we’ll find our way (the number of alternatives are greater or equal to one). If we move to a part of this country where there is a strong dialect, we might have communication problems (the number of alternatives are zero).

In order to be able to continue our journey we need a new member to the group (system), who understands both that dialect and us. So, we have to increase the variety of our system. This is what the phrase “only variety can absorb variety” means: we cannot really respond to a new context or a change without increasing the variety of our system.

Absorbing variety

Absorbing variety is one way to respond to change. Let’s say I’m the leader of a team. I tell them what they have to do, and if they do something else, I’ll punish them. It is a classical command and control approach. If a change happens, according to Ashby’s Law, I have to increase variety in my organization (the system) in order to be able to respond. Since I’m keeping the whole team under my control, the only way to do this is by increasing the variety in myself. However, that is very expensive, and even if I’m a super human I cannot keep up with the pace of the change for a long time, so I need a different approach.

By giving up the command and control approach and introducing empowerment, I can open up the potential in the team and use the variety from their background, knowledge, etc. to absorb the necessary variety.

Ashby’s Law can be applied to business scenarios, too. In the next example, I’m running a hot-dog stand and the business is going well. I have more and more customers, but I reached a state where I cannot create the hot-dogs any faster. Due to the longer waiting time in the queue, certain customers stop coming back. The current number of customers is satisfactory, but it could be more, so I hire an employee to help me out.

Regulating variety

I mentioned before that there are two ways to deal with variety, and regulation is also an option. Let’s see the previous situation from a different angle: I’m satisfied how business is going. I’m very uncertain about the future, and I don’t know how the market will look like in three months. So, instead of hiring a new employee, I control the variety by continuing the business alone.

Depending on the context, regulation can be achieved by specialization as well. My customers are asking me whether I plan to sell beverages. I say no because of the previously discussed uncertainty, and keep being specialized in selling hot-dogs only, but I recommend a friend’s store where they can buy beverages.

Cost of response

It is important to know that even if the input of our system is regulated, the other system’s unmatched variety is still there, and it will be the input to another system. What if the customers, who were asking for beverages, find another hot-dog stand in the neighborhood, which sells canned sodas? Unless my hot-dog is extraordinary, they’ll buy hot-dogs from that stand and I’ll lose money.

As always, the response (absorb or regulate) depends on the cost or the risk I’m willing to take. Absorbing variety can be very expensive, but usually can lead to a better outcome. On the other hand, regulation seems to be a better option in the short term, but may have more disadvantages in the long term (note: I haven’t found any scientific evidence to back these statements, but somehow they sound obvious to me).

System overload

Until this point I was writing about the stage when the required level of variety is lower than the expected level. Robert Dilts calls this stage stagnation. When the system reaches a level of variety that matches the level of the variety of the other system, then the system is stable. When it is way above it, the system is overloaded.

I decide to sell beverages and I start big: I provide different kinds and in different kinds of packaging (I didn’t do any research and have no idea what they actually want). It is a huge investment, and what if my customers want only a can of soda (the one they can hold while eating the hot-dog)? Then my system is overloaded and this may have a huge effect on my business, because of the unnecessary investment.

Ashby’s Law in software development of the 21st century

Understanding Ashby’s Law can be very useful in software development, because it is all over the place. Scrum introduced the cross-functional team idea so that teams can adapt to change faster, eXtreme Programing emphasizes the importance of craftsmanship so that developers can provide multiple solutions to a problem, Kanban limits the work in progress to control the system, and in order to avoid system overload Systems Thinking is talking about understanding the demand.

Two Ideas for Stand-up Meetings

2012-11-06T00:00:00+01:00

I overheard two great ideas about stand-up meetings. The first one is from Dave Snowden. He observed that certain sessions weren’t going as effectively as they could. The participants were talking about irrelevant things, and the very important “what needs to be really done?” question wasn’t properly addressed during these meetings. Therefore, he suggested adding, or completely replacing the original three questions with this one: “What do I want to do instead?”

If there is a meaningful answer to this question, then the Scrum Team is doing something different from what it is supposed to do. I didn’t have the chance to talk to Dave about this in more detail, but here is my interpretation: a Scrum Sprint is a really focused event, and a Scrum Team is supposed to be a highly disciplined small organization. If a member of such a team in an environment like this is doing something other than what she wants to do, then either something is wrong with the Sprint or the level of discipline is not high enough. Therefore, this is something the Scrum Team has to talk about.

The other idea comes from Liz Keogh. She observed that when a meeting started with the phrase “who wants to go first?”, it turned into a status meeting. Somehow that phrase turned on the “I need to report” part of the brain, and from that point the meeting was meaningless from the Scrum point of view. Actually, this makes sense, and if I look back and think about the early stand-up meetings we had, the ones that started with a long silence were much better and more effective than those where we asked somebody specific to start.

Can the Marshall Model be Presented Differently?

2012-10-25T00:00:00+02:00

If you follow the recent events and discussions in the Agile/Lean community, you most probably have heard about the #rightshifting movement, which uses the so called Marshall Model to figure out the actual mindset of an organisation and help them to move from a less effective stage to a more effective one through intermediate stages. When Bob Marshall was explaining it in practice at Lean Agile Scotland 2012 I was thinking what if it was possible to skip these intermediate stages? When I was looking at the model as a chart, my idea only seemed possible via a huge jump which is always expensive and usually impossible, but what if the model is not represented as a chart, but a cylinder? In this case the transformation does not require a jump: it is “simply” a walk from one stage to the other.

Disclaimer: with this post I have no intention to change or improve the existing model, or create something new. I got an idea which I’d like to share with you. That’s all.

The Marshall Model

Before explaining my idea in more detail, I’d like to introduce you to the Marshall Model, more precisely the Marshall Model of Organisational Evolution created by Bob Marshall somewhere in 2008 and documented as a White Paper in October 2010 (by the way, happy birthday!):

It is a chart based model, which defines four major stages, which are, in ascending order of effectiveness: ad-hoc, analytic, synergistic, and chaordic. The goal of the #rightshifting movement is to help organisations to be more effective by moving to a stage to the right of their current stage, hence the name: #rightshifting.

I have no intention to copy and repeat the whole White Paper, but I need the exact definitions of the ad-hoc and chaordic stages in order to explain my idea:

“Ad-hoc: ad-hoc organisations are characterised by a belief that there is little practical value in paying attention to the way things get done, and therefore few attempts are made to define how the work works, or to give any attention to improving the way regular tasks are done, over time. The Ad-hoc mindset says that if there’s work to be done, just get on and do it - don’t think about how it’s to be done, or how it may have been done last time.”

“Chaordic: the chaordic mindset believes that being too organised, structured, ordered and regimented often means being too slow to respond effectively to new opportunities and threats. Like a modern Jet fighter, too unstable aerodynamically to fly without the aid of its on-board computers, or sailing a yacht, where maximum speed is to be found in sailing as close to the wind as possible without collapsing the sails, a chaordic organisation will attempt to operate balanced at the knife-edge of maximum effectiveness, on the optimal cusp between orderly working and chaotic collapse.”

So, in an ad-hoc mindset, typically chaos reigns, and in the chaordic mindset there is chaos and order (chaordic is a made-up word, it was created by mixing the words chaos and order).

Similarities between the Ad-hoc and Chaordic Mindsets

Apparently, all of these stages contain a certain level of chaos. However, when I’m looking at organisations in different kinds of stages from a distance, they all look the same: delivering software without using any formal process. I asked Bob about this, and he said that the difference was the discipline. In my head, if an organisation in an ad-hoc stage can develop discipline, it can be ordered, and with that it can get to the most effective chaordic stage.

The second similarity comes from my observations and hypothesis: the level of understanding creativity in ad-hoc and chaordic stages is almost the same (side note: I believe that software development is creative work):

A couple of years ago, I was a member of a team which was clearly in the ad-hoc stage. Our days were chaotic, and we were so focused on delivering that we didn’t pay attention to anything else. For example, being more effective - rightshifting - was never discussed, however our solutions were creative and we wanted the next solution to be creative as well. After a while, we realized that we couldn’t work like this any longer, it was so frustrating that we felt we had to do something about it. The conclusion was that we needed structure, so we gave up creativity and used the freed up time and effort to introduce it. After that, we went through all the stages of the Marshall model and before we got dismissed we spent some time in the chaordic stage. During this relative short amount of time, we had nostalgic discussions about the creative ideas we used to have in the ad-hoc stage and how good those times had been. So, we started to bring these ideas and discussions back to our daily work, and rediscovered the advantages of creativity. Since we were much more disciplined by then, it wasn’t that hard to do this one last shift and become creative again.

Jump from Ad-hoc to Chaordic

When I see two stages which have similarities, I immediately start thinking about how to get from one stage to the other, because it may be possible. Unfortunately, it is not that easy in this case, because those two stages are on the opposite edges of the Model, and the immediate transformation is only possible via a huge jump over the whole model:

This jump is really expensive and I dare say it is not even possible using the current understanding. It is like learning how to do freestyle swimming on the floor of the living room and the next day heading to the Ocean jumping into it and trying to get out alive.

Paradigm Shifting - Different Representation

However, if we give up this thinking and the chart based linear end-to-end approach, and present the stages on a cylinder where one can walk around instead of a chart, then we aren’t talking about a jump any more, because it is a walk from ad-hoc to chaordic like this:

In this representation ad-hoc and chaordic can stay next to each other, because they share common grounds such as the chaos and understanding of creativity. The effort to get from ad-hoc to chaordic is the effort to build up discipline in the organisation.

Closing Thoughts

Again, this is just an idea which came to my mind when I was listening to #rightshifting talks at Lean Agile Scotland 2012. What do you think about it?

PS: I used images and quotes from Bob Marshall’s White Paper with his permission.

A related post you may find also interesting:

There is a Difference Between Effective and Efficient

The Hidden Inventory

2012-10-16T00:00:00+02:00

A couple of days ago, I had a quick conversation with an old friend of mine about the place of done columns - also known as inventories - on the Kanban board. He wanted to know if the internal done column - where the work items that have been completed in that phase are kept -, or the internal queue column - where the work items done in the previous phase -, was the better option. There was a time when I would have said that it didn’t matter, just make it visible, but this time I gave a different answer: favour the internal done columns over the internal queue columns, because a system with internal queue columns might have hidden inventories.

The story starts with a small push when one moves the work items to the queue of the next phase:

According to the board above, this push is perfectly legal. Let’s assume for the sake of the example that the developer’s focus is on finishing as many items as possible in Implementation, so she pushes Item D into the queue of Validation and pulls in Item G. Let’s say that the cycle time in Validation is higher than in Implementation, so there is a good chance that Item G will be finished and pushed before Item D is started in Validation. The WIP limits are still honored, and Item G can be pushed into Validation, but with that it becomes full. The flow will stop when she won’t be able to pull more items into Implementation after that fills up as well.

The flow stops because of the temporary slowness of Validation, but the problem has been exposed too late, and additionally an inventory has been created in a form of waste. With her push, she increased the actual capacity of Implementation with the unused capacity of Validation and introduced a hidden inventory in the system (actually, she didn’t do anything wrong here, because the current system allowed her to do those steps). I called it hidden, because it is not visible until a change happens in the flow. When the hidden inventory becomes visible, it generates different kinds of other waste such as muri.

This problem won’t make your organization go bankrupt, but can cause some damage, especially when the work in Implementation and Validation is done by completely separate sub-organizations (this damage usually manifests as in half-done features, feature studies, or documents waiting to be pulled one day).

There may be many solutions, I can think of two at the moment:

Set the WIP limits according to the current capacity (this requires measurement of the capability and throughput in the different phases)
Use internal done columns instead

Both of the solutions will signal early enough if there is a disturbance in the flow. There is one more obvious, but important detail which is worth mentioning: the inventories must be included in the WIP limits, not like in the example below:

Here, the flow is not continuous and the mura waste caused by an unlimited inventory is huge. Of course, the visualization will show when the situation gets critical, but again this signal comes too late when a lot of effort has already been put into the work items staying in the inventory, and that investment won’t pay off in the near future.

Cucumber JVM: Hooks

2012-09-26T00:00:00+02:00

I finished the previous post with the promise that I’m going write more about hooks in cucumber. By definition, hooks allow us to perform actions at various points in the cucumber test cycle. The definition wisely doesn’t say much about these actions and the points where they are executed. They wary from performing prerequisite actions for scenarios to sending emails when a certain step fails. One can ask, What these have to do with the following scenario:

src/test/resources/web_text_munger.feature

Feature: web text munger kata
  Scenario: It should process a sentence
    Given the embedded tomcat is running      # NEW
      And the application is deployed         # NEW
      And I am using Firefox for testing      # NEW
      And I am on the home page
     When I enter "flow flow"
      And I press "submit"
     Then I see "folw folw" as the munged text
      And I see "flow flow" as the original
      And I close the browser                 # NEW (VERY BAD, DO NOT DO THIS HERE!)

The steps marked with # NEW have nothing to do with the business case of the scenario. They are prerequisites that I need done if I want to run the scenario. For these, I need a different kind of approach: I’ll call these steps in different hooks.

Scenario Hooks

Scenario hooks can be defined with the cucumber.annotation.Before and cucumber.annotation.After annotations (JUnit has the exact same annotations in the org.junit package, make sure you use the right ones as cucumber will not process JUnit annotations. Don’t try to use JUnit’s @BeforeClass and @AfterClass annotations either for the same reason – see also section about global hooks):

import cucumber.annotation.After;
import cucumber.annotation.Before;

@Before
public void beforeScenario() {
  tomcat.start();
  tomcat.deploy("munger");
}

@After
public void afterScenario() {
  tomcat.stop();
}

Let’s remove the unnecessary lines from the web_text_munger.feature and move their content to the scenario hooks:

src/test/resources/web_text_munger.feature

Feature: web text munger kata
  Scenario: It should process a sentence
    Given I am on the home page
     When I enter the "flow flow"
      And I press "submit"
     Then I see "folw folw" as munged text
      And I see "flow flow" as the original

WebTextMungerStepsdef.java

@Before
public void beforeScenario() {
    tomcat.start();
    tomcat.deploy("munger");
    browser = new FirefoxDriver();
}

@After
public void afterScenario() {
    browser.close();
    tomcat.stop();
}

The scenario executes without any problems and it seems that we are done. Now let’s run the old simple_text_munger.feature as well. No problem there either, but a Firefox window just popped up unexpectedly. It seems that the before hook has been executed twice. The methods annotated with @Before and @After are executed before and after every scenario regardless of where they are defined. That’s not good for us right now.

Tagged Hooks

It is possible to define a hook so that it is only executed before or after scenarios that are tagged with a specified annotation, for example:

src/test/resources/web_text_munger.feature

Feature: web text munger kata
  @web
  Scenario: It should process a sentence
    // The steps

WebTextMungerStepsdef.java

@Before("@web")
public void beforeScenario() {
  // actions
}

@After("@web")
public void afterScenario() {
  // actions
}

It executes nicely and the test case is green. Let’s add another scenario to the web_text_munger.feature. Both are green, no problems here, but the Firefox window popped up twice again. Since both of the scenarios have been tagged, the hooks have been executed twice: once for each scenario. If you have a lot of scenarios, it’s worth executing the before and after hooks only once in order to save time and resources.

Global Hooks: The Hacking

Unfortunately, cucumber doesn’t support global hooks at the moment. It is possible to solve this situation, but it is an ugly hack. Let’s use the first @web annotation to start the web service and the browser:

WebTextMungerStepsdef.java

private static EmbeddedTomcat tomcat = new EmbeddedTomcat();
private static WebDriver browser;

@Before("@web")
public void beforeScenario() {
    if (!tomcat.isRunning()) {
        tomcat.start();
        tomcat.deploy("munger");
        browser = new FirefoxDriver();
    }
}

Now the tomcat and browser references have nice global states, that’s why I don’t really like this solution, but I don’t have a better one at the moment, so I’ll try to live with it.

Closing the browser and stopping the web service is a bit trickier, we don’t know which the last scenario that requires them is, so we should shut them down when the test suite exits. This solution is pretty much the same as in ruby because there the at_exit is proposed to be used in cases like this.

WebTextMungerStepsdef.java

@Before("@web")
public void beforeScenario() {
    if (!tomcat.isRunning()) {
        tomcat.start();
        tomcat.deploy("munger");
        browser = new FirefoxDriver();

        Runtime.getRuntime().addShutdownHook(new Thread() {
            public void run() {
                browser.close();
                tomcat.stop();
            }
        });
    }
}

Final Words

Don’t let the previous example discourage you from using hooks. They provide a great opportunity for setting up scenarios and cleaning up afterwards. The code is available under the episode_6 branch on github. Happy testing!

Zsolt Fabók

Context and Perspective is Everything

About Flows and Infinite Queues

Related posts you may find also interesting:

Public Speaking Events in Spring

The Empty Else Block

The Optimal Batch Size

Related posts you may find also interesting:

The Coin Game

Related posts you may find also interesting:

When Will It Be Done?

Related posts you may find also interesting:

Be Aware of the Three Columns

Related posts you may find also interesting:

Parkinson's Law of Triviality

The scene

The participants

Let’s build an atomic reactor

The bicycle shed

Refreshments supplied at meetings

Parkinson’s Law

Even if it is not right, it is possible...

A related post you may find also interesting:

I Love the Smell of Outlook in the Morning

The Walnut

Liquidity for Kanban Systems, My First Look

Liquidity for Kanban Systems

Unclear relationship between liquidity, lead time and throughput

What liquidity is telling me at the moment

Calculation and measurement issues

Liquidity by work item size

The first comparison

Notes

Related posts you may find also interesting:

Chrome Remote Desktop Plugin

A Zeno Paradox at the Workplace: Achilles and the Tortoise

Only Variety Can Absorb Variety

Ashby’s Law

Understanding variety

Communication between systems

Absorbing variety

Regulating variety

Cost of response

System overload

Ashby’s Law in software development of the 21st century

Related posts you may find also interesting:

Two Ideas for Stand-up Meetings

Related posts you may find also interesting:

Can the Marshall Model be Presented Differently?

The Marshall Model

Similarities between the Ad-hoc and Chaordic Mindsets

Jump from Ad-hoc to Chaordic

Paradigm Shifting - Different Representation

Closing Thoughts

A related post you may find also interesting:

The Hidden Inventory

Related posts you may find also interesting:

Cucumber JVM: Hooks

Scenario Hooks

Tagged Hooks

Global Hooks: The Hacking

Final Words

Related posts you may find also interesting: