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

Grenades, Shells & Bunker Busters

As agile business analysts, we try to keep our stories small, independent, testable and valueable. Once in a while, though, we come face to face with a Bunker Buster and everything starts looking scary.

Impact

Every story is likely to impact a certain portion of the developed application. Measuring this impact and using it to "time" a story well, is something commonly ignored by business analysts. This doesn't mean that the analyst or the team doesn't know the impact of a story but this measure is not used in planning exercises effectively.

We can almost categorize stories to get a quick idea of the impact that they have on an application. In my experience, there are three such categories

Hand Grenades - Stories that add functionality
This means these stories add completely new functionality. These stories impact a very small part of the application that has already been developed.


Shells - Stories that enhance functionality
There are stories that form latter parts of a series which enhance already developed functionality. These stories bring in minor refactorings and hence their impact is rarely beyond the code written to deliver that particular functionality.

Bunker Busters - Stories that enhance the application
These are the stories that aim at enhancing the "complete" application. A common example of this species is application security. Inevitably, there are areas of the application that only privileged users can access. These kind of stories bring in major refactorings and hence have an impact on a considerably larger proportion of the code already written.

Handling Bunker Busters
In a ideal world, a business analyst will deal with Hand Grenades and Shells. But things are not that simple all the time and we need to handle a Bunker Buster once in a while. There are 2 approaches towards handling these stories.

Avoiding
The first approach is to simply avoid a Bunker Buster by reducing it into several Hand Grenades or Shell stories. Carrying the example of security forward, we will think about the security involved, everytime we add or enhance functionality and thus split security across several Hand Grenade and Shell stories

Advantages:

• Less / No impact on existing code
• Tests (especially functional ones) remain healthy and effective
• Stories become really independent and valuable
• Planning becomes simple

Disadvantages:

• Requires upfront thinking and design
• Inclusion in all stories

There are areas like security, common to most projects we do, which can be handled using this approach looking at the trade off between upfront design and ease of implementation.

Embracing
The second approach is to play a single (generally huge) story which impacts a whole lot of developed functionality. In many cases this option is inevitable because the required functionality was never thought of.

Splitting this story doesn't make too much sense because the result tends to be half-baked functionality which poses even more problems. Timing this kind of a story is something that the team needs to be careful about. This story is likely to impact a large proportion of code as well as tests besides bringing in all the disadvantages of large stories with it.

Considering these impacts, the team may decide to :

play these stories as soon as discovered and refactor code and tests as required
OR
play these stories at the fag end of the project by leaving existing test untouched and testing this functionality seperately.

For more on Bunker Busters, stay tuned...

Deceptively small stories??

For sometime now I have got the feedback from developers, that the stories I write look small but have loads of work to be actually done and they get under estimated during the Iteration Planning Meeting. Now when I asked for a way in which I could make the story look as big as it is, I was given the idea of putting tasks in the story.

I have used this method for sometime now and I find myself writing things like:

TASK 1: When the user clicks "OK" an empty Word template should be uploaded to the server and then the same file should be opened for editing

whereas I would have generally written:

Clicking "OK" should open MS Word with an empty template so that the user can edit the contents.

While this puts implementation into the story and makes the story really bulky, it seems to really help the devs and may even be of help to a technically inclined client or the client's IT department which is going to take over the maintenance.

I think distributed agile makes us take many such deviations from the pure form of agile ideas we have read about. Most of these are justifiable in terms of the trade-off between concepts like "minimum documentation" and "transparency / knowledge sharing". After all isn't agile about doing whatever it takes to quickly deliver value to the customer??

Communication Patterns

Incidentally my earlier post was about how Distributed Agile works. My unexpectedly long web silence was infact due to the current DA project that I am working on.

One interesting thing that we get to observe is how the communication patterns change over time, amongst the local team and also with the distributed team.

There are few specific things that I have observed during the last 5 months on this project, which I would like to bring up here. All of these relate to the communication that happens across oceans.

Overview
Last few months I have been busy on a Distributed Agile project. I feel obliged to put down my observations of the changes in the way communication takes place between distributed teams.

The typical setting renders the following arrangement:

1. Client (since this is about communication we restrict clients to be the people who give requirements. NOT sponsors or end-users)
   
2. On-site BAs
3. Delivery Team. This is the larger team that does the development and consists of BAs, QAs, Devs and an IM/PM
   

Note that the patterns of communication enlisted here use the above setting as a base. They may not be similar to the way distributed teams work when actual delivery is distributed.(That'll be covered in part 2, if there is one)

Communication
Communication is arguably the most emphasized practice in Agile methodologies. A perfect agile team will communicate in these ways (in order of preference)
- face to face
- video conferences
- voice conferences
- email or other documentation.

Small co-located teams will easily handle communication amongst themselves and with the client. It is the larger teams that find it difficult to manage without emails / documents and it gets worse when the teams are distributed and have to work with each other across seas.

This is a collation of my experiences about how the communication patterns evolve and affect the project.

Context blues
When the project begins, a very small number of people have had a chance to meet the client face to face. To make things worse, the team that ramps up, and starts to increasingly communicate with the client, is the team which is going to deliver the software. This is the 3rd entity listed in the overview.

The BAs in the ramping team lack 3 things that makes communication effective. These are listed below in order of importance.

Business Context
The first thing that the delivery team lacks is the business context in which the solution is to be provided. The Business Objective behind this project and the criticality of the project success are the fundamental things that let the team organize it's thoughts and actions towards a common goal which is more or less inline with the client's expectations.

Client Context
The second thing that hampers effective communication is the lack of knowledge of who the client is. It is of high importance that the delivery team is aware of the client's position and the stake that he has in success of the project.

Client
Knowing what the client is like, is also very important to be able to communicate effectively. Having met the client personally impacts the effectiveness of communication a lot.

This is the first phase of the communication with the on-site team. Another interesting feature of this phase is the importance of the on-site BAs. The on-site BAs do not lack any of the things listed above, which makes them many folds more productive and hence important to the project.

Infrastructure blues
This is the second phase of the communication evolution in a distributed agile project. This is the phase where the delivery team reacts to the earlier phase of lack of context. The immediate solution which is put forth is to strengthen the communication infrastructure so as to get as "close" to the client as possible. By the order of preference given above, the team rules out the face to face communication and promptly moves towards video and voice conferencing solutions.

This phase features infrastructure failures which are acted upon with varying degrees of success and in the end, stabilize.

Delivery team amnesia
This phase is a result of the rising ease in communication with the client. The delivery team now has ease access to the client. It also has most of the necessary context of the project. The development also starts showing real progress by this time and hence the delivery team now gains importance. It has to get critical questions answered, give development support and show progress via showcases.

All this action tends to give the delivery team intermittent amnesia about the existence of the on-site BAs. This is a pattern that continues in varying degrees throughout the project. For countering this particular problem the team comes up with a schedule to communicate with the on-site BAs. This turns out to be a decent solution but it fails every time there is a change in the schedule. Every change then takes time to stabilize.

Guests and parties
By this time the delivery team is using the communication infrastructure to the full extent. But there is still some context that's missing and the delivery team starts becoming more and more aware of this fact. There is a strong strong need to talk to the client face to face.

The project has more or less stabilized by this time and so the cross-pollination as well as client visits to the delivery location take place. Many important decisions, sessions, context & knowledge sharing happens during these visits. There are invariably some tricky areas/issues to be discussed during these sessions. Making the most of these sessions is one responsibility that the BAs should really handle well.

Another amazing effect of the visits is the trust that builds between the client and the delivery team because now the client actually sees the work going on and progress being made. This is a good opportunity for the delivery team to bring to the clients' notice, the implications of their actions (or inaction). Signing off / giving feedback on functionality that has been developed is a major participation required from the client. Demonstrating how this feedback is taken and worked upon helps the delivery team to considerable extents.

These visits also enable teams members to spend more informal time with the client. Team outings and sight-seeing are important parts of these visits.


Stabilization
This is the phase after the client visits are over. Whatever major issues were to be discussed have been discussed and decisions reached (well, almost). This is the golden phase in the project where everyone is much more clear about what they need to do and when to do it and that includes the client.

This is the phase to be reached by a distributed agile project as soon as possible. It is generally not possible to jump these phases and get to the stabilization phase early. It is however, quite helpful to understand that these phases will come and will need to be handled.