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”

Taking care of people and business

It is for a good reason that the agile movement should be based on the agile manifesto – I think it’s a sign of strength to be able to state what basic principles you base your work on. But why do I find this so important?

Independent of if your process is packed with rules, artifacts or roles or if these things are kept to a minimum and independent if you use agile or waterfall, situation arise when the process and the rules make more harm than good. If you then have shared values, these can guide you so that the rules don’t become more important than the outcome. “This is by the book” is in my world a sorry excuse for not having good arguments for why you act as you do. Even if something is in a book, you should not hide behind that. Of course there are corporate rules which you must decide to follow as being part of an organization, but values can be helpful in stopping people using these rules for their own purposes, that being laziness, fright, power lust, uninterested, uncertainty or what ever is behind hiding behind books and regulations.

It is my opinion that processes and rules should help us reached the highest sustainable productivity in order to reach corporate objectives. In order to do so we need to take good care of our business and very good care of the people which are a part of this business: customers, partners, employees, etc. Not that we should be afraid of hurting their feelings and therefore tiptoeing around problems (this is in my opinion quite the opposite of what you should do) but every time you hit someone with “this is by the book” they will not reach the highest sustainable pace. They still don’t understand. There is also a good chance you kill their spark. Therefore People over Processes. In the agile movement we care about the people. That is why I agree that we should stop using the word resources and this is why we have loads of habits in the agile processes. But they are not there because they are in a book, they are there for a reason.

This is perhaps also why I now here so many complaints about methods like scrum. I hear more and more getting the feeling that many scrum implementations have lost touch with People over Processes and are holding on to habits which are not the best for the long term or the short term productivity and seem to be there just because they are in a book.

But I’m not working for checking off that we’ve followed all the rules in a book. I work for making holiday dreams coming true. What do you do?

New project, new examples

As of a couple of days ago, I’m splitting my time between two projects. As it happens it’s also on two different locations here in Stockholm so I’m happy that we have a warm autumn here in Stockholm so I can ride my bike between the projects, but what is really fun is that we’re using Specification By Example in both projects.

One major difference between my work will though be that I’m a core team member in my “old” project, while I will be an outsider/stakeholder in the new project. I’m supporting our product owner and writing examples but not be an active team member. This will very interesting to experience in combination with Specification By Examples – does example writing business people have to be part of the team?

This means that I’m that fortunate that while learning this I get lessons in two rather different projects and from two rather different styles of implementation of the examples.

Today, I had the first specification session with the new project and we started of discussing what we want to catch in the examples in the project. We then started writing examples, both some that are included in the scope of the original user stories but also the framework for examples to be implemented in later stories. Tomorrow we will test the examples on the team. This will be really interesting to see and hear.

Another difference between the projects is that we will be using a more conservative form of scrum in this project which is also very interesting when comparing with the other project where we have used something more of an almost post agile process with few fixed artifacts and more a continious adaptation of our process in order to improve productivity.

Is a clear objective a clear must for success or is the opposite nearer the truth?

If you search for “objectives” and “projects” or some related terms, it is easy to get the opinion that everyone and everything is showing that clear objectives are essential to the success of any projects. If I’m to be a bit mean here, I would say that some seem to think that as long as you have clear objectives , success is a given.

But then again, if you really think about it: clear objectives are not the same as success. I could have the clear objective of running a marathon in a year but without a million different things such as actually preparing, getting enrolled (or measuring the distance oneself), you will not stand on a marathon finish line within that time limit.

And now Philip Runsten, a Swedish scientist actually states in his newest research report that clear objectives can (and probably will) create more misunderstanding than more fuzzy objectives. Being a skeptic, I cannot but salute Runsten for challenging this deep faith in clear objectives which we can find in our modern society.

Runsten has in his research looked at what makes competence intensive work groups successful. I haven’t read his report yet, so this is just what he writes…

He states that in his research he finds that teams that are forming clear and common objectives for the group are less successful than those which lets individuals in the group form their own opinions about the objectives. They all look from their perspectives and try to get their objectives prioritized, making this process alive during the completion of the task. If you instead start with defining clear objectives, these tend not to be questioned, which is negative for the team’s productivity. If you have clear objectives, it is often assumed that these are owned by a leader and not by the group collective.

True or false? Well, I’m going to at least do some reading. The paper (in Swedish) can be downloaded from http://hhs.diva-portal.org/smash/record.jsf?pid=diva2:420968.

Personas and Siri

Yesterday, one of the team members introduced me to the site http://shitthatsirisays.tumblr.com/. I’ve never been a big fan of these intelligent guides, probably because it does not suite me as a user so even if I do find myself with an IPhone using Siri, I will probably not use that service.

But what is interesting with Siri, from what I can see from the examples, is that Apple must have used personas which made fun of the functionality and actually built it with these guys in mind. Not only do they try out the edge cases, but while doing so they are active online and this has a viral effect. My friend told me and now I’m spreading the link on my blog.

And the examples shows that Apple does not only realize how their users are, but they also show that they are not so super serious, allowing us to make fun of them and ourselves. Again, Apple is to be saluted. Darn, they are so good.

Writing examples, take 4

Today, while starting up our fourth iteration, we again work with our examples. Our coach, Jocke Holm, is now stepping back more an more, enabling us to take more and more control. The situation is similar to being the kid learning how to walk. It is so nice to be carried around all the time but you at the same time crave the freedom of making it on your own. I salute Jocke for making it a smooth ride for us: it is not easy seeing your kids fall and hurt themselves but the hurt they feel if you haven’t allowed them to doing so under controlled situations is so much harder.

This time I had prepared myself and actually written something of a skeleton for an example. Jocke told me not to show it straight away and this was a good thing: I new some of the tweaks I wanted to catch but I still wanted to see if the guys came to the same conclusions as I did.

I then presented the guys to two of our new personas which we have developed at TUI Nordic. We have more personas but these two have very different objectives and behaviors when consuming the services we are developing for them. Together we just made some quick notations of their different needs and then we headed for the examples.

One of the guys started writing about the happy scenario and when we felt comfortable about this, I started adding some of the complexities which are necessary to exemplify the features. The guys ended up with a semi-similar example compared to my first draft. The differences were important and good.

It’s a good thing for me to do some initial drafting before discussing with the team since I then have thought of some of the most important details but it was also good to start from scratch while working together. I actually found that the scenario was not focusing on the thing I had expected and this is not the first time I find myself in this situation while working with examples. The methodology  really turns my head sometimes, making me see what the real issue is instead of assuming that the problem is how the wanted feature is as it’s explained by the customer.

Leadership as a service (LAAS)

What’s your occupation?

If you are like me you don’t give the same answer to children and adults. To other adults I say stuff like “web development”, “User experience”  and the name of my organization. To kids it’s a whole other thing. I work with airplanes and Bamse. And to tell you the truth, the answer to the kids is in my opinion actually a better answer.

I don’t know if it’s true, but I’ve heard that the founder of Swedish H&M said that he wanted every employee to say that they were selling clothes when asked about their occupation. He wanted everyone to feel that they were also part of that big process, independent of if they were coding business logic or cleaning toilets. If you don’t know that your work should lead to more sold outfits, then you have a problem.

But then again; how silly isn’t that? I don’t work with the actual planes in any practical sense and even if I’ve walked the Gemba in one of the Little Hop (Lille Skutt) costumes (don’t share this info with your kids), I don’t daily with Bamse. I’m working on improving our webs. Or am I?

You could, as we see it, realize that if the purpose is to bring these kids and their parents on planes to Bamse and get there with a smile on their faces, there is so many things that must work. They must buy the trip, get the transportation, etc, etc. And what happens if we sell them the wrong trip so the parents are upset while arriving? And how joyful will the greeting from Bamse be if he has the wrong info about when the kids are arriving?

At TUI Nordic we talk about giving service to each other in order to maximize the service to the customers. In other words: in order to secure that the greeting from Bamse is the best, the Bamse guy should have been given the best service from us, his colleagues. This is called a Service Profit Chain.

This also calls for another type of leadership. Instead of staff servicing their bosses with completed work, a manager should see himself as providing a service for his staff. Leadership as a service, in other words. Interesting and difficult but also rewarding.

Or perhaps it’s just me wanting to say to kids that I work with airplanes and Bamse without lying to them…

The tipping point of agile in an organization

I think I’ve always worked with agile values and even after this becomes so outdated that it’s embarrassing for me and everyone around me, I guess I will stick to those values since they are near and dear to me. Getting stuff to work for real, working as a part of a group, collaborating and acting on change is both my strengths and my weaknesses.

But when does an organization become agile? “Are we there yet?” as so many kids have asked their annoyed parents in cars and planes and trains all over the world. I guess that large organizations are always and never there since there where always be areas where the agile values are melted into the foundation and areas where this is not an option. Yes, that goes for Google and its likes as well.

But what I find interesting at work right now is that we’ve somehow reached a tipping point where agile is no longer the odd case but something you can actually expect people to know and embrace. Not everyone is agile, interested in agile or wants to be agile but that is, as I mentioned, expected in any organization or group.

I guess there are many reasons for this and I cannot at this moment say what actually made us reach a tipping point. I don’t think anyone standing at any tipping point really knows that if the tipping point is not super obvious.

So what is next? Adapt to change, collaborate, working for working software, be part of a team and having loads of fun while doing so.

The annoying personas

Some say that objectives should be SMART, Specific, Measurable, Attainable, Realistic and Timely. But goals should also be (to be really useful) something you could say a NOT in front of and it still makes sense. This is the reason I like the agile manifesto: it says for example Working software OVER documentation. Since someone could argue that a lot of documentation is more important than working software, this statement becomes so important.

When creating personas, I would argument that the same rules apply: in order for personas to be useful they must be so formed that you cannot please them all with your features. This is one of the reasons I like our personas: they are based on our segmentation model which stresses motives and personality. It is so easy to fall back to different types of users, defining them as people. But a person is more than his user behavior. He has values and motives.

A couple of days ago, we were working on a number of functions and how our personas interact with these functions. I was taking the role of one of the personas and I often ended up with not seeing the value with that function in this role. Suddenly one of the participants just stated:

– I don’t like that X. He’s arrogant and grumpy.

And there you go. Some people are like that when they are interacting with your brand, your product and your functions. If all your personas are likable in all situations and they always love all your features, I think you’re missing out on some of the real values of personas.

Ignoring the redness of a stick

The best teacher I’ve ever met had of course many talents which all together made him a brilliant tutor and one of them was teaching us to be aware of the distraction of details while solving a problem. While writing examples today, I again was struck by the importance of this.

This teacher, who gave math classes in High School made his own math tests and the last task was always something special. In order to solve that you need not only have grasped the lessons but you also had to be really clever. I must say that I, as a mediocre  math student, seldom cracked his last question, but I always looked at that first when taking a test and it was always a pleasure seeing him after the test explaining how to solve it.

One of his first tests included this question: given that you have a red, one meter stick. What would be the smallest dimension for a box to hold that stick?

This still requires some thinking for me to solve but the most interesting part is that he wrote that the stick was red and many students focused some of their problem solving on this fact. Why does he write that the stick is red? How does this affect the dimensions? But the answer was that he intentionally included facts which were distractions. He said that one key area of problem solving is understanding which facts are relevant and which facts to ignore. I guess some of the students hated that… But it is an important lesson in real life, as all software developers (should) know.

While writing examples, I struggle with this all the time. I try to think out all details and often get stuck writing examples which covers all these facts. And then it hits me: that fact is just the redness of the stick. It makes the problem solving hard but it is just a distractions. When I can ignore that fact, the examples becomes so much simpler to both write and understand.

My old teacher died many years ago, but his teaching stays with me in my daily work. What a sign of great leadership.