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

Mountains to climb

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?

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

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

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

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