Business Analysis

The Revolution

2009-06-23T18:16:00.000-07:00

Software Development - Art OR Science?

A seemingly clichéd question. Never passed my mind all these years. But let me tell you how I got thinking about this and maybe it'll interest you a bit.

Like I said earlier, I have been following a lot of Lean-Kanban discussions, articles, etc lately. Some such material is Little's Law & WIP limits. Now the moment I saw an equation, I couldn't resist the temptation of trying out some math to see if the size and composition of my current team is optimal. Furthermore, I thought, given a few specifications of the project like domain complexity and technology, could I find the optimum team size and composition?

I hit two forums with this idea and most of the feedback was that there are too many things to consider and difficult things as well like the skills and experience of the people on the team. And I agree that people make most if not all the difference. But that's the problem isn't it?

What's so special about our people? Skills. Experience. Talent even. It's a sign. It's a sign of our industry being immature. I think its in around the occupation stage on this scale.

Enough demand can trigger the Art - Occupation - Industry - Science transitions for any activity. Note that the transition is never 100%. There's Art and Science in everything. The question is whether something is "more of" art OR science.

People keep arguing that Software Development is different. We are not like construction, we are not like assembly line manufacturing, we are not like Product Development either. I used to believe it till a few days back. But the more I think about it the more I feel that these are arguments of a losing population of craftsmen who are finding it increasingly difficult to meet the demand for their craft (which has BTW risen at unusual rates).

Think about the guy somewhere around current Pakistan who created the first piece of leather clothing many hundred years ago. Think about the leather industry right now. Think about the transition. At some point he must be saying "This is different. This needs skills. This needs experience". It took centuries for the transition but it happened. I am sure it can be co-related to the rise in demand for leather products.

The funny thing is, if you look at the list of general characteristics of the Art and Science sides, the first three points on each side don't really fit in with the IT occupation do they? We have loads of unskilled people sitting around producing amazing amounts of useless code all over the world.

So I think the revolution is inevitable. At some point the people who pays us boatloads of money for bad software are going to revolt. We either have to change OR die.

Here's another article roughly talking about similar things. The author anticipated a code market to emerge where reusable components would be bought and sold (which didn't happen OR hasn't happened yet). But the rest of the content is around the same theme as this post.

Kanban

2009-04-28T11:38:00.000-07:00

Although I am not in the thick of things right now (because I am onsite, alone, so far away from my team) I follow the very active kanbandev yahoo group. It's a great resource for thoughts and questions on lean and kanban software engineering.

David Joyce, a group member, posted about a presentation he gave and I found it really good. So here's the presentation for anyone else interested.

It's definitely a long one but take some time to go through it.

Good stuff David.

Story Dependencies

2009-03-16T14:06:00.000-07:00

As I mentioned in this post, I am pretty annoyed with myself because of the way I structured stories in the first release of my current project. Here are a few things that I learnt.

First of all when we say that Story A is dependent on Story B, it means that Story B development cannot start until Story A development is complete

There are different situations where one story is dependent on another. Each situation needs to be dealt with in a different manner.

Types and Approaches

Situation 1 - The wrong split
This is the classic vertical split. Many have advised against it but many more fall into the same trap again and again. Myself included :)

Look out for the vertical split problem.
Remember,
If your body is horizontally split in half as in you have no legs, you can still do something with yourself.

If your body is vertically split in half as in your left is separate from your right...

The first place to look for the vertical split is Admin Functionality / User side of the application. If you see your stories divided like Admin Stories and User Stories make as big a noise as you can quickly.

Situation 2 - The application flow
This is where we just plainly don't think.

Example:
When you get a message on Yammer, Yammer sends you an email. You can click on the email to look at the message you have got. BUT you can obviously keep your Yammer client open and see the message instantaneously and thats the way it's supposed to be used.

Email notification is a nicety. Showing the message on Yammer client DOES NOT depend on sending an email notification to the user.

Such errors are much easier to spot. Beware of the Business Process Workflows that you refer to. The business process workflow DOES NOT represent development flow. Mark the niceties and essentials apart in your workflow.

Situation 3 - Data dependence
This is a little more tricky. But I have seen this a lot of times as well. This is closer to David's comment on my earlier post.

Surely to sell an item, you need to set the item up in the system. Doesn't this mean that you have to build the Item CRUD features into the system before you can sell it.
NO!!
Theoretically the items could be setup directly in the database. If the goal of the system is to sell an item, then that's what should be done first.

Practically you should be doing the absolute minimum "item setup" before you build the functionality to sell it.

The first thing is to concentrate on the crux of the system. Selling Stuff, Lending Books, Renting out DVDs, Playing Music, these are the things to achieve as early as possible in respective projects. Therefore you need to do whatever is needed to get to these areas as soon as possible.

Musings-at-the-end
I was mostly plagued by the admin V/s user situation throughout this release. We split stories that way because there was a tough deadline to meet and we thought it's better to split the work so that more pairs can work on the project. It worked out alright and we are in the last iteration and even able to provide a few more story points than promised. But we did face a lot of problems in scheduling because we split the stories in a wrong way. So that's definitely something to avoid.

Another thought that keeps popping in my head is the idea of Programming by Convention. Like RoR.

If you have a team of fairly experienced, "like minded" developers... can they agree upon a few conventions to follow so that two pairs can work on "Setting up the Item" (Admin part) and "Using the Item" (User part) simultaneously? I am still talking about evolutionary design (code as well as database). I seem to think that with good build processes, this should be possible.

What do you think?

Credit Cards, PCards and Level 3 data

2009-03-06T13:01:00.000-08:00

Here's a post that talks about business more than business analysis.

I have been researching what it means to process level 3 data for credit cards. For quite a while now. Finally today I had that "Oh!" moment and I want to share it because I have had trouble finding data.

Basics
Credit Card processing is simple. I am assuming e-commerce here.

1. Customer enters credit card information (Number, expiry date, billing address, CVV)
2. Site (Merchant) sends the information to a CC processor.
3. CC processor talks to the issuing bank and authorizes the card
4. Site (Merchant) gets paid by issuing bank
5. Customer pays the issuing bank later

Not So Basics - PCards
Large Corporations and Government Agencies (LCGAs) realized one day that they could save a lot with electronic transactions and decided to use credit cards. But the employees went crazy with their personal credit cards. So Visa and MasterCard came out with special cards that were issued to employees specifically for official purchases. This is the Purchasing Card (PCard).

Level 3
However, the usual credit card transactions were difficult to settle. LCGAs realized that if the Merchant sent more data about the purchase to the CC processor while charging the card, LCGAs could get this data back from the CC Processor and thus could reconcile all transactions electronically and hence easily.

So the merchants started sending "Level 3" data to the CC processors. This is detailed data about the line items for which the card is being charged.

Benefit
The basic benefit of Level 3 data is that LCGAs can reconcile the purchases made by their employees easily. They can also keep a check on what the employees are buying.

Conclusion
Level 3 processing is only beneficial for PCards. Not for consumer Credit Cards. It's advisable for merchants to pass Level 3 data to CC processors because it increases their chance of working for LCGAs as well as gets them some discount on transaction processing fees.

Can you shuffle your stories?

2009-02-25T13:43:00.000-08:00

No? Neither can I and I am not happy about it.

So I got my new iPod Touch. One thing I find slightly annoying is the fact that when you select an album it gives you the list of songs. But the first option is "Shuffle". Being used to LPs and Cassettes and CDs I don't really like to shuffle songs. I have listened to my favorite albums in a given order of songs for so long, that I want to listen to them in that order.

So I started wondering about the requirement for a shuffle option itself. And I conclude that it does nothing but brings a tiny bit of randomness in our lives. A little bit of surprise. That's all.

What is also important is that the songs that we listen to usually are shufflable :) Because I do listen to Indian classical music and you can't shuffle that. The khayal has to come before the drut rendition.

So what's this got to do with user stories? Well, I am currently plagued by dependant stories and I suddenly realized that they are like India Classical music. They can't be shuffled. Separate post about why I have too many dependant stories on the current project.

Dependant stories are not always avoidable. But it is ideal to have a lot of stories that can be shuffled.

A Bunker Buster coming!!!

2009-01-01T23:53:00.000-08:00

Get Down!!! Take Cover!!!

A bunker buster on it's way here guys...
...been a long time since I wrote one of those :D

But then again, as Nassim Taleb says in The Black Swan

What you know can't hurt you (much)

More on the book later. I still got to finish it.
And by the way, have a wonderful New Year guys.

Features V/s Sophistication

2008-12-19T04:00:00.000-08:00

Usefulness of software:
Letting the user do what s(he) wants easily and fast.

Features:
Number of activities a user can perform with the software.

Sophistication:
Software intelligence which simplifies user interactions.

Software, like anything else follows the laws of Diminishing Marginal Utility. Here are the graphs as per my experience with software (Not as a software professional but as a simple user)

Features
I think the marginal utility of adding more "features" to the software diminishes at a much higher rate.

Firstly because individual users don't use all the features but have to pay the price, in terms of money as well as processing power, disk space, etc.
Secondly because users have to deal with all the "genericness" of the software and hence cannot do what they want easily and fast

Best example of such software is (my beloved) Lotus Notes.

Sophistication
The marginal utility of making software intelligent also diminishes albeit at a much slower rate. Google Calendar Quick Entry is a good example of software intelligence. So is GMail's drunk email protection.

What keeps GMail, GMail is that everyone (creators and consumers) abides by the simple rule that GMail is for sending and receiving email. If you want to do something else, you will have to use something else.

There are a couple of software that come to mind which do have a huge feature set but still keep the crux simple enough. Microsoft Word for example has done it rather well in that I can go in and create a simple document as easily as I could when it ran on Windows 3.1

As a business analyst this translates into a simple rule:
Know the crux of your application and stick to it.

When you set out to start a new project, get your users to agree upon the problem to be solved and do whatever it takes to solve that problem; not a penny more, not a penny less.

Software for Everything is as enticing a concept as the Theory for everything. I think there's a reason we haven't found it :-)

Cumulative Flow Diagrams

2008-12-16T09:35:00.000-08:00

Once you have your wall in place, it’s time to start monitoring your progress through the project. Best done on a daily basis and best done with a “Finger Chart”. Here’s an example.

A finger chart is basically your wall turned sideways so that your swim lanes are horizontal rather than vertical. Now what you track is the number of stories in each state (finger).

This chart may not make sense to you immediately but there’s a lot of useful data hidden in here. Here are the different inferences you can make by looking at a finger chart.

1) Bottlenecks
The first thing that you monitor on a finger chart is bottlenecks. This is easy. Just check for a band thickening consistently. A band thickening means that there is either a capacity problem or a capability problem in the next band. For example, the BA/QA band consistently thickens a suddenly rises at specific intervals. This is because the Client is signing off the stories only at the end of each week. This may be due to various reasons which need to be investigated to see if something is wrong OR can be made better. The ultimate goal is to achieve a smooth graph.

2) Work in progress
At any given point if you measure the total across all bands vertically, it will give you the total work in progress. This is a total of everything that needs attention from someone or the other on the team. Always try to keep this as low as possible. You should ignore the Celebration State for this calculation.

3) Average Turnaround Time
If you measure the time across all bands horizontally, you get the turn around time for a story. This is a good measure of your entire process. How lean your processes are, how good the team is, how involved and keen the client is, etc. This is what tells you how much time your team needs on an average to turn an idea into working software.

Remember that the finger chart is a cumulative of all stories. Therefore the top line of the graph should never dip down unless you have really reduced scope.

Now whether to track Number of Stories OR Story Points on a finger chart is an interesting debate. I will try to present my ideas on that in another post.

UPDATE : As David pointed out these are called Cumulative Flow Diagrams in the Lean world. Finger Charts is/was more of a ThoughtWorks term.

Choose your lanes

2008-12-11T20:59:00.000-08:00

Starting a new project is always fun. For Agile/Lean teams setting up the story wall is a part of the fun.

Some would say you are defining the process that you want to follow. The life-cycle of the user stories from being analyzed to delivered. But there’s more to a wall than defining the story lifecycle. In its wall the team chooses what it wants to monitor.

The lanes on the story wall are statuses in which the story can be. An agile team wants to track these statuses to quickly find problems that are slowing the team down. These problems can broadly be classified into two categories.

Capacity Problems – Found by tracking Wait States

There is a bottle neck because people have too much on their plate
Can be solved by
- Adding more people
- Finding out better ways of doing the work
- Prioritizing the work correctly
- Making the process leaner by removing statuses

Capability Problems – Found by tracking Work In Progress States

There is a slowdown the right people are not doing the right job
There is are problems external to the team which are slowing the team down
Can be solved by
- Training people if there is enough time
- Bringing in specialists who can help out
- Addressing external problems

Monitoring every state that the story is in is ideal but not optimum.

So choose your lanes keeping in mind what you want to monitor.

When something is not happening on its own, make it a ritual by adding a lane.

Keep your process lean by removing unnecessary statuses from the wall as well as the process.

Can't negotiate size... and a good thing too

2008-12-09T20:50:00.000-08:00

In many companies the Business Analyst or the Project Manager “estimate” the project and bind developers on the project to that estimate. This is an absolutely brutal thing to do to your project. But even within agile teams where the developers estimate, the Business Analysts or Project Managers sometimes tend to challenge and negotiate developer estimates. Not because they don’t trust the developers but merely out of selfishness. Because it gives a tremendous kick to deliver something that a client wants faster.

Now if the team is “estimating” in a “time based” unit such negotiations make some sense. Because a developer might say “Well I’ll take 3 days to do it but developer X is really good at XML so he can probably do it in 2 days”. And that might help given that you can assign the task to developer X (who in all probability is good a everything).

Another way of doing this is for the team to “size” user stories based on relative complexity. Here’s how it works.

As a developer on the team you are only classifying the stories into buckets of high, medium or low complexity. Nothing you can do is going to change the complexity of a given story.

As an analyst or project manager on the team please don’t ask developers questions like “Are you sure this is a 4-pointer?” The only one who can simplify stories is you.

Something Faster is better than Everything Later.
Everything Faster doesn’t exist

What are we doing?? - Part Three

2008-11-25T00:56:00.000-08:00

This is what got me thinking about "What (the %*&$) are we really doing?". Are gazillions of dollars being invested in IT, by organizations just trying to maintain their status quo? As the study shows, this is partly true.

Businesses require to grow for survival.
Growth requires accommodating more and more people and systems into your business.
It is very natural (and useful) to be paranoid of these new people / systems.
As businesses grow they have to become more or less bureaucratic.
Bureaucracy requires additional processing power.
This power can either be man OR machine
If the business chooses to invest in machines, we, the IT guys, make some money.

So that is what we do.

We help businesses grow...
...grow by overcoming their paranoia by automating bureaucracy...
...bureaucracy which is only bound by the stakes...
...stakes which are ever growing.

To be honest, I am still not totally convinced that this is all what software is about. What do you think?

What are we doing?? - Part Two

2008-11-25T00:10:00.000-08:00

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 ;-) )

(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
(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)
(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.
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

2008-11-24T22:20:00.000-08:00

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...

Business Analysis and Quantum Physics

2008-09-11T12:18:00.000-07:00

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

2008-09-11T12:11:00.000-07:00

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

2008-04-08T12:14:00.000-07:00

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

2008-02-15T00:36:00.000-08:00

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...

2008-02-12T21:46:00.000-08:00

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.

Celebrate small successes
Get regular feedback from clients (showcases)
Let the whole team know what we will be focusing on in the next iteration, including the business context around it (Iteration Planning Meeting)
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

2007-11-29T04:03:00.000-08:00

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

2007-02-14T11:32:00.000-08:00

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

Mountains to climb

2006-12-03T21:44:00.000-08:00

Business Analysts work closely with the customer. Each new area is a challenge. There are discussions and problems and solutions. Both the analyst and the customer get comfortable with the idea of finding better, simpler solutions. This is especially true for fixed bid projects, as the project is at stake if the analyst fails to find a simpler solution and convince the customer too.

Solving problems is always exciting. For an analyst, this is the juicy part of the job, because no human being can survive for long just writing word documents one after the other. One incentive is customer delight, second is developer delight (scope reduction, etc). Of course the kick that an analyst gets out of solving a problem and offering a relatively simple solution is inexplicable.

However, sometimes it happens so that the analyst gets stuck. There is a complex requirement that he/she gets from the customer and as usual the problem solving starts. The solution however seems complex. The situation is there right in front of him, all the scenarios are known and the functionality required to cover all these scenarios is just simply hugh. So the story is left half way through. More thought is put into the problem in wake of a simpler solution.

What the analyst fails to realize is that there is no simpler solution. Sometimes there's a given amount of work and it just has to be done. The sooner this realization comes, the better.

The time spent on a given story is I think, the best indicator of such a situation. Just measure the average time you take for a story. Probably coupling it up with the dev (complexity) estimate would be even better. So if you are taking much more than this average time, there's somthing wrong.

For Example: You take 6 days to analyze and write a (roughly) 3 point story. If you realize that this one story has gone on for 15 days, it's time to stop and think.

In case of such a situation,

Firstly, raise the fact and see that the whole team knows about this hugh chunk of work coming. Have a domain session and share your knowledge.

Secondly, prioritize this area. Change the release plan if required. This will most probably turn out to be a risky area.

And most importantly, start work as soon as possible. Just write a small, testable story and get the area kicked off. IMHO it is acceptable even if the story doesn't provide much value to the customer. It will provide value to the team by introducing an area.

It's like looking up at a mountain and thinking about a simpler way to reach to the top. Most of the times it's smart to start climbing.

As someone has rightly said, "Thought is supposed to be a guide for action. Not a substitute for it."

How to eat an elephant?

2006-12-02T19:41:00.000-08:00

The only way to do that is to cut the elephant into slices. Slices which are small enough to be eaten because the sole purpose of cutting the elephant is to make it possible for humans to eat it.

You'll need a certain number of people to eat a whole elephant anyway. If you make slices small enough, at least they won't feel sick at the end of it.

There is no overhead in the activities of choosing the piece that looks most delicious, putting it in your mouth, chewing it and swallowing it. There is some, but it definitly beats having to swallow the elephant whole.

So don't try to be subjective or pragmatic or take a case by case approach. Don't fool yourself.

Write small stories.

Applied Integration

2006-10-16T12:36:00.000-07:00

For a while, I have had a question on my mind that I couldn't really find an answer to. I had almost forgotten about it but a friend brought up the same question and before I knew it I was giving him my take on it. Before I get to the question though, I want to write a little about integration.

Last release I was involved in building some functionality to integrate with one of our client's systems. As I understand it, there are four prominent characteristics of integration that should be kept in mind when we decide to integrate systems.

1. Specialization
Integration arises out of the need for specialized systems to come together to attain a common goal.
Although each system can help in a unique way, none can achieve the goal by itself.

2. Communication
Integration is communication and all the rules of communication apply.
- Common language
- Interchange of information
The goal of communication is to get to a win-win deal.
Communication is feedback, well, at least most of it and this feedback is the basis of integration

3. Functionality on both sides

There is functionality on the other side. You are integrating with a system because it has something to offer. The goal is to leverage the information / knowledge / functionality on both the sides in a lesser amount of time than is required for any of the systems to attain the goal by itself.

If the Matrix is ever built (in a reasonable amount of time that is), it will be through integration of various specialized systems rather than all by itself.

4. Compromise
In order to communicate effectively, there is compromise required on both sides.
These compromises are mostly in the form of language & time.

I found myself using this understanding to explain my point of view to my friend. The question I was struggling with was,

If I do my job right, will everything work itself out?

I readily realized that this was stupid. However right I did my job, I couldn't achieve anything in a reasonable amount of time. So I changed my question to,

If we all do our jobs right, will everything work itself out?

This seemed promising. But I realized that, my job is my specialization and that's true for all of us and when working together, feedback is important for us to know that we are doing our job right. Without this basic integration we are hopeless.

Any team brings in integration of many specialized systems. Developers, BAs, QAs, Project Managers & Clients, for example, in a software development team. To take part in this integration, communicate useful feedback and leverage each other's "special powers" by making necessary compromises is the only way to build the Matrix... Or for that matter a library management system.

Embracing Bunker Busters

2006-08-19T11:27:00.000-07:00

For various reasons, there are situations when there is no running away from a Bunker Buster. An agile team should therefore be watchful. Once the analyst finds a potential bunker buster, he/she will have only one parameter to tweak... The timing. Embracing a bunker buster is a a brave step, I would say. But then isn't, bravery only relative to the preparation??

Symptoms
Here are some tips out of my experience for identifying bunker busters. Note that these symptoms do not decide a bunker buster individually. Like gesture-clusters in body language, they work in combinations.

Vagueness
The first and most probable characteristic that you'll notice about a bunker buster is vagueness. This is not the same vagueness that you experience when you don't know the screen where particular information is captured. This is vagueness which has potential to change the way you have been thinking about the solution. Some fundamental assumptions about the way the user is going to use the application could be proven wrong at the and of your analysis. This brings us to the next characteristic, The Paradigm Shift...

Paradigm Shift
Over a period of time in a project, the team develops an idea of how a user is going to use the application. A bunker buster has the potential of changing this basic usage paradigm. Let's take an example here.

Imagine a phone book application. This application allows Adding, Editing, Viewing and Deleting phonebook entries. The team envisaged this application thus:
- The user will search or browse the phone book to find a particular entry.
- The user will then view the details of the selected entry.
- The user then has the option to Edit or Delete an entry
- The function for adding a new entry is available throughout.

Now after some time into the project, the business and the analysts realized that the users that search, browse or view entries are different from the users that add, edit or delete entries. The solution was to select a mode while entering the application. The user would be able to only add entries in the "Add" mode. While the "View" mode would let users only view an entry.

This is a paradigm shift. While most bunker busters we see in reality are not of this magnitude, I hope you get the idea.

Extra Long Analysis Phase
Both the above lead to an unusually long analysis phase for this particular story. Another fact that contributes to this is the fear that there might be exceptions. While the new usage paradigm makes sense from the usability point of view, there might be functionality which will make less / no sense if the user is going to use the application in a different way!

Approach
To get consensus of all the stakeholders on this new paradigm, to clear up confusions, to find and take care of exceptions (if any) and to present all this in the form of a small, independent, testable and valuable story is a mammoth task. To make this a tad easier, here's a list of things to take care of when dealing with a bunker buster. I have divided this by stake holder because the underlying gist is to communicate constantly with everybody.

Client
Communication with the client is always crucial. After sometime into a project analysts generally split into areas and so do the members of the client team. While handling a bunker buster however, constant communication with the complete client team is essential. I would include all business as well as technical users in this. End users, sponsors, client's system administrators, deployment team (in case you are building a product) and of course the complete client team that defines requirements. The shift in usage paradigm is a key decision on which you would need all kinds of input and a consensus from all the mentioned parties.

BAs
Other business analysts are the best people to talk to when it comes to finding exceptions. They will have complete knowledge of the respective areas that they are working on. Also, early communication of this kind will help them analyse the future functionality keeping the bunker buster in mind.

QAs
One thing that closely matches the way an application is going to be used is the functional test suite. Functional tests are the most valuable and the most fragile tests on a project. A bunker buster can render loads of them useless if they are not refactored to accommodate the new usage paradigm in time. Depending on the size of the functional test suite, the QAs will have to decide whether to refactor them or throw them away or leave them untouched. The QAs can leave the tests untouched if the application can provide useful hacks, like switching security off. Of course there are other functional tests that test security. Personally, I think this is the last resort. Functional tests should always be in sync with the way the application will be used.

Developers
Communication with developers is of vital importance because a bunker buster has potential to change the domain model in unexpected ways. Validating the feasibility of the change and it's estimation is absolutely crucial. While the bunker buster is in play, I would suggest even pairing with the developers. One area where it will most hurt is the amount of detail in the story itself. Due to the long phase of analysis, accommodating all the detail in the final story is all the more difficult. Remember that while you are busy preparing this story for play, there is functionality being added to the application. I think this is one more place where it would be much better to leave the story at a high-level, do a careful kickoff and if possible pair up with the developers.

Timing
As mentioned before, timing is possibly the only parameter that we can tweak as a team and taking full advantage of this fact is very important. Due to the consequences mentioned above, I think it is best to play a bunker buster at the very beginning of a release. That way the UAT for the previous release can go smoothly. The team also gets a logical break point to adopt this new way of thinking about the solution... Mentally(analysis) as well as physically (code and tests).

Scary as all this may sound, I guess successfully embracing changes like these is the ultimate value that an agile team delivers.

Avoiding Bunker Busters

2006-08-13T12:20:00.000-07:00

"Prevention is better than cure" and one good way of handling Bunker Busters is to avoid them. Agile teams seem to be wary of handling anything by prevention, as it requires thinking ahead and taking care of things to come rather than things that are. While this makes perfect sense for Grenades and Shells, Bunker Busters have much more potential for damage and it is worthwhile trying to prevent them rather than handling them when they come.

There are areas in every application which can prove to be huge bunker busters if not handled in advance. Teams are even aware of there existence but still choose to handle them "when they come". One such area is "Application Security" and I have heard about (and experienced) this quite a lot so I think it makes a good, simple example.

Let's go back to the way we write stories. The story aims at stating a particular requirement in the form of an action, which a particular role wants to perform to achieve a specific, measurable, achievable, realistic and time-bound goal. The generally accepted form of such a story is a single sentence as follows:
As a <role>
I would like to <action>
So that <immediate goal>

A Grenade in this form would look like:

As an administrator,
I would like to add a new book to the library,
So that the book can be borrowed by the borrowers.

Now this is a good story because it can be easily implemented to achieve the following:

A form which only the administrator can access [role]
Logic to validate & persist the information entered into the form [action]
tests to check if the book can be borrowed by the borrowers (which is another role BTW). [goal]

The "So that" clause here does two things. It sets the testability of the story as well as clearly mentions the dependancy.

Leveraging all clauses of the story in this way (and firstly writing stories in this way) can go a long way in favour of the project.

The same story would become a Shell, like this:

As an administrator,
I would like to restrict other borrowers from adding a new book to the library,
So that I can control the books added the library.

(this will be played in addition to the first story, because we decided to do security later)
Sounds worse, does it?? But it can get even worse like this:

As an administrator,
I would like to restrict borrowers from adding new books to the library, editing book information, deleting books from the library, viewing x,y and z reports and configuring x, y and z,
So that I have full control of the admin functionality of the application.

(this story will be played after the stories for all the above functionality have been played...)
This is a bunker buster; and the worse part is that this could be avoided.

(Note: the second and third stories aim at delivering the same functionality, although the reader might think that these are stories will let the administrator "configure" access restriction to the mentioned parts of the application.)