Archive for category Social
Innovation – the heartbeat of products
Posted by Ram Sundararajan in Social, Values on July 31, 2009
Lately, I have been thinking and reading articles about innovation and innovative companies and I finally got the time to jot it all down over the weekend. And here are my thoughts…
Many companies want to be perceived as innovative. But are they really innovative?
Part of any process in a company should be to focus on products, the end goal that forms, guides and informs innovation. Wanton innovation is wasteful. There must be something in the product to pull it all together.
There are many companies that develop new technologies and go in search of problems for those technologies to solve. Take the internet bubble for instance; it was defined by this kind of thinking. It was a carnival of worthless innovation. Half baked business ideas and models pumped into money burning concerns in a misguided attempt to make quick bucks and beat the competition. Entrepreneurs launched websites for selling pet foods and some built gaint warehouses for delivering groceries by van. It turned out that no one wanted to buy groceries delivered to them by web van’s warehouses. Alas! The internet bubble burst taking with it all these half baked “innovative” ideas and businesses that had developed solutions to problems that never existed.
We need a very product oriented culture in companies. Lots of them have tons of great engineers and talented smart people. But ultimately there needs to be some gravitational force in the product to pull it all together. This gravity is what I feel innovation is all about.
I strongly believe that money is not the key for innovation. The key is the product focus and a product development cycle that has room for innovation. Microsoft for instance, spends billions of dollars in Research. Every year it invites journalists to look at its massive concrete and glass structure full of “innovations”. Yet, they end up copying things that Google or Apple does. Look at hotmail or yahoo mail apps. Its gmail mocked! Or Zune, the Microsoft variant of iPod, an obvious copy. The only product I know, correct me if I am wrong, that came out of these research facilities is the speech recognition component in Vista. Yeah it works well, but it is not a killer like gmail or iPod.
Talking about the key aspects of innovation, I think the company’s focus on the product is a must. If a company wants to be innovative and wants to differentiate itself from the rest, I think that it should question its products and its product development cycle.
As an example, let us look at Kano model of customer satisfaction.
It categorizes the features built into any new product as
• Must have feaures
• Linear features
• Exciter features
Must have features are the ones that must be in the product to be useful. Without the must haves there is no product. However, I feel that the must have features need not be fully implemented when the product is released. A “just about right” or “lagom” amount of completed must haves will do.
Research suggests, that although without the must have features the product will be useless, it is the linears and the exciters that gives more satisfied users.
Let us say, that I wanted to build a hand held music player. What are the must haves required for this tool to be useful?
Let us assume, a good head set, some hard drive to store music files, a play/pause/rewind/fast forward button
One can of course spend a lot of time for instance to make the head set really really good. But a good enough head set would fetch us “just about satisfied” users. There are other important things that can make the player really good. So lets stop there and move on!
The Linears, they are the ones that gives the user more satisfaction. A linear feature is the one for which “the more the merrier” holds true. It is called linear because customer satisfaction grows linearly with the quantity of these kinds of features. The more the linears in the music player the more satisfied the user gets.
Some examples of the linears I would like to add to the music player are
1. Good battery
2. A good display
3. A scroll wheel on the sides to browse music
4. Auto and manual lock/unlock button to lock when the user is on the move
5. Slick design
6. Light weight
7. Games, calendar, clock etc
Exciters are the ones that add great satisfaction to the customer. It often adds a price premium to the product. However, a lack of exciters will not decrease the customer satisfaction below neutral. But I believe that exciters are the ones that will make the product be perceived as innovative and these are the ones that make the product stand out from the rest of the pack.
Some exciters for the music player would be
1. As soon as I plugin the music player, it will bring up the users’ default music player (whatever it might be) and sync songs both ways.
2. Charge free device that uses solar and advanced light sensitive batteries
3. Maximum of 2 clicks to access any song on the hard drive.
4. No buttons in the player. We make the whole music player a touch screen.
In whatever feature in a product we do, we got to have 1 or 2 real exciters. Look at gmail for instance; they have built in at least one exciter in any type of functionality you find there…that is innovation! Google’s key to beat the competitive market where yahoo mail and hotmail once ruled!
For a product to be innovative, companies should integrate both linears and exciters in their feature list and make it transparent in their product development cycle. Categorizing features this way can contribute to an innovative company.
I believe that only innovative companies can stand in this harsh, competitive, volatile market. The more successful a company is in finding and implementing the exciters, the longer and happier the customer stays and hence stronger and faster the company grows. Many companies focus on adding a lot of linears to their application, this is not bad afterall. But they have to realize that time is wasted! Linear features increase the customer satisfaction to only a certain degree. They will not fetch greatly satisfied customers. Feature freaks got to think about it and control their temptation!
“Do you need satisfied or greatly satisfied customers?” One real good exciter is better than 10 different features. To me, it is like comparing a man to monkey!
So, let us all build more exciters…not just features!
Points or days? Should we care?!
Posted by Ram Sundararajan in Social, Values on July 27, 2009
Some months back, I wrote a mail to you guys about the easiness and the usefulness of using points system in a story instead of calculating its size in days or hours. I thought that I should blog this discussion now as I think that it might be useful for others too.
For calculating the effort involved in a story we now use days as the unit. By days we actually mean “ideal” days.
That is, we smartly ignore other work related things a developer does in a typical day and calculate only the amount of time s/he has to spend on the story.
We have calculated an ideal day to be 60 % of the developers’ typical day. In other words, it is 4.8 hrs or let us say 5 hours to approximate.
I think that this ideal day system for measuring the effort or size of a story brings in some unnecessary ambiguity into our calculations.
To understand what I mean, let us go back and ponder on what estimation means to us?
What are we trying to do in the estimating meetings?
The answer I think is, during the estimation meetings we are trying to define the size of each user story. In other words, we are trying to categorize each user story based on our previous experience and calculate the effort involved to put these stories into sizes or points like S, XS, M, L and XL or 1,2,3,5, and 8 respectively.
Great, so why do you use “ideal” days?
Well, I think that we use ideal days because we somehow wanted to relate time to effort so that we can know how many actual days a story is going to take or taken. Also, it becomes easy to express the status in number of days to the stakeholders rather than with an abstract entity called points. Yepp, true…but I think, this creates ambiguity to a very large extent when practised. For instance, an ideal day for person A need not be the same as the ideal day for Person B. So I think this system is highly subjective. It does not make sense to me to use a system that varies a lot between individuals.
If we wanted to measure how long a story is going to take, we should instead use the team velocity and perhaps create baselines using Burn down charts.
These two measures together can give a better approximate estimate in time for a story.
Let me add some weight to my argument with Mike Cohn’s thoughts on estimation
Choosing between story points and ideal days
With Agile methods, it is perfectly okay to use either points or ideal days as the measure of the size of a user story.
But I think that the points system is more advantageous and complete. Read on…to know why?
According to Mike (and I totally agree with him of course), below are the key advantages of using a points system
a) My ideal days are not your ideal days
b) Points estimate do not decay
c) Points are pure measures of size
d) Points estimation are usually clearer and thus faster
a) My ideal days are not your ideal days
Let us say, two runners one fast and one slow are standing at the start of a trial. Each can see the whole track of the trial and can easily agree that the track is one kilometre long. They either come to the agreement because of their previous experience or by comparing it with another track. Either way the process is easy and intuitive. Tracking the length of the trial is similar to the points system. That is, one simply measures the size.
Now, let us bring in some ambiguity by adding more parameters…
Suppose instead of discussing the length of the track, the runners wanted to calculate the time it takes to run the trial. Obviously, the time taken by the fast runner will always be lesser than the slower one. It is going to be difficult for these runners now to come to a consensus. Both of them with different numbers are correct from their point of view. They probably will never agree as to how long it will take to run the trial.
There is another thing that we need to pay attention too. An Ideal day between developers differ a lot because they are constantly involved with something else other than the story development. Things like support issues, big maintenance bug fixes, investigation, design for future projects all takes time.
So as said, the ideal days system is too subjective to be a standard.
b) Points estimate do not decay
An estimate in points has a longer life span than estimates in ideal days. It is simply because the point estimate only takes into account one parameter and that is the size.
Let me explain this with an example. Let’s say that we are to use ideal days to estimate a story that has to use a new technology like flex. We know that none of the developers have worked with it before and we have to do a lot of investigation and learning to produce the story feature. So, let us assume that the developer estimates it will take 13 ideal days to complete the story. Great!
Now, let us fast forward a few sprints and ask the same developer how long another similar flex story will take to do. Obviously, the estimate will be lesser, let’s say s/he says 3 ideal days. Bingo! we got a problem here. Similar stories take different amount of days to implement.
Many teams tend to ignore this as a problem because they think it is only logical that the amount of ideal days decreased, because the developer knows more about the technology now than before. They also argue that measuring team velocity over time would even out this difference. But it actually won’t in reality.
Because…we will see that using ideal days, the team velocity always remains the same even though developers do more work. See, the developer now after a few sprints produces the same feature in 3 ideal days, where the first time it took 13 ideal days. In other words, in 13 days the developer is now capable of producing 4 such stories (4 stories X 3 ideal days = 12 ideal days). But with ideal days the developer’s velocity is always 13 even though s/he can complete 4 such 13 days stories in 13 days. So ideal days do not reflect the actual team velocity in this case. (logically, after a few months the team velocity should have gone up)
With the points system, we do not take time into account…we just calculate the size. For instance, we say that the flex story is about 8 points or XL large and then after a few months, the team velocity is calculated, now we see that the velocity goes up because the team is now able to complete X number of more XL stories than they did previously.
c) Points are pure measures of size
As said earlier, points are pure measures of size and ideal days are not. Of course, ideal days can be used as a measure of size, but with deficiencies. As in the above example, points remain the same but ideal days tend to vary depending on the developers expertise.
Story points being pure measure of size has a couple of advantages. First of all, story points allow the team to estimate stories with analogies. It makes the estimation easy and more fun as we are only talking about “this story is like the other one” and hence should be for example an L or 5 points. When we estimate in ideal days, we can use the same analogy approach, but the problem is that we tend to bring in the calendar days and measure how long a story will take to execute instead of looking at how big a story is. As said, “how long” approach has hidden problems!
Secondly, a story being an abstract measure of size escapes the temptation to correlate it with reality or time. Less is more!
Ideal days has an inherent comparison built in
That is, we tend to always end up comparing actual vs ideal time.
Then this pondering eventually ends up with questions like, “how the heck we ‘only’ did 8 ideal days of work in a 14 day iteration?” You know more often than not, many teams put the blame on some bully.
d) Points estimation are usually clearer and thus faster
Yes, to me it sounds obvious that it should be really easy to estimate a story on just the size. We skip detailed level of discussion and it makes things easy.
So in estimation meetings, we got to decide only if a story is an XL or M?…Then arises suggestions like we got to do these and these things. Further the last time we worked on that piece of code we found that we had to re-factor it etc. We can also use our previous stories as analogies. Perhaps a similar story that was an XL involves lesser effort this time?! Maybe maybe not…that’s what we decide in estimation meetings.
My point here is that it is easy to talk on higher level and skip going into the details.
Of course, we got to break down the story into smaller tasks. But that has nothing to do with estimating a story size.
Finally, I think that estimation in ideal days has some advantages. But I unfortunately can see only one obvious thing.
Stakeholders want to know when a story will be finished. Is it by Aug 1 or Aug 15? Calculating ideal days might be easier
to get to the date the stakeholder wants to know. But it is like a shortcut and it creates a lot of side effects for the team members.
So I think we gotta stick to the best practises that agile gurus suggest. That is points for a story size and velocity based on points for the team! Just as Ez as it can be
ThoughtWorks conference on Scaling Agile
Posted by Ram Sundararajan in Innovation, Social, Values on June 9, 2009
As some of you might know, four of us here in Bangalore went to a conference/seminar at ThoughtWorks on ”Scaling Agile”. For those of you who do not know much about ThoughtWorks, they are a successful company with over 1000 employees in six countries. They are the fore-runners when it comes to Agile project management. ThoughtWorks also sells an Agile project management software called Mingle.
During the conference, it was very exciting to see how similar our work framework was to theirs. Does this mean that we are on the right track? Oh yes; not only by following one of the Agile principles of “reach the customer faster” but also by following some of our core values very effectively.
Right, below is what ThoughtWorks had to say about how someone whom they call an Iteration Manager should try to establish in his/her team (this role is bundled in the role that Lena and Jojo are doing at present…)
Iteration Manager should work toward a professional and accountable work environment. Such environments exhibit proper behaviors and mannerisms, such as the following:
- Mutual respect is displayed for self, others and customers
- Successes are celebrated
- Mistakes are treated as learning experiences
Strikingly relevant to what we already have, isn’t it? I will post you this book today.
Okay, going back to the conference, below are the key points we learned from there
- Programming is an art and software development is a social activity – Improve the conversation and you improve the software
- Embrace change – Dare to make a difference
- Rapid feedback – Develop to make your MUST HAVE work faster. Get rapid feedback from the customer. In our case, UxD and Test
- Continuous Integration – Check-in your code often. Create a test harness like Unit test and functional test simultaneously
- Face to face communication is a must – ThoughtWorks does it using video conference, chats, etc
- Make yourself easily accessible
- Make dev. Environments close to Production.
Apart from these, ThoughtWorks stresses on the importance of graphing out our project activities so that the Project Team and the stakeholders can find out the bottlenecks in the project now and then. I do not think that we do it today but they talked about the importance of maintaining charts which can be discussed on a weekly basis. This chart becomes more interesting especially during the retrospectives, if not immediately.
It was interesting to see how they keep track of the number of check-ins a day through a graph. At ThoughtWorks they say that they have a general rule that whenever a developer checks in a code, s/he is responsible for the aftermaths. If a bug is found in the recently checked-in code, it’s the developer’s responsibility to see to it that the bug is fixed or the code is rolled back within 5 hours.
When it comes to practicality, I would like to jot some things on the Continuous Integration part. I think that we have completely missed out on this part when we moved to the new Harvest model. ThoughtWorks has MOSCOW requirements in the product backlog. When the project is under implementation, the development team discusses the design aspects and implements the most important MUST have ASAP. They check-in their code (they said 20 times a day) to the main branch, and write unit test and functional test simultaneously and make sure the automation test passes really at the beginning. The test and the design team then picks up the task and works with them. Thus overcoming the “continuous waterfall” pitfall in the development cycle. The dev, design and test team work simultaneously on the tasks. Fantastic!!
We tried something similar to what they suggest here May sprint and it seems to have worked well for us. But again, we all in our roles need to make ourselves more accessible, else we will end up in the continuous waterfall.
Below are what ThoughtWorks thinks are challenges and options to overcome when it comes to scaling Scrum
|
Challenges |
Options |
|
Limited face to face |
Formal and scheduled communication channels like meetings chats, video conference |
|
Consistent view of big picture |
Scrum of Scrums |
|
Lack in clarity of responsibility/ownership |
Information radiation
|
|
Decision making |
Improve escalation points |
|
Knowledge sharing |
Communities and forums |
Below are the key take-aways from the presentation ThoughtWorks did during the conference.
- Program plan and governance – By governance they mean communication
- Continuous Integration
- Trigger points for structural changes – We need to get red hot at things that work less good and burn to improve it ASAP
- It takes more time to change
- Focus on Objectives, Principles and ADAPT!
Oosch! You know what? I think that the next time you guys come down here, we should make a visit to ThoughtWorks. They really have an open, flat, motivated and a smart work environment!
The Bangalore Report – Day 3
Wednesday
The plan today was to have a bit of a slow day, focusing on unit-tests, some Javascript sessions and such.. But (as usual it seems) things did not turn out as planned.
We started the day with the morning stand-up meeting. We quickly handled the issues at hand between all of use(well except me since I’m the boss) and got started fixing the stuff found by UxD late yesterday afternoon swedish time.
We had our goal set to finish all the reported issues before the Stockholm stand-up meeting, but some of the issues took time, so we did not reach our goal.
During the meeting with Stockholm the scrum master was screaming more then ever, maybe she wanted to make point. I don’t think so, she has a good sense of humor, so no worries.
Well after that I started to go through a lot of bugs that are prioritized for the next spring by Mr Irish. Me, Mr UxD and the loud Scrum Master will have a chat regarding my conclusions tomorrow. Hopefully Bangalore Earth Hour will not happen during our meeting.
As I tweeted previously today, Jayesh is spot on with his skepticism regarding Earth Hour that toke place on the 28th of March. In Bangalore Earth Hour happens several times a day automatically… Luckily Blue Star has filled the basement with batteries that kick in, so Internet never goes down. I wonder what happens with the elevator, since the light go down? Shit, I need to remember to take the stairs tomorrow!
Durring the day our beloved boss sent approximately 15 mail regarding a failing in-development feature and kick-started Rams sweeting. We will handle the issue next week when Ram can have a partner in Mr New York(samcyp).
Me and Ram went for a late lunch around 2 PM, since he just needed five minutes more for about two hours, at the same restaurant as yesterdays dinner and lunch. But what the heck, it dame good food.
During lunch me and Ram also went to Total, a big shopping mall near by the office. I found some nice clothes for the kids. On the way to Total Ram asked me what I thought was the best and worst thing in India. The worst thing is easy I said, the contrast between those who have(and they seem to have a lot) and those who has none is really striking. The best thing would probably be meeting Ram and the rest of the crew, and of cause the food.
After lunch I got a mail from Mr UxD asking if I had started investigating the feature I had promised to do until monday. He thought that it was a good thing for me to start with tonight, since it would prevent me from falling asleep until CL final tonight. I know it was a joke so no harm taken:) But this brings a thought to mind, if possibly anyone who reads this blog is living at Nandhan Grand in Bangalore and could tell me what channel the game is on. All I can find are programs with 15.000 people dancing and singing.. It’s really strange, but true! It’s like all channels are directly liked to Bollywood!
After work me and Ram walked over to the Forum, and got some more stuff for the kids back home. On the way to the Forum I say the most stressful job in the world, a traffic cop in Bangalore. He was sitting in some cage and was occasionally screaming at some Auto-richa who was on the verge of going the wrong way one a one way street at rush hour. He once tried to hand out a fine but the Auto-richa driver got away.
At 9PM I had dinner at the Hotel, shiploads(as the spellcheck want’s it to be) of rice, chicken and naan. During dinner I watched the Zoom channel in hindi. Since I say a picture of Paris Hilton every five seconds, I knew I wasn’t missing much.
Tomorrow is the last day for me here in Bangalore, it’s true that time flies when you are having fun. Since this is my fourth trip to Bangalore one might imagine that I would get used to the traffic, the noise and the massive amount of people, but I think I never will.
But the week before I went down here, I finally figured out what is so special about Bangalore at night, it’s the darkness. Bangalore is a city of 5 million people (according to wikipedia) but is still really really dark. It’s just the main streets that have light, the rest is dark.
And now it’s 11:55PM 00:10 AM, and the game is soon to start. But Star Sports, which will be airing the game tonight, I think, is still showing tennis!
The Bangalore Report – Day 2
Tuesday
Today nothing really exciting happened, I woke up and went to the office. Unfortunately I had forgotten the AC on all night, so I was freezing cold when I woke up. Luckily freezing can easily be fixed here in India, step outside for two minutes and your fine.
At the office we started the day with the daily stand-up meeting, after that we started fixing the issues found by UxD(two still to be nailed tomorrow). Me, Ganesh and Kashif fixed some easy bugs after the stand-up meeting.
At 12:30 it was time for the Stockholm “morning” stand-up meetings. It’s kind of fun to take part in meetings with Stockholm from down here. I will not name any names, but the Scrum Master in Stockholm really screams during the meetings whenever she talks to us. Luckily everyone knows she is not upset but is compensating for the distance.
I participated in the sprint follow up of the April sprint with Stockholm, unfortunately Internet was behaving badly. Rumors has it that some router was killed apparently(possibly nevdull77 testing something?!)
While I was in the meeting, Ram was kind enough to pick up some food for me. All I can say is that it’s lucky that I do not live here in India, it was a massive amount of food(and hot as usual). I would look like a big red balloon after a couple of months!(Music tip: Black balloon by Monster Magnet )
In the afternoon we did some ruff estimations of coming projects in the June sprint, as well as we had a little meeting regarding testing of our own code and quality contra quantity, it was good. Quality still rules!
During the whole day I have been trying to get some time to prepare the Javascript Event Chain/Namespaces session we have planned for tomorrow, but have not really succeeded. But what the heck, how hard can it be. I’ll shoot from the hip on this one.
For the evening we had planned to leave the office at 7pm, to celebrate the Bangalore Star-of-the-Sprint. But due to reasons out of our hands, bug fixing, mailing an such, we left at around 8pm. We went to a nice restaurant close by the office where JoJo handed out the “voting cards” with a company logo and all. The focus for the Star-of-the-Sprint is to find the person who have been living the core values best for the past three-four weeks. The victory went to Adarsh, with Appa as a close runner up and Durgesh taking the bronze medal! Congratulations all of you! The prize Adarsh won was a lovely little silver star, it looks great!
Unfortunately JoJo forgot to say that is was not allowed to vote for yourself, but luckily Ram only got one vote.
The food was great and somehow the conversation always seemed to end up around the things Jon ate when he was down here in Bangalore. Jon, I tell you, the Bangers are really impressed. I’ve heard stories about how chilies being eaten and more, and they say “that you boldly went where no mans gone before in the wilderness of food”! They also say that Jalle is more like me, a bit more sensitive. I think what they mean is, a bit more sweaty.
Today I learnt that there is a real Ramesh around, and not only our own. Ramesh apparently works for Blue Star in Bangalore. Unfortunately he’s in the hospital right now because a big tree outside the office fell on him during some heavy rains some time back. How much bad luck can a guy have, we hope that his broken legs heal soon.
After the dinner Ram and Durgesh took me home in Rams new car. A great thing that has happened since my last visit is that Ram now has removed the plastic covers from the seats! I like Ram car, its great. Or it’s probably like this, I like to ride in Rams new car much more then behind him on his scooter. I don’t have a death wish you know
The Bangalore Report – Day 1
It was really close that I did not continue with the Bangalore reporting thing, but why stop a loved tradition
, so here we go
Sunday
The trip started out really bad, I stood in the wrong check in line for 30minutes at Arlanda, and I hate that. Me, I’m a guy how likes to have control, if I stand in the wrong line that’s an evidence of me not having control.. Puts me in a bad mood one could say. And for christ sake, it’s 04:30 in the morning.
Question: Is Sweden on leave or something? At 4:30 Arlanda looked like Bangalore, people all over, I promise. It was insane.
I eventually ended up in Frankfurt, and Frankfurt is Frankfurt.. ..Dark and grey, no fun at all.
But I did the good thing of the day in Frankfurt; I helped a small young guy, possibly 13years old, find his way to the Bangalore flight. He was a Swedish consultant working for Cap Gemini going down to Bangalore to attend some 2 week course. Apparently Cap Gemini has 20k developers working in India. But back to the good thing, he tagged along with me through Frankfurt Airport, this of cause due to that I’m such an experienced traveler and a real business man. I even waited for him when he went to the toilet. Even on the flight to Frankfurt I had noticed that this guy kept running back and forth to the toilet, and he later explained to me that he was afraid of flying, and of cause that was the cause of all the visit to the toilet. I told him, “you will have no problems on the flight to Bangalore, it’s a big 747 and the flight will be smooth”. Boy, where I wrong, we had a really bumpy road down to Bangalore, I hope the kid survived!
The flight to Bangalore went well beside the bumps, I had this really interesting Mr and Mrs Something who had been living in the US for 6 months and where now moving back to Bangalore, they were really nice talking to. The Mr in the family was working for a big Indian consultancy firm, and was a bit feed up with not being able to change anything. “We are not very agile” he said, I tipped him to contact Blue Star and see what they could offer..
Entering customs in Bangalore was a new experience, thank you Swine Flu!
Previously it has taken a long time to go through customs, but now thanks to the flu it takes ages, first one need to fill in a form regarding your physical health. I lied a lot as you might understand, since I really need to start running or something. After that you need to state where you have been the last 6 months, easy for me, I could even state the street addresses, Klarabergsgatan 60 and Allfarvägen 21 Täby. The people in customs did not understand my joke so I had to change it to Sweden.
The only problem here was really the massive amount of people that needed to pas the 3 doctors asking the same questions as one previously has answered in the form..
After that I was planning to fast as a shark pick up my bag and get out to Prasad from Blue Star who was waiting for me outside. One could guess that the bags would be waiting since passing the doctors took about an hour. But no, I waited 53 minutes for my bag, and when I finally got it I got grabbed in Customs by Mr Sunshine himself. He wanted me to open my bag, since someone had marked the bag with a big X on the side. So I open the bag, and showed the lap top I had brought from Sweden to JoJo . Well about here the discussion starts, Mr sunshine informs me that is only allowed to bring one computer into India and he thinks the laptop is worth 40.000 rupees, which is probably 35.000 rupees to much, I said “no way, I’ll leave the computer here with you and you can do whatever you want with it”. So then he said, “but I can give you a discount” , I said, “are you real(that is a translation of “är du riktig” in Swedish) can the customs give me a discount, that sounds insane! “. Mr sunshine did not react positive to my comment, and I should have kept my mouth shut! But to end this part of the story, we “agreed” on 33.000 rupees as the computers value, and I paid 9013 rupees as some kind of tax.. it’s hard to believe but I can show you the receipt.
The day ended on a really good note though, when Prasad had taken me to the hotel, the hotel had decided to upgrade me into a suite instead of my ordinary room. Suite == Sweet.
Monday
I had talked to Ram during the nightly adventures in customs, and we had agreed a pone meeting at the office around 09. And so we did, it was really great meeting the nice people in D&M Bangalore! For me the day mostly consisted of meeting, and meetings held in Stockholm, so I did not really have the time to take part in any cool stuff that the Bangalore team is working on. Me and Ram had a nice, but short, lunch with some Blue Star people.
In the afternoon we all got the chance to celebrate Ganesh’s birthday. They do have some strange traditions here in the far east, the guy’s getting older get’s cake all over his face, and he seems to like it.. Must be some Hindu tradition, “go to the local baker, get a ‘cream cake’ and put it in the face of your friend”. Strange, but fun!
I spent the evening at the hotel restaurant, sweating and speed eating due to the fact that two people were constantly filling my plate with Chicken tikka masala. Or possibly it could be due to the Kingfisher beers.
Ps, forgot one thing, my shoe touched some cow shit today, does this make me holy or just my shoe? Ds.
Twitter earns something bigger than money
Posted by Samuel in Innovation, Social on May 20, 2009
Many have understood how they can earn money by using Twitter, but no-one knows how Twitter earns money.
There are many speculations concerning Twitter’s future.
This is my wish.
According to many, I live in an imaginary world. I believe that everything is created, and by a creator. If you believe in a creator/God then we could imagine that the earth and all its resources are “gifts” to mankind.
We’ve managed to take these “gifts” and make money out of it. New stuff is innovated out of them. We created Twitter.
I would like to believe that Twitter is a gift to mankind, from mankind. A new “gift” to connect people together, innovate new solutions using this great platform and make money. Thank you Twitter (God #2?)!
As I said, wishful thinking! I’ll love Twitter even if they figure out a way to earn money.
Flat line for the Twitter Brain
To me one of the major Twitter experiences is the feeling of being connected to millions of other brains on the planet. It’s like Isaac Asimov’s fictional fantasy of Gaia is starting to come true. I probably shouldn’t admit this, but whenever I encounter a new term one of my first thoughts is “wonder what’s tweeted on that subject right now?”. And now and then during the day I need to get my Twitter Trends fix. Sometimes it reveals totally new things to me. It’s how I first heard of Susan Boyle, for instance. I’ve now realized that I got to hear about Susan Boyle only hours after she had rocked Britain the first time. That’s amazing! Usually weeks and months pass before I catch up on such events. (I’m not a fan of the genre, but I don’t want to miss something like the Susan Boyle phenomenon.) It’s totally awesome to get this opportunity to plug in to the Brain. Thank you Twitter!
Of course, sometimes the Twitter Brain is a bit stupid. Often it’s very shallow. And, yes, not seldom it’s really introvert. (Discussions about Twitter itself seems to be what interests the Twitter community the most.) I’m OK with that. I’m not one to throw out the baby with the bath water. The signal vs noise ratio is still really high.
But what happens if the Twitter Brain dies? Do I risk going brain dead if I’m plugged in to a huge Brain when it dies? Yes, obviously I do.
Yesterday the Twitter folks changed a setting used by 2% of their user base. And somehow enough people shut of their brains and started to tweet stuff like “Twitter Failed! Retweet!”, “Twitter is bad. Please Retweet!” “Goodbye Twitter. RT this!” and so on and so forth. Fully and utterly useless crap. Then the brains of the receivers of those tweets went dead and they retweeted. And their followers retweeted. And their followers … You get the picture. It was like a disease. My time line was full of tweets like that. I think four out of ten slots on Twitter trends were related to this too. Check the hashtag #fixreplies out and you start to get the idea. I felt I had to throw something in to the balance and cheered the change. That never showed up on Twitter Trends though.
Please, please you tweeting people. (And all you non-tweeting people too). Keep your brains switched on! I’m plugged in to your brain and I don’t want to go brain dead. Maybe if keeping ones brain switched on at all times is hard, we can train ourselves to sense when it’s off? And then there’s No Tweeting!. Of course the “When retweeting, use common sense” rule apply too.
Yesterdays flat line of the Twitter Brain was scary. I hope it was an exception.
Addendum: I’m also amazed at the official Twitter response to the brainless outcries. They call it “lots of great info”. Totally funny.
Promoting: Using an Agile Software Process with Offshore Development
This one is still very “current” even though is was last updated in July 2006, in regards of what we currently are trying/working on in Bangalore.
When retweeting, apply common sense
I read this really interesting blog about how there’s a better way to rewteet (via @JoshHelfferich). While I agree to most of what the article says, I somehow feel one could have skipped the moral lesson. Twitter is all fine and healthy even with all those copy/paste RT:s out there. No worries!
It all boils down to common sense anyway, doesn’t it? If you are quoting someone’s use of her 140 chars, then a verbatim “RT @source” makes a lot of sense. The Twitter I visit daily is full of interesting people who say important stuff in cool ways. There’s no point in rephrasing their tweets. If your Twitter doesn’t look like mine in this respect I suggest you use that unfollow button and start following interesting people instead. That’s what’s so good about your own timeline, it’s yours!
Passing on links could be a bit different though. Not always, because sometimes interesting people send their messages through both the link and the words they embed them in. (Apply common sense, remember?). But if you really are “just” passing on a link you should, really should:
- Know what that link is about
- Know what you think about the content
And then it shouldn’t be hard to craft your own words to follow the link. After all, you still want to reference who “sent” the link to you and the link occupies some space so you don’t have much space to fill anyway.
Maybe it’s this easy: If you care about that link being followed you’ll maximise the chances by letting your audience know why you recommend that link.
Or even simpler: Show respect!