Settling for Lean

In this post I want to share my experience of playing the real time strategy game Settlers 7 with a Lean Manufacturing perspective. 

Overall I think introducing Lean when playing Settlers have really helped my game, but it is no question that it has also made me think differently about applying Lean thinking in a “real” context. Compared to the real world Settlers 7 is a simple system with more or less predictable outcome, but I see that I need to study and analyze what measures are needed for each different game. My focus has shifted from finding the “perfect” game strategy, to studying and learning in order to better adapt and find a winning strategy for a particular scenario.

Settlers 7 - a manufacturing game

Settlers differs somewhat from other real time strategy games I’ve played, in that resources which are collected needs to be refined before you get something of use. There are actually 26 different resources, 11 different units, and 19 different buildings that refine resources into new resources/goods. This gives us several interesting combinations of setting up production lines to produce the right goods for warfare, quests, trade or research. It is also important to point out that all resources are deposited at storehouses, before they can be refined or used. These storehouses have carriers who transport the resources between storehouses as needed. Workers collect resources at the nearest storehouse and bring them to their work yard. In order to be successful you need to watch your logistics as well as your production. The last element of the economy is to build the work yards and storehouses. All these buildings are built by dedicated carpenters and need resources and refined goods to be completed. This rather complex economy is what makes this game fun and interesting, especially from a Lean Manufacturing perspective.

Pulling the chain

When I first started playing Settlers 7, my strategy was to produce as much of every resource as I could, to create an abundance of everything in order to overwhelm my opponents. I also set up a large queue of buildings to construct, so that my carpenters would be effective and not idle. This strategy worked for the first couple of campaign scenarios, but proved to be neither efficient nor fun.

Instead I tried to apply Lean Manufacturing principles to my economy. Firstly I introduced a more pull based approach to my production. Instead of creating as much as I could of everything, I set up defined product lines to achieve a specified goal. These product lines are a mix of different buildings connected to a single storehouse, and has as a whole defined input and output.

For example in a product line to gain early research we need 3 novice clerics per technology. Each cleric requires 2 bread and 1 beer. Bread requires flour which requires grain. Beer requires grain and water. We then need to build 1 church, 1 brewery, 2 bakeries, 2 mills, 1 well, and 3 grain farms. This is a self-sufficient product line which produces and gives us 1 cleric per cycle, providing us with a new technology every 3 cycles. All these buildings are set to “On Demand” so they will not produce clerics when not needed.

The reason to build a product line around a single storehouse is to reduce the need for transportation between storehouses. This obviously reduces the cycle time but it also reduces the direct cost by building less storehouses. Not so obvious is the fact that this arrangement also makes the product line more robust against variation in transport load. If the resources instead are collected from different storehouses, the product line will be dependent on the burden of the carriers, which could impose delay.

One of the biggest benefits of introducing a more pull based production, is that I am now more focused on what I want to achieve and on the strategy in the game, instead of managing resources and goods. I also get a better efficiency and I win more games.

Studying the flow 

A natural side effect of introducing pull based production, is the reduction of excess inventory. We only produce resources we know we will need, and therefore we won’t have anything to spare. This proved to be a challenge. In one case I set up two effective pull based production lines, one to produce beer and one to produce sausage. I was producing more goods faster than I’ve been able to before, but suddenly everything seemed to collapse. There was no apparent reason, and a quick inspection showed me that I had enough resources and no overproduction. In theory my “pull-system” should work, but apparently it didn’t…

To find the flaw in my system, I had to go down to the production floor and study the process. I started following single resources through the production chain and discovered that my transporters where carrying grain between storehouses connected to separate grain farms. In other words they were carrying grain from my beer production line to my sausage production line, and vice versa. I had reduced my inventory too much! In Settlers 7 resources are consumed in a first come first serve manner, and when the beer production needed grain it was collected from the sausage production even though there would be grain produced there the very next second. To fix this problem I had to increase my inventory of grain at the different locations to reduce the waste caused by transport.

This error really taught me a valuable lesson and I started to regularly study the flow of single resources through the chain. Overall this has given me the most value from introducing Lean in Settlers. I have found that even though things look good in theory and a setup of product lines worked in one scenario, I really need to study the flow when setting up a new line or make small changes. When things are a bit different or we make small changes, the dominant wastes may also change, and this alters the overall behavior of the production system. At the most extreme the study of flow have shown me that in some cases I have to completely shut down a production line while starting a similar production line at a different location. The reason for this is that the sudden variation in demand is so great that a short stabilizing period is needed.

Limiting work in progress

Having improved my production I then focused on improving the build process. As mentioned earlier all buildings must be built by carpenter settlers, and carpenters need resource in order to build anything. When I want to set up a building, I place the construction site where I want the building, and my order is placed in a queue. As soon as the order is placed, the right amount of resources are allocated and brought by carriers to the storehouse nearest to the site. The carpenters won’t start working before all the resources have arrived. Obviously this whole process takes some time, and when you as player know what next three product lines you want to build are, you are tempted to set up all the sites and put it all in the queue. That way you can sit back or focus on other things, just as I did. And when I saw that this process was too slow, my first reaction was to “optimize” the order in the queue… which of course didn’t help.

What really helped was to introduce a limit on how many buildings I allowed myself to put in the construction queue. A large queue size meant a lot of resources where needed at the same time, putting a burden on both the production system and the carriers and thus uncontrolled delays and waiting time. It also meant having a large inventory of resources lying around at different construction sites. After reducing the queue I could see that the overall operation went smoother, and I realized that I had much more flexibility to adapt to unforeseen events, such as an attack from an opponent.

Useful URLs for playing Settlers 7

http://www.damocles.ca/settlers7/  - A good overview

http://forums.ubi.com/eve/forums/a/tpc/f/6061083365/m/9621004648  - Great post on food boosting. This post inspired me to think about Lean in Settlers

http://thesettlers.us.ubi.com/the-settlers-7/  - Official Settlers 7 site

Writing good specs is really hard!

Some time ago I and some colleagues started an open source project to create an application to register the Foosball games we play at work, in order to look at statistics and see which teams win the most games. As we wanted to learn more about Specification by Example we decided to try and drive the development with the process described by Gojko in his book. Even though we haven’t done much more than specifying a couple of features, we got a couple of lessons (re)learned from it. 

The first lesson is that you won’t save time in the specification process by reducing the number of participants. We tried to hold a specification workshop with only two participants. After working thoroughly on our specification, making them self-explaining with examples, we validated our effort by getting the other developers to proof read them. The criteria that they where good enough was that the developers should be able to describe the requirements without any help from us. Our requirements where accepted without any changes, and we where satisfied with a job well done... until a couple of days later when some of the developers wanted to implement the features. The lengthy discussions we now had, where similar to the ones we had in the workshop just a few days earlier, but now with a different people. It was important issues to clarify, but we could have clarified them earlier. Luckily nothing was implemented which depended on these requirements, as is often the case in larger projects. That would have made it even more wasteful. My lesson out of this is: You don’t save time by reducing the number of participants in specification workshops, you will only end up with the same discussions over again, and at a later time in the development cycle.

The second lesson I (re)learned, is that creating good specifications is hard work. It is so easy to underestimate the time it takes to conceive and formulate specifications that are unambiguous and easy to read/understand. To specify two requirements with examples, we used almost two hours. That's an hour per requirement!! Obviously some time was spent getting our heads around the relative new way of writing specs(with examples that is) and settling for the right granularity for this application. But I remember sitting in the workshop looking at my watch and thinking that we should be more effective! And I honestly think that if this hadn’t been a project on our spare time with a focus on learning Specification by example, we would soon be cutting corners to produce more specifications in shorter time. And that is really bad! The sad thing is that this is a likely scenario in many projects, but you never see the costs of cutting these corners until development is well under way.The cost is often put down to development costs, and thus not showing the real cost of specification work. We all know that uncovering mistakes or misunderstandings in the requirements at this stage is many times as expensive as doing it ”right” in the first place, but until we accept that creating good specifications is hard work we will continue to waste time and money.

All that she wants..

It’s now a month since I first learned about the concept of Specification by Example, and I thought it was time to incorporate the practices in my hobby project; making a portable shopping list for Android. As the developer I am, I boldly set up FitNesse on my computer and thought “Now I will write some GOOD specifications with examples”. But where to start? My attempts at writing examples showed me that I was describing ‘how’ the app worked, not ‘what’ it should do. Then I realized my first mistake. My focus was on automation and code validation, not on specification at all. I needed to push back and find out ‘Why’ I was making the app in the first place. 

At least this was easy since I had ‘ordered’ the app. The desired effect I wanted was to make the grocery shopping process easier for my family. We’ve tried other app’s on the market and none of them was good enough to get my wife to use them. So I needed an app that would meet my wife’s requirements for easy grocery shopping. Eager to succeed I started writing an effect map and wrote down everything I could think of that my wife would want in a grocery app. Feeling very clever I presented my findings to my wife, and she agreed that almost everything I had written where nice features she would like. This was no surprise, since I like to think I know my wife very well. Just to be sure I had covered everything I asked her if there were other things she could think of that would make grocery shopping easier. “No, I really don’t know what is possible to do with an app, so it is a bit difficult to say” she told me. It was clear she felt that her “duty” was done and wanted to talk about other things. But just as I had learned from the course, I insisted that anything would be welcome, even non-SW items. “Well”, she said, “I get a bit hindered since I need to hold my phone when shopping, it’s much easier to hold a small piece of paper..“

Then it struck me. I had just played out an all too common scenario from our industry. Gojko warned us several times of this in his course. It’s all too easy to focus on the system we want to make, so we forget what our stakeholders actually need. When being presented with a promise of a good application she liked my ideas. But any app I make won’t turn her phone into a piece of paper, which is what she actually wants.

Hidden moral of the story: 1) Push back to find the desired business effect. 2) Always collaborate with business users when deriving the features from the goals.

Daily introspection

Reflection is a key factor in the learning process and is essential when we try to systematically improve. There are a lot of different techniques for reflection depending on what you want to improve and whether you want to reflect individually or as a team. Although many recognize reflection as important, few actually take the time to reflect often and regularly. This is why I propose the simple technique ‘Daily introspection’.

The purpose of ‘Daily introspection’ is to establish a habit of thinking about what you do and how it affects your work and the world around you in general.

Daily introspection:

1. Create a reminder for when you would like to do your introspection (preferably morning).
2. Choose ONE tasks/issue from the previous day.
3. Write a few lines of why you think you did the right thing, or how you could have improved the situation.
4. Throw away what you write.

These steps should not take you more than 3-5 minutes, which is just short enough to not find excuses for being busy. If you don’t have 5 minutes a day for something, you don’t want to do it. To keep it this short it is important that you do not choose more than one or two issues. If you really need to reflect some more, tell yourself that this is an extraordinary reflection. Stick with the short reflection until you feel that you have established a habit.

Some of you will probably want to keep what you write as reference for later use. Maybe you want to look back and see what you have written a month or a year ago. Although this probably could give you some value, I advise strongly against it. To establish a habit by being consistent, you should aim for an easy flow. When you think you might read it at a later time, you will start to worry about how you write, which raises the bar for the technique as a whole. Besides, setting up a filing system for 365 reflections a year might discourage you.

If you try ‘Daily introspection’ I hope you will find this technique useful. I would love to hear your experience with introspections, and other techniques for making this a habit.

Specification by example

I attended a course on ”Specification by Example“ by Gojko Adzic, and he challenged everyone attending to write a summary of what we learned. Feel free to comment or give feedback if you have attended his course and have other perspectives of this, or if you see that I have misunderstood something. For those of you who are not familiar with Gojko’s work, I strongly recommend it. Check his site http://gojko.net.

Summary of Specification by example course

As I understand it, Specification by example is the process of creating requirement specifications using key examples from the business point of view to validate that the software is working as the business intended. The specifications are used as automatically run tests against the system and thus hold the Single version of truth. After deployment of the system these tests will also serve as Living Documentation of the system. As a developer I like to think of this as following TDD from the business point of view. (You might know it under other names as well.)

Setting up functional tests with tools like FitNess is not new to me. But a key point I got from the course is how to specify these tests in order to describe what the system should do and not how the system will do it. The latter is sadly the most usual mistake according to Gojko, and I realize I am one of those who have thoroughly misunderstood this. To see if you have captured what in your examples/tests you can use these criteria: 

1. You are using keywords from the examples to summarize them
2. You can’t summarize the examples in more simple terms.

Many of the guidelines for making good unit tests also apply to good specifications with examples, i.e. Keep them simple, Self explanatory, Easy to read for intended audience (business people in this case). An important lesson from the course is to push complexity into the gluecode layer. In other words, everything you need to setup and start test, such as inserting data into database should be handled by gluecode. If I understand this correctly this means that the speed of the tests are important, but not as important as keeping your tests clean and simple!

Achieving Living documentation is not something most organizations do in a flash. Gojko presents some process patterns one can implement to gradually get to Living documentation. These patterns are

·         identifying Desired business effect

·         Deriving scope from the business goals when the team is ready to implement more functionality. 

·         Identify Scope using User stories or Use Case

·         Collaborate to find Key examples

·         Refine into Specification with examples

·         Automate to get Executable specification

·         Validate frequently and evolve into Living Documentation