The ethics of missed calls

ThoughtWorks is a crazy place. You're walking on thin rope all the time and there's super opiniated crowds on both sides who will eat you alive if you take one wrong step. Most of these arguments are paradoxical as described by Jim Highsmith, and get boring and repetitive very soon... "growth", "specialization", etc. Then there are arguments that are totally futile and endless. Like the lunch served in the India offices. People can go on arguing about how they like OR don't like the "current" caterer and obviously never get anywhere because people have different tastes in food and there's no caterer in the world that will be able to make everyone happy.

But every once in a while a really nice juicy argument comes along and makes it all worth the while :)

Missed calls

Missed Calls were (are?) a big part of the Indian (youth) culture when I was going through college. Cellphones were getting cheap enough for college kids to carry one, but call rates were not cheap in any sense of the word. In that situation missed calls were a legitimate form of communication.

1. Giving missed calls to the "wealthy" party so they could call back and bear the cost of the call. This worked well with parents :D and sometimes with wealthy / generous friends.
2. Giving missed calls to indicate yes / no (one ring = yes, two = no). Useful in all manners of covert transactions including flirting with guys / girls from orthodox families that WOULD NOT allow calls from friends of the opposite sex. err... yes this is true.
3. Giving missed calls to indicate "I'm here". When you were meeting a friend and expected him/her to come down / out of the house so you can get going, you don't go to the house. That's weird; a waste of time; a thing to avoid at all costs (exchanging pleasantaries with the friend's family, having a bit of snack / tea offered to you, sharing awkward silence with your friend's super cute sibling, etc). So you give a missed call meaning "Waiting downstairs. Let's go."

There are several other examples of using missed calls to communicate important stuff. If you picked up your friends call before three rings it was considered treason. It meant you were out to get your friend and in complete violation of the "code"!

A question of ethics!?

Apparently the US is new to all this. No one in the US gives missed calls. People just talk. How boring. But when this subject came up couple of weeks back in the TW NY Office, one of the arguments presented was around ethics!! The argument was something like this...

Although the missed call is free to you, the telecom company incurs cost to connect the call and so it is unethical to use missed calls to communicate because you are not paying the telephone company!!

My very first reaction was, of course, "That's a ridiculous argument!!". After thinking about it long and hard I my reaction changed to "It really is a ridiculous argument!!". I vehemently believe that missed calls are legitimate and you are a fool not to use them. You are totally within your rights & not doing anything illegal. Its the contract that the phone company signed up for and so if you can legitimately use the exploit in the system. I consider is "Fair Use". (listen to that regardless; its a masterpiece)

Its not like the phone companies don't know about this. They can't do anything because of a deadlock in a competitive market. If one of them starts monetizing missed calls the others will eat it alive and gain significant market shares.

The catch

There is however a roadblock I faced while making this argument. I was looking for other examples of this behavior (using the free part of a service to gain benefit) and I couldn't find a single one! I know its impossible but you have to help me out here. Missed calls are at stake! Is this really the last legitimate exploit that we have on out hands? Are we so boring? Say its not true...

UPDATE: A friend pointed me to this episode of "This American Life" that explores the question of loopholes and ethics at a much deeper level than missed calls.

Laundry

Its sad that my first post after so many months has to be a rant but I am infuriated by this stupid laundry card system. Someone should be shot multiple times for inventing this and making innocent travelers become victims of this insanity.

To be sure, I mean this rant as a view into one of the most ill-designed system that I have come across. As software professionals and entrpreneurs, we have to keep in mind what our users have to go through to use our systems.

I move into my New York apartment 2 weeks back. I find a series of instructions. The ones around laundry are the most incomprehensible but "I'll cross that bridge when I have to..." I say. Two days back I decide that I have to get the laundry done and so the battle begins.

1) RTFM

The instructions tell me to

1. locate the laundry card stuck to my refrigerator
2. go to www.sdirevalue.com and add money to it
3. go to the building across the street to "activate" it 
4. and then go to my basement and wash my clothes.

(Weird. But hey I'm new in New York. Maybe this is some really intelligent system so let me play along.)

2) 1st problem

sdirevalue.com asks me to "Create a new account". Whatever. I got to get these clothes washed. I register.

Now it asks me at "Add a card" to my profile. I guess that makes sense. So I enter the serial number of the card as required. "This card is already associated to another users account" it says...

(Obviously the last resident didn't think of de-registering this card from his account. Neither would I. Its stupid to expect that someone would remember to de-register their effing laundry card when moving out!!!)

3) Customer Support

I call customer support but they close at 5pm so I have to wait till the next day. When I call them the next day they tell me it will take two days to give me a new card. (Sigh... what option do I have?)

Two days later I see two cards dropped in my apartment.

(Obviously this is a well known problem and there is a possibility that the second card will turn out to be "Already Registered". So they gave a third one just in case. Great!)

4) I need to blog about this

So I try to add the second card. It works!! (I don't have to wear formals to ThoughtWorks tomorrow like I did today!! I will have washed clothes.)

But alas its not so easy.

When I click on "Revalue" which I can only assume adds credit to this card, this site asks me to enter the code on some machine that looks like this.

What. The. Fuck???

I'm assuming hoping this machine is in my basement OR the building across the street where I'm supposed to "activate" my card. So now I have to

1. go to this machine
2. find the serial number 
3. come back and enter it on this site
4. add value to my card (like that's going to be straightforward)
5. go wash my clothes.

I have no idea what fresh hell am I to expect. But I am determined to get laundry done today. Unless of course if I end up requiring customer support... cause those happy people are at home prancing about in their fresh clothes...

Who came up with this shit?? No wonder there's still debates about gun control in America.

Even as I'm publishing this I'm hoping I'm wrong. There must be some higher purpose for me taking these pains to do laundry (apart from being merciful to my fellow subway commuters). I hope someone comments and lets me know what this higher purpose is. But I don't think it likely.

UPDATE: This isn't over yet.

I went to the other building and found the code on this machine and added money to my card. One would have thought he could wash his clothes at last... but NO!!

The money that I added is being "held" by this company. They have given me a "Revalue Code". Now I have go to the other building and enter the revalue code in the machine. That will actually add the amount to my card. Oh and the "Revalue Code" expires in 7 days!!!

And we're back

For several very good reasons, I made a move to wordpress about an year back. But the google ranking for this blog never went down. It ranked second on a search for "akshay dhavle" after more than a year of having a single post saying the blog had moved!

90% of the traffic to the new blog was referral traffic from agileanalysis.blogspot.com :(

The other stupid mistake I made was two merge my business analysis blog with my everything else blog. It diluted the content significantly.

So here we are. I am back to the "new & improved" blogger platform which is essentially as crappy as it was earlier if not worse. I hate the templates, I hate the lack of customizations, I hate how much "post-production" work I have to do after writing a post just to make headings and paragraphs work the way they are supposed to. I hope it'll get better.

But I am happy that I will be posting more regularly about business analysis.

The Sichuan Restaurant

I am in Bangalore for an agile training for a client. I'm staying near our office in Koramangala so I went to this chinese restaurant called "Sichuan" near Raheja Residency for dinner. First of all let me say that its a really good restaurant. If I had to nitpick, it was a bit warm in there but that's about it. Food, ambience, service, rates, everything is very nice.

I had a soup and a main course that was delicious. Even the fresh lime soda was nice. So I am absolutely positive that they can serve excellent desserts as well.

But... there's a Natural's ice cream store just next door!! (Natural's is a very well established brand in India). I overheard the waiter ask at least 4 customers if they'd like to have dessert and they all very frankly told the waiter that they would have it next door. No offense meant and none taken either!

The Sichuan restaurant clearly has two choices.

1. Make better dessert than the Naturals chain
   OR
2. Strike a deal with naturals so that they either serve natural's ice cream at the restaurant / give some kind of discount on naturals ice cream if you've dined at Sichuan

What would you do as the owner of the Sichuan restaurant?

The Project Owner

I recently paired on an Agile Fundamentals training for an organization. Its a two day course in agile philosophy, principles and basic practices offered by ThoughtWorks Studios. Its more of an awareness programme than training that you can put to use in your daily life. This makes sense as any two-day training that promises "take-away"s that can directly be applied to your situation is probably bogus.

Although the training itself is pretty much "canned" in terms of material, the discussions that happen over those two days are very important. In discussing various aspects with people from this organisation, I saw another instance of an engagement setup anti-pattern.

There were multiple stakeholders in the client organization (there always are) and the IT team was dealing with all of them. There were a lot of conflicting priorities, priorities changed while development was going on, people who made decisions went away and new people made opposite decisions due to lack of context, etc. Here's where I think the problems is but first lets talk about the product owner role for a bit and then we can discuss how this ought to work in a services context.

The Product Owner

In my view a product owner role is defined by two simple characteristics:

1. She has absolute authority over what features go into the product.


2. She is absolutely responsible if the product doesn't work.

To satisfy these conditions, the product owner will show several behaviors.

• Has a clear vision of what the product should be


• Knows exactly what the product is currently capable of doing


• Knows the target market (user segment) and the trends in that market


• Takes inputs from the organization, the development team, the marketing guys, the market itself and base


• Based on such inputs, is able to prioritize between planned features, bugs and new ideas

For a product, this role is absolutely necessary. And companies usually don't go wrong there. But when companies set themselves up for running a project, they usually miss this role. It leads to a lot of heartache for everyone and needs to be taken seriously while setting up the project governance.

The "Project" Owner (for lack of a better name)

Let me try to explain what this role should do in a project context. I will also add some context around each point and why I think its important.

1) The Project Owner should ideally be from the client organization

• Since the product owner is supposed to be the absolute authority on what features are developed, he should be part of the client organization.


• If the product is not external facing, it is probably going to be used by employees of the organization. An internal person will be able to understand their needs better

2) The Project Owner should be fully involved in the development process

• To understand the current capabilities and gaps in the product, the product owner should be fully involved in the development.


• She should attend all the showcases, test the application and give feedback to the development team


• She should be involved in story discussions so that she can give inputs about the best way to achieve a piece of functionality based on her knowledge of the user base

3) The Project Owner should have complete authority and responsibility

• She should be the Business Sponsor herself (possible in small startup like companies) OR be someone who is completely trusted by the business sponsor.


• She will take inputs from various parties but will decide what to do herself.


• She will have to have a strong personality to negotiate within various stakeholders in the client organization to make sure the product stay true to its purpose and doesn't go off track because one of the stakeholders shouts louder.   

 

Common arguments and pitfalls

If I am an IT vendor and I ask my client to create this new (almost full time) role, why would they listen?Well, it can turn out to be a tough conversation with some clients. But the basic idea is the same. The way you ask for time commitment from the client, you should also ask for such a role. Its in everyone's best interest. For some clients, you might need to prove the requirement before you ask for someone to take on the role.

Can it be someone from the IT organization?Well... its better than having no one I guess. But its not ideal because there's a lot of client context required for the role. Maybe a smart BA/PM who is permanently stationed at the client site can do it but its not where you want to go.

Iterations, Batches and Flow

I've recently had a lot of conversations with people who are thinking of iterations as batches. By definition that's what they are. You sign up for a "batch" of stories, at the beginning of the iteration, and you deliver them by the end of that iteration. However, it is useful to think of requirements (stories) as units of work that flow through the value stream. Here is why I think so.

What is a batch?

"A batch is a group of items that will be processed at once as a single unit"

Items are usually batched to achieve "economies of scale". This usually means that there are some overhead activities associated with the items in question and it is better to distribute the cost of such activities over a batch of items than to perform such activities for each individual item. A good example is transportation. It is always more economical to transport a whole container full of items than to transport individual items.


You can batch items up at various levels. Coming back to the software world, you could batch requirements (stories) at an iteration level, at a release level or even at a project level if you must. That's what classic waterfall does, it batches requirements at the project level. But the point is, you need to work on the whole batch at once at each step of the process. Which means you'd prioritize the whole batch, analyse the whole batch, develop the whole batch, test the whole batch and then deploy the whole batch.

So what's the big problem?

Well, by batching items, you are limiting what you can do with each of them individually because as we discussed you have to process a whole batch at once. So where you could have prioritized, analysed, developed, tested and deployed individual requirements (stories), you can now prioritize, analyze, develop, test and deploy only iterations, releases or entire projects.

Flow

Instead, think about requirements (stories) continuously flowing through the value stream. This way you can assess individual requirements and make sure that only the most valuable make it into the value stream. Then you can analyze, develop, test and deploy these faster because they are small. Now all you need to do is take stock of how your team is doing at regular intervals. This is the time when you would showcase to your client stakeholders, check your throughput for the given time (velocity OR number of stories), have a retrospective, brainstorm technical approach, assess technical debt, etc.

And what about those "economies of scale"?

You do lose out on them to some extent. But here are two points to make you feel better because economies of scale are overrated anyways (at least in context of software development).


Firstly, remember that the more you do of something, the better you get at it. So by doing small parts of the overhead activities, you get better and faster at those activities and they don't remain such a big cost anymore. For example, take deployment as an overhead activity. The whole process of deploying to production is usually so tedious and time-consuming that you prefer to do it only when you have a sizable "batch" of features to be deployed. But if you start deploying each story to production, you will have to better that tedious process. You will have to automate most of the deployment. You will have to automate most of the testing. After 10-15 stories are deployed this way, the process will not remain tedious anymore.


Secondly, stop thinking of it as extra cost and start thinking about is as the price the business pays for being able to delay decisions and for getting the opportunity to course-correct.

Example:

Let's say you were developing a feature which was split in 10 stories. After deploying the first 3, which formed the minimum marketable feature (MMF), you saw that your users are not using the feature as expected. You either need to change the approach for the remaining 7 stories OR you need to stop working on that feature altogether because, given the users' response, other features have become more valuable.

As business, you would have saved some time & money if you had waited for all the 10 stories to be finished and then deployed. But those savings are insignificant compared to first hand user feedback about the feature and the chance to act based on that information.

As the development team, don't feel bad because your efforts on the first 3 stories were wasted. They weren't. You invested that time and effort to find out whether that feature works for your business. You already got more than what you bargained for.

So what about iterations?

Have them by all means. But don't worry about hangover*. Don't try to sign up and finish a particular set of stories in the same iteration. If you can well and good. But what you are really aiming for is to perform consistent amount of work every iteration.

*So as long as your hangover remains constant you are good. If its increasing, you need to change your approach. For example by signing up for lesser stories.

Where do RFPs come from?

Once upon a time in a big corporation...

Mr. X (you know? the one who does all the work) : Aaaaaargh! I am fed up of watching this screen 24x7 just to let Mr. Y (the boss) know if I ever see a red dot in the top right corner 

Mr. Z (co-worker) : Hey we can probably get some software to do that. You should talk to Mr. Y (the boss) about it. 

Mr. X (to himself) : Sure! that'll get me fired.

So Mr. X doesn't talk to the boss(Mr. Y). But Mr. Z plots an evil plot to get Mr. X out of the way. He tells Mr. Y that they should get software to replace Mr. X.

The Mr. Y loves the idea.
He makes a presentation to his boss...
who presents it to his boss (as if it was his own idea)...
who arranges for a meeting with Mr. P (a guy he knows in the IT department)...
who rants for the full duration of the meeting about how he doesn't have any time / resources to build new software.

Mr. P then goes and whines about it to his boss (Mr. Q)
who says he has some money left from this years budget that needs to be spent. "Let's get the software built by a vendor" he says.

Mr. Q talks to his boss
who tells him he should talk to Purchase department
who tells him he should talk to Legal first to write a request for proposal
who tell them he will need to hire 2 college grads and a really sadistic lawyer to create an incomprehensible document about what needs to be done. He spends all his budget on the college grads and sadistic lawyer and gets a document that totally impresses the Purchase department who awards him with the "King of Kickass RFPs" award.

Purchase then takes the RFP document and sits/sleeps/(i-dont-want-to-know)s on it for the rest of the year because there is no budget anyway. Then new money arrives in the next year and Purchase floats the RFP.

It goes to vendors who start acting like they actually understand the whole business and asking difficult questions. Purchase gets scared and calls Mr. Q. However, Mr. Q has left the organization to go and join another one as "Chief RFPist" after his award winning RFP last year. Mr. R has taken his job. He doesn't know head or tail of the RFP in question.

He talks to his boss who says "Oh! Yeah I remember! So and so had talked to Mr. P last year about replacing his subordinate's subordinate's subordinate's subordinate with a software." Have him talk to the vendors. But Mr. X has already left the agonizing job, Mr. Y is on vacation and Mr. Z is too busy staring at the screen looking for a red dot in the top right corner to be able to get on a call with the vendors.

So Mr. P talks to the vendors and gives the "requirements". The vendors write more bullshit in their "Response to the Request for Proposal". They too have a couple of grads and a smart ass legal guy. Mr. P then takes all the responses to the purchase and legal department for their recommendation for the cheapest quote with the maximum loopholes and awards the project to the most "suitable" vendor.

And then they say 70% of IT projects fail.