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”
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?
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.
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.
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.
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.
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…