Is it a MVP?

The word MVP (minimum viable product” has spread like a virus and can definitely be seen as a meme. But like terms such as “energy” or “quantum physics”, people sometimes use the word without really understanding how Eric Ries explains it in Lean Startup. So, here is a quick test you can use the next time someone uses “MVP” or “Minimum Viable Product”

Random rantings on randomness

I may be a bit black and white here, but I often find that in the question of measurements and estimations there seems to be two clear sides and the battle is tense:
– Measure everything! You get what you measure! If you can’t measure it, don’t do it!
– Measurement leads to people doing what ever to get high scores, not high results! We spend so much time on measurements that we don’t have time to do any changes. Depending on the measurement point and method, you can present any result.

So where am I? I see myself somewhere in the middle and I cannot decide where my heart is. Probably nowhere. So hence I turned to randomness. Or rather, Audible did. I have an Audible subscription and every month I get a new free audio book and since we were on holiday, I took the time to get some new nice reading. I seldom have something special in mind and pick something that sounds interesting. Since this was the way I found Predictably Irrational and Made To Stick, I find this method very good. I find books I would never have selected otherwise and many times I’m very happy with my choice. And this time I found Drunkard’s walk by Leonard Mlodinow. I was directly hooked. Math was never my strongest subject, but here I was drawn into the history and almost magical world of randomness. The book also covers how the workings of our brains clashes with the workings of randomness. We are pattern seeking entities and randomness is random.

To summarize, what is hard for us to grasp is that there is a small chance that something specific improbable will happen to us but very probably that something improbable will happen. As an example, the chance of you dreaming of your aunt the night before she dies probably feels improbable but the chance that someone of her many friends and relative do is not as improbable as one might think.

In the first edition of the Ipod, Apple spent a lot of energy making the random song selector working randomly and they did such a good job that people complaint about it not being random. Again, the chance of The Winner Takes It All being played twice on your morning jog is not that high (if you have that song and loads of other songs on your device) but the chance of any song being played twice is not that low, given that you have that song on your device. With a true random song list, it is not unlikely that one song is played every time you use your device. But when you change the question to what the chances that specifically The Winner Takes It All is played everytime, the chances drop dramatically.

For you math geeks, this is nothing new, but for me so thoughtworthy and there are some aspects of randomness which I will continue bothering you with.

So I leave you with a question to the next time. Imagine that you are participating in a game show. You have three doors in front of you and behind one door, there is a wonderfil sportscar. The game show host tells you to pick a door. The game show host, who knows where the car is, then opens one of the doors you didn’t pick, knowing that he opens a door behind which there is no car. He then asks you if you want to stick to your choice or if you want to change. Should you?

Are you killing sparrows?

For Mao, the increasing of the crops was crucial for his success: he not only needed the crops to feed his large population but he also wanted to build a financially strong empire.

So he asked (himself or others, who knows?) what he could do in order to increase the crops. What lowered the output and could be controlled? One answer is pests of different kinds. Rats, sparrows and a number of other animals were identified as enemies of the state, feeding themselves on the Chinese fields. Large campaigns promoting the killing of sparrows were created and the population followed his call.

Was Mao correct? Yes, the sparrows did pick the fields and when the sparrow was almost removed from the fauna, this problem was removed. But there is a big but… The sparrows might have picked the fields but they also killed other pests and with the sparrows gone, this created a much bigger problem than the sparrows had ever been.

Another time and another continent. In Predictably Irrational, Dan Ariely tells us about the Israel daycare which had a problem with parents picking up their kids to late. To solve this, the daycare tested introducing a fee for late pickups. The effect was that parents started to see late pickups as an add-on to the product and the late pickups increased. Realizing that they’ve created a bigger problem, the daycare removed the fee, but since the social barrier against late pickups had been removed, the problem increased even more and took years to overcome.

When you have a problem like this, it is sometimes easy to think that you can just test something which seems plausible to lessen the problem. Lean, agile and scrum all points to this testing of small plausible improvements but what they don’t talk about is the risk that you kill all the sparrows and create a much bigger problem and a problem which is hard to remove. There is no CTRL+u in some real time situations. I’m not change resistant here, but I only lack a discussion about these risks and how they are avoided. I do think more people than the daycare and Mao made these mistakes, but who tells us about them?

If I would dare to guess what we can do to avoid killing the sparrows it is higher competence (the Mao example) and a lowered belief in the rationality of men. Behavioral Economics shows us in research after research that we are not rational but think we are. This overconfidence in people acting rational makes us create solutions which assume that people act logical and rational. In the daycare example, they assumed that the rational and logical solution for parents was avoiding the fee, but this is not how people work.

Looking forward to more discussions on how modern software development handles change without killing the sparrows

Learnings from Technical Department

One of the things which drew me to TUI Nordic was the work with Lean, which is an integrated part of many departments of the organization. One of the departments is the technical department, which also received a third place in the latest Swedish Lean Awards.

We therefore found the time to hear some of the insights from the technical department: how can we who works with software development (most specifically web development) learn from another department in the same organization?

It was really interesting to see the similarities in challenges in the processes but also see potential improvements we would never have considered had we discussed with other software developers. Not only is this a completely other industry, but also the age of the business and the tradition is completely different.

One of the many highlights was the second opinion. In many cases, another person should make an inspection of the work done. The basic rule is that this is needed if the change is critical but this also has a scale. If you do something to one engine, then the need for inspection is smaller than if the change is done to both engines. This is thought worthy when it comes to code reviews. But then we have the case when an inspection is wanted but not necessary and the technician is alone. The rule then is for the technician to take an appropriate break. What that is must be evaluated from case to case and the technician must for himself make an educated estimation of what that it. In some cases it can be a coffee break but in some cases many hours may be necessary. Thought worthy.

Do you have another department which works comparable processes? Do find the time to hook up and share knowledge. And who knows? You may also learn to know some really nice colleagues as well?

Survival of the fittest does not mean designing the smartest of solutions

Having followed my husband’s, Anders Hesselbom’s and Marcus Ahnve’s discussion about the evolution saying of “survival of the fittest” and it’s baring on software development, I want to clarify some misunderstandings concerning “survival of the fittest”.

Many believe that survival of the fittest equals the winning of the best solution. The best and the strongest survives the competition. But that is not what survival of the fittest mean in software development.

Look at the vagus nerve in a human. It starts up in the brain, goes down under the aortic arch and then back up to the throat. Is this the most elegant possible solution to building that nerve? No, only an idiot would design the nerve like this if he started from scratch. A person on which the nerve goes directly would probably be considered as better or stronger. If you consider that the same type of problem of the rerouted nerve exists in for example giraffes, you can see the extent of the problem.

So, what is survival of the fittest? When the ancestors way back in time lacked our long necks, one or a number of individuals mutated so that their necks became slightly longer. The nerve became a tiny bit longer too, but the upside of the longer neck was bigger, so the group with the neck survived long enough to reproduce in greater amount than those without it. And step by step, the necks became longer. The side effect of the elongated nerve was always a lesser disadvantage than the longer neck. Of course, after many generations we had that absurd situation we find today, but the chance that a mutation surfaced where the nerve was instead directly routed and the rerouting was successful is very slim. And since the nerve as is does not result in an enough big disadvantage in reproduction, the design remains.

If you’re a software developer, close your eyes and relax. Then think about which system and which code the solution of the vagus nerve remind you off. Is it that neat and beautiful solution you’re so proud of? Well, I hope not. It is probably some kind of legacy code or legacy system. It was probably a good solution way back, when someone made a quick and dirty solution to a simple problem. The solution was just temporary, but remained and steadily became a bigger and bigger headache.

What you really would want is to cut that nerve, rebuild it in a smarter and more future safe way. But your manager might not see it as a problem. It works, doesn’t it? Which are the risks with cutting the nerve? Are you sure that we will survive and that things will be better afterwards?

Evolution is The Greatest Show on Earth. Wonderful to see, amazing when it comes to giving birth to amazing solutions, but don’t be so sure that you have the nicest and best design.

Who is the corporate hero?

Take a good look at these two images.

 

Yes, she looks a bit freaky, but besides this. Which person(s) would you classify as a hero?

Jeffrey Phillips asks in his blog post, Why is fire fighting more valuable than avoiding fires.

And the answer is in these two pictures. It’s not heroic to do the cleaning. For many, it’s very satisfying to feel like a hero. You get a lot of credit and recognition. In many cases, the people preventing fires are considered negative, backwards thinking and boring.

We all know that we need both but how much of you’re time do you spend rewarding the fire fighters and how much time do you spend on appreciating those who are preventing fires?

Being a part of TUI Nordic means that I have the chance to work with TUIFly Nordic, our air carrier. In their culture, the picture is the opposite. Zero tolerance for failure. Constant follow up and process improvement is built into the company walls. There is a sense of constant urgency. An urgency to improve and an urgency to prevent that fire from ever happening.

Are you consistently bad?

We need to be consistent! We need to be reliable!

Aren’t that nice?

But then consider Sanjiv Augustine’s wonderful statement from APLN:

(Source Jesse Fewell)

A team can be consistent and reliable and still deliver garbage. If you always deliver garbage, you’re pretty predictable, aren’t you? You can truly rely on them delivering garbage. Business as usual.

I have a childhood friend who works with a supplier who he really can count on. He can count on the system failing after each upgrade. He can rely on the support functionality not being able to fix his problems after the delivery and he can be sure to have a lot of angry users on his back. After each upgrade.

What bugs my friend the most is not the individual problems. It’s that no one seems to care that his company loses money every time they upgrade the system. He’s annoyed by that nothing gets better. He feels like the supplier sees the problems as normal. Well, they are since they are consistent, he laughs with panic in his voice when we talk after an upgrade.

I’ve told my friend that he should abandon the supplier, for his company’s sake but mostly for his own health’s sake. And this my recommendation: if you work with a supplier who sees garbage deliveries as the normal state, get out. And if the supplier thinks there are different problems each time and blames this and that, well that is no excuse. If the process consistently produces garbage, it does not matter if the garbage is of type A one day and B the other. It is obvious that the process allows the garbage.

If you instead work at that supplier, you should do something about it. The competition is hard out there and blaming this and that does not help. Look back at your latest deliveries and figure out how many critical errors your company has introduced to your users lately. And no, don’t blame the integrators or the installation guys or even the users. Look at the end product.

Are you proud or are you lining up arguments why you were not to blamed for these incidents?

Jesse Fewell have on his blog presented how Sanjiv Augustine has described his idea of an Agile PMO and how such a solution can fuel continuous improvement.

This is just one take on the problem and it’s handling. Because this is not a problem what can be solved, it’s something you need to work on all the time and on all levels. So what if you have 90% code coverage, work test driven, use scrum and have continuous integration? These are great tools among other tools but if you still work in the garbage spreading business what’s the use of you mixing the garbage with some fine wines?

The failure of lean in Service

John Seddon describes in this interesting presentation why standardization of work can (read: probably will) increase costs, why introducing “lean” into service organization can be so contra-productive and why “tool heads” have given lean a bad name. By doing real research, walking the process instead of describing it in a conference room with a lot of post its is the path to lean service delivery.

The sound is really poor but it’s really worth while.

http://www.infoq.com/presentations/rethinking-lean-service

Are you productive or just sub optimizing?

I’ve previously posted a number of blog posts where I discuss the dangers of measuring individual productivity. If you believe in The Theory of Constraint, the questioning of this type of measuring becomes natural.

Mendelt Siebanga gives some well put examples of why he also thinks it’s contra productive with measuring individuals but he also discusses how you can increase productivity. A short, well put blog post.

1715

Is not a year (well, it’s of course a year, but I don’t refer to that here) but a loosely coupled network of Swedish women somehow engaged in software development and who have a special interest in agile and lean values and leadership.

Yesterday evening was spent in their wonderful company. I seldom like groups or networks aiming at a physical criteria, but sometimes those can give you special experiences and questions. By keeping this as a quite small group but with very different perspectives, I hope and believe that we can all learn and teach something.

We’ve now formed a LinkedIn group, where we’ll discuss issues between our meetings, which I hope will be once a month.

Thanks, Ulrika Park, for inviting me, and thanks Sara Manding with Valtech as the evening’s sponsor. And thank to 1715 for a wonderful evening.