The image above is said to be the most successful and powerful customer letter ever written. But what is the strength. To the musical genius, it might be a mystery but for all us who never successfully played an instrument we can just read the headline, close our eyes and immediately get a strong scene in our minds.The letter is discussed in the brilliant blog, http://www.neurosciencemarketing.com/blog/articles/your-brain-on-stories.htm, which focuses on Marketing and Neuro science. But what is a product without it's market image? Nothing. You might build the best software /product in the world but if no one has ever heard about it or if people thinks badly about it, what is that worth. Here are some well put advice from the blog:
Clearly, the narratives in the successful ads resonated in some special and universal way with their readers. We’ve all experienced moments of social discomfort, much like the would-be pianist who sits down at the piano only to have his friends laugh. And we’ve all had moments of pride when others acknowledge our skill or accomplishments. Is the narrative nature of the wording in “They Laughed When I Sat Down…” bringing these deep-seated memories to the surface to produce a more profound effect than had the ad simply suggested that we could impress our friends if we could play the piano?
My advice: to engage potential customers, write a vivid story involving your product. It’s worked for the best copy writers and most successful ads in history, and it can work for you.
There is so much emotions involved in user and customer experience. I cannot help but be amazed by this week's discussions concerning the IPad. Those who are talking about it simply loves it or they hate it. Not that they've touched it or used it but the emotions are already sky high because of the emotions that the brand Apple means for many. Apple are great at telling stories and yes, those stories do not apply to all. Quite the opposite; when you tell intriguing stories, they tend to either affects you positively OR negatively. If there is no chance of that high negative emotion, the chance of the positive one is slim. Just look at HP's design notebook in pink and red.
Dev System B: – Yes, and you also need info BBB, so we'll send that down to you. For me, that is so confusing. What is Up and what is Down in an integration? I've up until now seen UI as above the business and database layers, but these discussions are making me unsure. Or perhaps it's just my developers pulling my leg and having a laugh on my behalf.
It’s winter here in Stockholm and I’m pretty tired of the cold and most of all; icy pavements. Since I run to work at least twice a week, the icy roads are an annoyance. To put it mildly, I get pissed every morning when I try to spot which areas are the least icy in a dark, unlit, Stockholm.
What I could do is try to solve this problem. I would get involved politically and work for these roads being winter kept. That would solve the problem, but it would take years, would perhaps never be realized and a big risk is that if I focused my time on this, I would perhaps not have time to run. And my objective was to be able to run to work.
Another solution is to continue running, using studs.
I don’t say that the first solution is wrong, but as Dan & Chip Heath points to in an extract from their new book Switch, it is easy to loose the goal if you try to solve the COMPLETE problem. This is of course one of the core values of agile software development. Trying to make the complete specification before you start implementation is just one other example.
It also goes hand in hand with one of the ideas presented by Anders Colstrup on Friday’s seminar on Inspiration – you need to focus on the objective and every day take a step towards that objective.
If the problems in your project seem unsolvable, and hopeless, read the story of a man, struggling to help undernourished children in Vietnam. Your problems have never seemed more trivial.
Returning to Anders Colstrup’s inspirational seminar on inspiration, I focus my attention to objectives and goals. Do we need objectives and what is a good objective?
This post shares a lot of ideas from previous posts, covering 7 habits, scrum and commander’s intent. But Colstrup somehow got a new twist to the importance of objectives.
Learning how to swim under water
He started by sharing a story. Read it and reflect.
A girl was learning how to swim and at age 8 had become a skilled swimmer for her age. She had decided to take one more swimmer’s level, after which she felt she was done. One thing she needed to do was to swim 11 meters under water.
Having not had any problems up until then, she jumped in, swam under water but surfaced just after 7 meters. Up she went and then down again. Surfacing, she could see on her father’s face that she hadn’t succeeded. Now the tips from the others started coming. She should swim until she ran out of air, take three more strokes and then surface. She shouldn’t ascend directly upwards but trying a forward angle.
She tried once more but failed. Now, she was almost in tears.
What did Colstrup do?
Think what you would have done.
What he did was that he placed a person 11 meters from the descend. The girl just had to swim to the person and then ascend.
She succeeded immediately.
According to Colstrup, and I agree on his finding, the reason for the girl failing was not her lacking the skills. She couldn’t see the goal. Under water, you can see perhaps 30 centimeters so how could she know if she has swam 11 meters? By placing someone in the water, he made the objective concrete and visible.
I can only agree from my own findings. One of the most successful projects I’ve been a part of, we had a very clear picture which we all could touch and understand.
The makings of a good objective
Objectives must be there and they must be concrete. You must know if you’ve reached them.
If you go back to my previous post and read about the negative bunch, those not performing at their best. How many do you think are negative because the objectives are not clear or reachable? Colstrup was more direct in his critique of managers. Bad leadership.
But if someone does not share the objective? Colstrup worked with a team, and found that the players didn’t feel anything for the management’s objective. What he then clarified what what were the players objectives and if they were combinable with the management objectives. As they were, he could translate and relate them. If we together reach X, can’t you work at Y at the same time?
He then made the objective very concrete. The guys then got to build a number of small tokens, visualizing the reached objective.
What was also very interesting was how much he works with the mindset of placing athletes in the moment of reaching the objective. “When you’ve won that contest, where will you go for dinner? What clothes will you be wearing then? What will be your next competition after that? Will you get some new gear for that competition?”
Again, I cannot help but agree. When I’m completing a competition, I start thinking about what I’m going to do when I’m done. How long I will sleep, how much and where I’ll be dining. What form of exercise I will focus on then, etc. And also, the only time I’ve broken a competition was when that image disappeared from my head.
Working towards three objectives
He also warned about just giving one objective. You need three objectives, a Barrier braking, a Realistic and a Safe:
The safe objective is when you are satisfied with the performance. You didn’t do anything new, but anything worse than that is not acceptable. The realistic objective is somewhere you haven’t been before but it should be reachable. The barrier braking objective is something that you thought was impossible, but that is because you and everyone else sees that there is some barrier reaching this.
Why do you need three levels? Colstrup sees the objectives a a target area and the larger that is, the more do you have to aim for. But does this not mean that everyone will focus on the safe level? Well, Colstrup thinks that again that is where leadership comes in. It is a leader’s role to help the crew aim for the realistic objective, knowing that it is ok not to reach it.
If you don’t have the safe objective and the realistic objective cannot be met, is it a total failure then? No, not if at least the safe objective is met.
What about the barrier braking objective? Well, that serves many purposes and one is to enabling the participants placing themselves in the situation when the realistic objectives have been met; where do we go then? Also, there are often mental barriers which makes things seem impossible but by talking about them and de dramatizing them the mental barrier can fall and even the barrier breaking objectives can be reached. Colstrup does not see it as a coincident that when there is a record which is “impossible to break”, and it has been so for ages, when it is broken, it is broken by many and repeatedly.
By having this large success zone, Colstorp hopes that people can be more in the Learning zone:
If you’re just working for the safe objective, you tend not to learn anything, if you are going to reach the realistic objective, you need to stretch your capabilities and learn new skills. But if the objective is set to high, you stop learning and instead turn to panic.
Think again about the negatives. Where are they? Where do they want to be? Are they in the panic zone and are therefore negative? Or have you never reached your goals so that they mean nothing, and people are in the comfort zone since “nothing really changes anyway?”. Or does the objectives change all the time?
When it comes to barrier breaking objectives, I again as so many times before turn to a sequence with Lance Armstrong. Even if you think he’s been using illegal substances or hate his guts, do look at these 30 seconds. If you’ve missed the story, Armstrong was diagnosed with cancer and given 10% (!) chance of SURVIVAL. And here is what he said at the press conference, sharing this information with the public.
What was his objectives? Well, given the odds there was no “safe zon”, but we could say that the safe objective was survival. But Armstrong also had a next level: he was going to beat the decease. But what is truly exceptional that he also in this the hardest of moments had a barrier breaking objective: return to professional cycling. Cycling is a endurance sports, and recovering from cancer in the lungs to get to a professional level must have been seen as impossible. But he did it and by breaking this barrier, he gives hope to million of cancer strugglers out it the world: it is possible to work for not mere survival!
In his book, It’s not about the bike, Armstrong often goes back to these objectives and now when reflecting on it, he actually states that he needed all these levels of defining success during his hard trip back, to life and to professional cycling.
We are only lucky if our challenges are not including life and death.
But it’s not enough just to have a meeting, discussing the objectives. We must keep that objective in our heads, every day. Colstrup gave the indivual members of a team an illustration of the objective. And for each day there was one line where they had to place their signature if they agreed on that they understood, wanted and worked for the objective.
Symbols and concrete representations of team and risks
When you work toward common or shared objectives, Colstrup believes that you need not only a shared goal, but a sense of we feeling and a common symbol, something that shows how you act. He told us about teams picturing themselves as A Train or a Stove, which attributes where examples of how they were as a group.
If objectives must be concrete, the threats must also be concretized and de dramatized. Again, Colstrup uses concrete representations for the threats so that a team can “destroy” a threat in their mind.
To be able to succeed, you need to know we mean with success and then we have to work towards that every single day. Objectives which we have a concrete presentation of are easier to work towards and objectives which becomes a part of every day activities are the most powerful. Individual objectives must be translated to team objectives.
And if you get the chance to listen to Colstrup, take it!
I’ve just gotten home from a really inspiring seminar, held by MIL Institute here in Stockholm. The title was I want to!
Anders Colstrup gives classes in athletics psychology, coaches athletes, mainly professional golf players but are now also coaching business leaders. I can understand if he’s successful. I was hopeful going to the seminar but it was better than I could ever have imagined. I guess I’m not the best of mothers writing this blog post fresh out of taking him from daycare, but I need to summarize. So here goes.
If we look at motivation factors, they can be internal or external, they can be positive or negative:
The idea behind Colstrup’s coaching is creating the bottom left corner – how to build internal positive motivation.
Colstrup asked us to spend a couple of minutes discussing what motivates us and then we could share our views. Besides listening to the different reflections, it was interesting (as Colstrup pointed out), that you get motivated by talking about motivation. And this is also why Colstrup works so much with the constant talking of the motivation factors – the actual talking builds motivation.
Colstrup then discussed the difference between motivation and inspiration. Motivation is when you get hold of an idea and you decide to reach a goal. Inspiration is when an idea get hold of you, and when the idea in itself is guiding you. Feeling inspired is a reward in itself for those who share that feeling.
Mihaly Csikszentmihaly talks about flow and has also written a book on the subject:
It was a bit funny when he mentioned that book since it has been on my Want To Read List for a while. Mihaly (I’m going to use his Christian name here for some reason) describes flow as feel that your capability is enough and that you can focus on the exact now to reach where you’re going. You know exactly what your next step is and can focus on that while at the same time reaching your goal. Colstrup mentioned successful climbers as excellent examples of this but many of us has felt The Flow.
But the flow is not only about having the capability. There must be a challenge. There must be an objective and you need to balance that:
Colstrup then asked us to think about what we feel when we work. Again, he showed a matrix:
The matrix requires some explanation. The “positive” and “negative” is more how likely you are to be working for common objectives. People can of course be negative if they believe the objectives or the road is “wrong” but some are more rooted in the negative tree and would probably be negative independent of the current objectives.
Colstrup said that his experienced gave the following numbers in many organizations:
10% are low performers
70% are average performers
20% are high performers
The lower 10% are mostly on the Negative row of the matrix. Depending on the culture, managers tend to focus on different groups in the matrix. In Sweden, many managers spend too much time on the negative crowd, but what message are you then sending? That you get more attention if you’re negative? A good manager spends time trying to help those who are positive. The active ones might need some cooling down and the passive might need some spice. Focus your attention on the wanted behavior!
So, what to do about the negative? Well, what you can do? Try to figure out why they act as they do. In too many cases the basis for a negative attitude is the leader himself.
Tomorrow, I’ll continue my notes with some findings concerning the importance of goals and how to form them.
Bob Maksimchuk’s interesting article Are We Agile Yet discusses the problem with defining if you are agile enough.
We like categorizing stuff. Is it an A or a B? When something is somewhere in the middle, we struggle with it. But that magic moment when you are classified as agile does not exist. Perhaps there will be some test sometimes, with which you can be qualified as agile. But I hope not since I think it would be quite useless.
When someone asks if you’re agile, you can explain the problem by comparing with a similar question:
When is a person considered an adult?
The question is not that easy to answer. Yes, you could say that legally someone is adult by the age of 18 in Sweden. But that is in Sweden. And in certain circumstances. You can vote but not buy alcohol. And it’s even harder when you look at specific individuals. Is she an adult? What about him? And when did he become an adult? Again, it’s hard to be specific. And someone can be an adult in some aspects and still behave as a child in other situations. My mobile phone signal is the Star Trek The Next Generation communication signal. Childish, perhaps. But does this mean I’m not an adult? And if you look at people suffering from dementia and showing a behavior we consider childish, does this mean they are children?
As with the question of adulthood, the question of agility is a question of scale and aspect. Maksimchuk even offers examples of criteria. But as with adulthood, there are no strict rules of which criteria are useful in your environment.
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?
One aspect of the agile community which I love (or is it all software developers, or people, I don’t know) is the eagerness to share and help out. As I explained in a previous post, I have no file archive so you needed to e-mail me to get my sample Project files. But Jochem Bökkers volunteered to help me out. So, now you can download the files from here.
Well, the files are nothing special. In the file Project1, I just added the settings described in Tutorial Part 22. I’ve also created a number of sample files, showing how Project can be used through out the project.
Get back to be if you have questions and input!
In this file, I have used the Resource Usage View. In the diagram (right side) I’ve changed the time scale to visualize weeks and changed so that also Baseline work is displayed. This means that I can compare my original plan (baseline work) with current plan (Work). In the left table, I’ve added the fields % Work Complete, Baseline Work, Actual Work and Work (planned). This is a view which can be used to see how resources are used and how we planned there were going to be used on a weekly basis.
In this file, I’ve used the Resource Usage view, changed the time scale to view weeks and changed the right side so it shows actual work. This means that time reporting can be done directly in the graph. On the left side I can also adjust Work (the planned work) and compare plan (work) with original plan (baseline work) and actual work.
In this file I’ve used the Gantt chart but changed the diagram so it shows weeks (you can guess this is my favorite). I’ve made a split to the view so I can select and edit specific sprints. To the table, I’ve added some fields so I can track progress. In the example, I’ve also visualised a cut sprint and an added sprint. Sprint B was cut short and Sprint D was added. I can see the added sprint by it lacking Baseline values.
In this simple example, I’ve just added two versions of a project and I’ve used the Gantt chart but have some added columns (Cost & Work) which is useful to the customer.
This is a simple template which uses my common settings for a new project. Note that I often change views (as can be seen in the other files) so you will have to customize your views after your needs.