What are we doing?? - Part Two

Any system is inherently trust based but always tends towards being distrustful. Consider a prisoners' dilemma example.

(A) = A crook with a bag of jewels
(B) = Another with $100

(A) needs the money and (B) needs the jewels. Now they are both "if you see my face, I'll have to kill you" kind of guys. So they develop a simple system. (A) leaves the money a designated place in the forest and (B) leaves the bag of jewels at another designated place.

If they both co-operate, they leave happy. But life is not so simple, is it?

Once they start losing trust in each other. They will employ various methods, making the system more sophisticated in the process, so as to make sure that they are not tricked. Here's what they could do (this list is not exhaustive ;-) )

1. (A) decides to send a friend to the place where (B) is supposed to leave the bag to see that (B) does leave the bag
2. (A) realizes that even if (B) leaves the bag, how will (A) know? So he decides to send two friends, one of whom shall come back and inform (A)
3. (A) grows suspicious of his two friends, coz they might run away with the jewels, so he has to keep their children as collateral. He appoints a person to guard the children and has to feed them as well.
4. The friends say that if (B) leaves an empty bag, it's not their fault. Which is fair, so they end up carrying mobile video cameras that transmit back to (A) on his mobile receiver...

... and so on.

Well actually at step 4 (A) goes "All this for $100?? Not worth it at all". Wise decision but if the stakes go higher, (A) will end up investing in the hi-tech solution which only improves his chance of not getting cheated by a fraction. By the way all this while (B) is also employing similar tactics.

So here we have two parties willing to invest in more and more complex systems as long as the stakes seem high enough for them. And here are we, the IT people, who will help them do it.

To be continued...

What are we doing?? - Part One

I am doing what we call an Inception for a new project. The situation is not at all unusual.

The Constraints

• An Organization with a bunch of generic e-commerce platforms
• Live customer sites on each of these platforms
• One of these platforms particularly painful
• Integration with proprietary back-office operations software

The Requirements
Build a custom platform that will replace all the existing ones, support all the customer sites and have a bunch of unique features. And BTW we need to go live in 2 months.

How?
The only way to do this is build a bare bones application that can take a couple of simple customer sites live in 2 months. We can then keep adding to the application and making it richer and better and migrating more customer sites as and when possible.

Now whenever you try to skin an application the first ones to suffer (and rightly so) are the administrators of the system. I say "rightly so" because normal users can potentially be dumb, careless, in a hurry, etc. and the application has to make sure they are doing the right thing.

Administrators on the other hand are trained to maintain the application. They can do without a jazzy UI and help and pointers all over the place. They know how to do their job. We, as designers of the system, take the liberty of trusting them. And in that trust lies the topic of this series.

To be continued...

End of a good project

For the past 8 months I have been working on omio. We got it from being just a mobile deals aggregator (for the UK) to also being a social network around mobile phones with reviews, ratings and stuff. Ruby on Rails was fun too... but then, that's always true, isn't it. Today was the last day of the project.

I have to say it's been a blast all throughout. First in Chennai with a new office and an extremely smart and totally insane team. Then in Pune with Sid, Aman, Deep and Anand... lot of fun.

Sid is rolling onto a .Net project and I did not try to hide the devlish pleasure I got watching him install Windoze on his machine :P But well, it's time he got out of his comfort zone. These rubyists... I tell you.

Aman, Deep and I remain on the beach (or bench, if you will) for a while. Hopefully something good will come out of it. Aakraman anyone?

Business Analysis and Quantum Physics

I recently read In search of Shrödinger's cat. It's a wonderful introduction to quantum mechanics; The basic (and intriguing) problem of the elusive electron acting as a wave and a particle at the same time.

Analysis is very much like observing the electron in the classic two slit experiment. The business domain is like a wave traveling through the two slits. But the moment we analyze, we make it boil down to one reality by asking it How, What, When and Who.

Waves give you a probability distribution, while particles give you one of the possibilities as a reality. Looking at a business problem, in the wave form is better since it let's you choose a reality that solves the problem well.

For Example: Let's say the business problem is "I want to let my customers know of the new offers I have so that they can take advantage of the offers and I can make money"

This is the problem in it's wave form. The reality can be one or more of email, website updates, RSS feed of offers, people going door-to-door, mobile advertisement vans and a million other options including telepathy, albeit with low probability perhaps.

The problem is that clients come and say "I want to let my customers know of the new offers I have by email so that they can take advantage of the offers and I can make money" and it takes a while to get into a mode where you challenge every reality and go back to the wave form, by asking "Why"? Why is the only question that let's you go back to the wave form.

The more we procrastinate our observation, the better will the chosen reality suit our problem. Agile takes this approach with the concept of the last responsible moment for a decision. It let's future remain future and hence full of possibilities.

Smart Business Analysis

A bunch of business analysts have started this blog recently. I hope to contribute to it more regularly than I update this blog. I will keep cross-posting here and linking good articles.

I hope to save smart business analysis from some of my more weird philosophies and analogies in the future. I thought I'll pick up a good practical BA problem for the first post there but ended up writing about "Business Analysis and Quantum Physics" for some reason.

Size or Estimate

Estimation, I think, has been one of the biggest problems of mankind. The Software development industry is no exception to this sad reality. We almost never seem to get it right.

The problem with the word "estimate" is that it's personal. It's relative to the person who is estimating. Moreover, it's a unit of time. That is why I prefer "sizing" stories rather than estimating them. Size is a non disputed (standard) unit, which measures the level of complexity involved in developing a piece of functionality, a story. The size is standard across a particular project team.

Pizzas are a great example of standard size. They come in small, medium and large sizes and, given the context of the vendor, the whole world knows what a small pizza means.

Pizza Appetite is the capacity to consume pizzas. A 5 year old will find a small pizza to big to eat. A teenager will probably find it perfectly filling. At 25, I find the small pizza too small. I can comfortably eat a medium pizza (or 2 small pizzas). I am sure there are people I don't know who can eat nothing less than a large pizza (or 4 small pizzas)!!

Stories are like pizzas. Given the context of a project, they have fixed sizes. As a developer spends more time on a project, getting older (and wiser), his/her capacity to develop complex stories increases. And this is where the trouble starts. At the beginning of the project the developer could do 1 small story every day. But now, instead of realizing that he can do a medium story (or 2 small stories) in a day, he begins to think that the medium story is actually a small one. The thing to remember is that the size of the story remains the same. It's just that the developer can now do more complex stuff in a given time.

Complexity points are never to be estimated (in fact they can't be estimated because they are not relative to individuals). In the OLAP terminology, complexity points are the fact. An estimate is a calculation you (as an individual) do when you are looking at them from the Time dimension.

So if you are estimating units of time, it makes sense for you to re-estimate so that you take into account your improved understanding of the system.

When you are sizing stories in complexity points be very careful not to fall in this trap. Re-sizing even sounds wrong anyway.

Functional Goals

After this post, I have had a number of conversations with people about what I really meant by setting functional targets instead of story point (velocity) targets. In one such discussion, I was given an example where someone set a goal to run for 90 minutes!!

At first glance you might not find the last statement worth the exclamation marks at the end of it. But this is exactly the difference between functional targets and velocity targets. I think it's wrong to set a target of running for 90 minutes. The real goal is to burn X number of calories. Or to travel X number of kilometers.

Once you set your goal right, you are open to find better ways of achieving it. If your goal is burning calories, you'd probably do it better (faster) by skipping rope for 30 minutes than by running for 90 minutes.

Now all you have to worry about is

• the rate at which you are actually burning calories AND
  
• what can you do to improve this rate
  

So instead of planning to complete 30 points next iteration (going by yesterday's weather, etc), I'd plan to achieve a set of features and keep optimizing the rate at which I am able to produce features assuming that I never compromise quality in wake of going faster.