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.

Iterationless...

After working in week-long iterations for 2 and a half years, going iterationless left me a little confused on my recent project. Of course when I say iterationless, I mean using extremely small iterations to bring in a flow to stories. Lean? Distributed Lean, maybe?

Firstly, I like the idea of trying something new. The team being small and the project being developed in ruby helps this experiment a lot. There are, however, somethings missing in this way of working. I'll list them down and give my view on each of them in this post.

To realize what we missed, let's look at what we get from iterations. The following are the main motives behind iterations.

1. Celebrate small successes
2. Get regular feedback from clients (showcases)
3. Let the whole team know what we will be focusing on in the next iteration, including the business context around it (Iteration Planning Meeting)
4. Re-estimate stories based on additional information gathered during the earlier development (Iteration Planning Meeting)

So let's see how we are trying to handle each of these situations.

1. Celebrate small successes.
This is very important. To look back and realize that we actually celebrated achieving a story-point targets each iteration, however, now sounds really lame. The moment you move your focus away from finishing a set of stories in a given time TO finishing a set of features and going to production, the world starts making more sense.

I think in this aspect chucking iterations totally makes sense. What this means is you should have a very strong release plan, with frequent (less than a month long) releases.

2. Getting regular feedback from clients
Showcases have nothing to do with iterations. Iterations only provide regularity to showcases. To say that we will do showcases once a week (and do it) is I think good enough.

One thing to beware of is that showcases-bound-to-timelines (once a week) and development-bound-to-releases (of irregular time intervals) can be quite tricky to handle.

3. Let the whole team know what the focus of the next iteration is
Ours being a small (ideal?) team, I don't see too many problems in this area.

4. Re-estimate stories based on new knowledge
This, I thought, was the most important aspect we were missing out. But once you realize that your story point sizing is only relative to any other story you estimated, the world seems much better. This means that as long as your triangulation is correct, you are ok.

One thing that IPMs give us though, is an opportunity for the whole team to estimate together. Right now I am unsure of how important this method is. I am posting a few questions related to this at the end of this post. It'll be great to get some feedback on these.


All in all I think going iterationless is beneficial in terms of:

• Shifting the team's focus from story points to features / business value.
• Letting the team focus on estimating complexity of stories much more clearly.
  

What I am unclear about is estimation.

• If we spend 2 hours every week to estimate together, are we going against lean philosophy?
• On the contrary, if we estimate just-in-time, in smaller groups (pair to work on the story) are we losing the "group touch" to estimation?
• Also if we estimate just-in-time (when we decide to play a story), the business doesn't get an opportunity to re-prioritize based on sizing.

Agile Business Analysts

Yesterday, Craig Brown asked Do we need Agile Business Analysts?. Two and a half years back when I joined ThoughtWorks, I would have said "No, we don't". Today I strongly disagree with the view that Business Analysts can be done away with on Agile projects.

The objective of an Agile project is to provide maximum value to the client as soon as possible.

Now I agree that the ideal situation would be when you have business users & developers who agree and abide by this sentiment. You can happily get rid of the BA in such a situation. Real life, for some reason, is never ideal.

Anyone who has interacted with business users on a medium to large project will have faced situations where it has been hard for the business users to come to a consensus on what they want. Business users are generally representatives of different functions of the organization. Each of them has expectations from the application which more often than not are conflicting. Keeping these users focused on what we set to achieve when we started building the software is what a BA does.

Being on an agile project gives the business users many chances to dream, many chances to make changes. Developers are human too. They dream about technology. While sometimes this can lead to some really cool/unique/usable feature in the product, it can also lead to "overcoolified unnecessities". Now in an ideal situation, all these dreams would come true. Unfortunately, dreams in the real world are bound by budgets & deadlines. Managing these dreams, ideas, changes so as to keep them aligned to the original business objective and deliver most value in the given time and budget is what a BA does.

What agile aims at, is to start minimal and change as required. When a small bug on a story turns out to be a big chunk of enhanced functionality, we create a new story. The tasks mentioned above, along with writing user stories, supporting implementation of the functionality, planning the iterations and releases, testing the developed functionality, etc. together makes for a considerable chunk of work. That's when you create a seperate role called Business Analysts.

Now this role can definitely be performed by developers. In my experience, though, good developers don't really want to do any of this. They want to write good code. That's what they are best at. That's where they will deliver maximum value.

Hence Business Analysts.

StubbornSoft & MammothSoft

I met a couple of villains today
a formidable lot.
StubbornSoft was one of them called,
the other was MammothSoft

StubbornSoft had it's own ways
for the user it didn't care.
MammothSoft would smugly say
"Try, change me if you dare."

In a moment I then realized
my dark and ugly fate.
When both of them cried out to me
Why, come let's integrate

We'll make a heavenly trio they said
our technologies cutting-edge
So smart piece of code as us
there'd ne'er be, we pledge

"I am quite small" to them said I,
"my features are too few.
But I let users do their job
and go home happy too"

"And what do we have to do with that?"
They asked to my dismay
"We were made to make the boss happy
not users anyway..."


Software is for users