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.