Two Systems

Priming

Apple, orange, grape.

Now fill in the missing blanc with the first word that comes to your mind:

_EAR

It's pretty safe bet to say your word was pear. So (hopefully) I fooled you! Situation would have been different if I would have selected snakes, tarantulas and other poisonous things and pasted this picture instead:

What happened to you is called priming. Human mind is really complex, but within the last decades we have learned to understand it better. Or at least we have better theories.

Brains have an awesome pattern recognition machinery. The artificial neural networks in Computer Science are trying to emulate how our brains work. They can be used to 'teach' the network to handle varying input. Our brains operate the same way. We have our own personal history. All our experiences, good and bad, actually affects how our brains work.

As a rude generalization I could say that brains are organized around ideas. Each idea contains a huge load of information about the topic and those idea boxes get more content while you gain more experience in life. Different ideas are connected. For example fruit - pear - green could be connected. Or if you have seen only yellow pears then your brain probably has different content. :)

In these vast networks there isn't only path across all ideas. And if you see some things more often together, they become more close for you. If you always get food after hearing a bell, your mind will probably link those two things.

Interestingly, your mind and body are maybe even more connected than you'd think. If you force your mouth into a smile or frown, it will statistically alter your mood. Similarly nodding or shaking your head will affect how you relate to a information you hear. Or if you see pictures of money, it will make you more independent, yet selfish. Probably not a good idea spread pictures of dollar bills around team room...

Two Systems

Your mind has actually two separate parts. There's the lazy, rational controller who thinks he's in charge and then the fast autopilot.

2 + 2 = ?

You didn't really calculate that. The answer just appeared in your mind. How about this:

16 x 27 = ?

You know you could answer that but it feels laborious and you don't want to do it. It would require some mental effort. Daniel Kahneman has labeled these two systems as System 1 (controller) and System 2 (autopilot).

System 2 is actually feeding us stories all the time about what's happening around us and System 1 is most of the time believing it. The difficult part is to understand when the story isn't true.

Cognitive easiness resembles truth. Saying that 'Repeating lie long enough makes it true' isn't far from being correct. And marketing people have known this for a long time. But things can't be to far out, they need to close enough to being true.

How many pairs of each animal did Moses take into the ark?

Well how about that? One pair? Or did you remember that Moses didn't even build ark, it was Noah. But don't feel bad even if you fell into this trap. Most people do. Moses is also an old guy in biblical context. Your brain was destined to fool you. But if I had replaced him with Skeletor your alarm bell would have probably worked better.

So sometimes we jump into conclusions without even being aware of it. Another noteworthy thing is that under strain the System 1 becomes almost blind. Check the experiment below. Stay sharp and concentrate on the white players:

While you concentrate of something mentally straining your pupils dilate. Also, you might need to stand still. (Have you ever been on the phone while walking and then you need to concentrate on getting the message through? At least I sometimes need to stop walking and think.)

All of this and much, much more you can read from Daniel Kahneman's Thinking Fast and Slow. If you are interested in how we (people) operate, I'd consider it a must read.

Side notes

As human brain extends and connects the ideas together, I'd like to also reflect how this information relates to what I've previously learned. Matthew D. Lieberman calls the two systems X-System and C-System. He actually has multiple references to Kahneman's work, so I guess it's good to read this one also.

David Rock (not personally) introduced me to the SCARF model. That already explains why we aren't so creative while being mentally strained. We can either fight or flight, but not innovate much.

Also this explains why I don't remember anything about conversations that I have while watching tv. And even more when I watch a movie that has subtitles. That's my brain saying "please return to the topic after the movie."

Lean Oven Beets

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

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

Process Flowchart.

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

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

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

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

Proper peeling knife. Poka-yoke.

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

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

Factory layout mark 2: More compact.

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

After shutdown and clean-up.

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

Customer Value Through Lean, part 1

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

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

Origins

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

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

Wastes, Support work and Value Adding work

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

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

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

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

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

Processes

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

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

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


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

DIY Build Light Indicator

This post will differ from my typical posts. It's not about processes or methods. But actually it's related to the practice of Continuous Integration. That's one of the key engineering practices most Agile teams use. Originally proposed by Grady Booch, but later popularized as one of the eXtreme Programming practices. For many Continuous Integration is simply "that build system".

There are many free and commercial tools available for CI. I have actually played around with CruiseControl (not much and I've never actually configured any builds in CC. It was more or less fading away when I joined my company), TeamCity (this one I like a lot), Jenkins and lately Bamboo.

The problem with all these CI tools, and all other online tools, is that you need to navigate to a specific place to find out if the build is passing or not. Similar thing for a Scrum wall or Burndown chart if you use for example JIRA. For us physical humans the physical things just work well...

The build light is a remedy for this. It converts the status of the build in our CI tool to a physical form: colored light. If the light is green, the build is passing. If the light is red, someone needs to fix the build ASAP! This kind of information radiator can easily spark action and foster self-organization.

Making yourself a build light isn't that difficult nowadays. In our case the most difficult thing was to get a Phillips hue Starter kit. With that you get a light that you can control with your computer. Then you will need a CI tool. In our case we connected our build light to a Bamboo build.

Then maybe the most difficult part: you need the glue code between your CI and your lamp. But today that's not too difficult either. Node-RED has made the task of connecting our physical devices to internet lot easier. (I'm not sure if it was difficult before. I'm just assuming it was.) Instructions for connecting your hue to Node red can be found from this blog post. (Actually before you get to use Node-RED, you will need node.js installed.)

But skipping ahead a few steps you get this: voila! Now we can diminish the "is the build passing?" questions. Simply check the lighting. If it's pleasant green you have nothing to worry. :)

Our buildlight. Who broke the build!?

Practice Makes Perfect - Release Planning Day 3

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

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

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

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

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

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

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

Focusing is Effective

If you have a hypothesis, there's probably no better way to validate it than by testing. It's one of my favorite practices from Lean Startup. Experiment. Make a hypothesis, test it and learn. Repeat.

But you also need metrics. Something that you can measure and see if your actions have impact on them. In our case we have been asking our Developers, Product Owners and Product Managers the same set of questions twice. (The poll has been anonymous and people have been participating really well.) The results show nicely how the actions we have done (our focus) have improved the results in those areas. Unfortunately they also show that things that have not been paid too much attention to are not improving.

We have made big efforts to improve our Product Management and to shed more light to our Product Portfolio. Also we have invested in training our Product Owners. The results in these areas are almost stunning. According to POs and PMs the work in Portfolio has improved by 30-40%! I could call that from zero to hero. Developers are now more satisfied with their Product Owners. Although the sample size with Developers is lot bigger than with the other two group, the numbers have gone up by almost 14%.

But unfortunately there are two sides in a coin. While we have put a lot of emphasis on the Portfolio and on Product Owners, we haven't maybe paid enough attention to core of the agile. Data is ruthless and clearly shows that our efforts in Continuous Improvement and Visibility to Work have not been too good. For this I will take personal responsibility. I'm currently both Chief Scrum Master and Manager of Releases. I have been clearly concentrating too much on one part and neglecting my other responsibilities for the organizational improvement efforts and making things visible. Point taken, now I know what to improve next.

As a statistical experiment this has been very interesting. My interpretation of the results is that they validate our hypothesis. The areas we concentrate on are affected and in a positive way. Having focus does pay off!

Behind Enemy Lines - Project Days 2014

Sometimes I notice I can be awfully prejudiced. I can't help but think about projects being all about waterfall. Hehe, I actually blame partially Lyssa Adkins about this (although in my things I admire her). Her excellent book Coaching Agile Teams talks about recovering Project Managers in a sense that they are far from being Agile

Based on this the reader may understand why I had my doubts when I was asked to give a presentation at the Finnish Project Managers' gathering called Projektipäivät. The event consisted of 20 different seminars in both Finnish and English. The one that I participated could be translated as 'Taking the Benefits of Agility into Use'. So even though the whole event was about a substance that I don't know much about, the seminar I participated felt like a safe haven.

The venue of the event was Dipoli, a building in Otaniemi, the cradle of technology in Finland. (I've also studied in Otaniemi, so it felt like a homecoming. :) ) All the presenters received a small bottle of Jaume Serra cava which I later learned was an excellent bubbling wine.

The first keynote was given by Ludovic Hauduc from Microsoft. He talked about the Future of Business Productivity and Project Management. Actually this was the first moment I gradually started lowering my defenses. He talked mostly about how the main characteristic of a successful project it that PEOPLE are involved. So it was not about the superior knowledge of the Project Manager. After the presentation I exchanged a few words with him and he said that MS Office unit is maybe not that agile yet due to the history, but they are on their path to change. Also I was curious about if they used SAFe model. But he told me they have their own way which is more of combination of different methodologies and once more emphasized the people aspect. I was very pleased about this message.

After the keynote I went to listen a seminar about Creative Utilization of Different Methodologies in a Project. Tero Huttunen from Tieto told about how the Project Managers face a big challenge with methodology knowledge. In the busy working life of today the PMs are under big time pressure all the time. And there are quite a few different methodologies out there: Agile, Scrum, XP, TDD, PRINCE, ABC, SAFe just to name a few. How could they find time to learn about all these and still have the project on tracks? (Personally I think it's about changing mindset. Giving more freedom and responsibility to the teams will make everyone's life easier. Of course given that the environment is accepting for such thing.)

Next Juhani Snellman and Elina Koskela from Reaktor talked about using Kanban in IT-projects. They also started their presentation by saying that they don't really have Project Managers and that they do everything in an Agile way. But the presentation was interesting. Kanban isn't totally new thing to me, but I haven't ever used it 'in production'. I merely know about the theory so it was nice to listen people who are actually using it (and even teaching how to use it.) My question to them was about statistics. They showed a nice cumulative flow diagram where they could show lead time and WIP. But when using physical boards someone needs to collect these statistics. From JIRA you can get that automatically, but yeah, using the real post-its has a nice wipe. (If you have distributed teams, working barely with physical boards is rather challenging.)

Then Mika Heikkinen from OP-Pohjola talked about how to use different methodologies in the big picture. Actually this was a bit misleading, because he was actually only talking about how they use SAFe. It was anyway really interesting. They have now used SAFe for over one year and have multiple Release Trains. Can't actually remember what was the percentage, but if I remember correctly they SAFe for about 40% of their projects. Could be less, could be more. But I claim that currently they might be one the biggest players in the SAFe field in Finland with their nearly 12k employees.

After the lunch break I joined the Leadership seminar. It might have been the most popular in the whole Projektipäivät event. The room wasn't the biggest, but it was really full. The facilitator, Mikko Babitzin from Tieto, had set up a second screen which was displaying the tweets with hashtags #projektipäivät and #onnistu2014. (Onnistu, which means succeed in Finnish, was the topic of this years event. Next year it will be growth which could be even more interesting.)

Vesa Rantala from Tieto shared his vast experience about working in foreign cultures and as a Project Owner. Main emphasis was once again in people and more on having personal relationship and interaction with them. Lack of asking question can also be interpreted in some cultures as not being interested in how things are proceeding. So by asking questions you signal your interest. Not really rocket science, but good to keep in mind.

Matti Vesala from Adare talked about social media and how to utilize and manage it. You don't need to be in social media, but if you accept the challenge you can get some interesting benefits. You can have your own prime time show. Not possible in television. :)

Hannu Salonen had selected 'Feedback is a Gift' as the headline for his presentation. It was both about positive and constructive feedback and about the challenge of giving and receiving it well. Really great thoughts and tips. Not really specifically for Project Managers but for anyone in a supervisor role. Or even for a leader who leads without any power over his/her followers (like a Scrum Master.) Actually I like this form of leadership the most and in the end it's the only thing that could work in today's working life. People are free to choose where they work and if you don't treat them well they can vote with their feet.

The final presentation in this seminar was given by Virpi Pikkarainen and Tiina Miettinen, two mothers and wives. (This was their own introduction.) Maybe the most important take-home I spotted was the fact that you cannot lead if you are neck deep in the details. You need to ascend a bit and take a helicopter view. Then you can see more clearly where you and the whole group should be heading.

The second keynote was given by Taneli Tikka, a serial entrepreneur who currently works in an internal start-up in Tieto corporation. They are developing the internet of things. Taneli's presentation was about transformational leadership. Good things start with Appreciation (of other people.) After that you can have Trust. Then if you throw in a bit of Enthusiasm and top it all with Learning you can be up to something really good. But remember to keep clear of being Passive or Controlling. Taneli was also referring to Deep Leadership, a methodology originally developed by Vesa Nissinen for Finnish Defense Forces. I wrote about it last summer. But anyway, I think Taneli's presentation was the most inspiring I have seen in a while or maybe even the best I've ever seen live. Charismatic person, still young and yet already long experience in start-ups and business in general.

The first day's program ended in a set of awards ceremonies. Awards were given for the best Project, best young Project Manager and for winners of Project Management Championship for students.

The second day started with the third and final keynote from Yrsa Sigurðardóttir. Her presentation was boldly named 'Project Management and Sex'. Well, it was really about genders, but this way she was able to draw more attention. ;) Currently there are no countries where it would really be beneficial to be born as a female. In Iceland the genders are closest but even there it's better to be born as male. But maybe things will change in the future. In her presentation she told about how they were able attract more women and young people into a project that was in really harsh conditions in the middle of nowhere. They made the camp really family friendly. The decrease in staff turnover was dramatic and results extremely good. Something to think about.

Later during the second day I actually got rather nervous about my own presentation. I made some final modifications and practiced some more. In the end I was rather happy with the content. Although my seminar had headers in Finnish, I wanted to present in English. Mainly because I thought it would have been recorded and I could have utilized that also in our internal communication (and for myself to take a look at how I present myself in public and how I could learn to do it better.) Unfortunately it wasn't recorded. But I kept the schedule, there was some time for questions in the end and feedback was positive. And I sincerely enjoyed. I knew my subject and I was happy about seeing people's eye contact. I think I was able to give them something.

The Roles and Responsibilities in an Agile Project and Organization from Toivo Vaje

But the final conclusion from the whole event was that projects don't necessarily mean waterfall. I think based on this event the scene has changed into something a lot more Agile. I think the two could live happily hand in hand. But I would have never found this out if I had not participated. Learning is everything.