The necessity to adapt

One of the more exciting things about being an analyst at ThoughtWorks is that you get to be at projects of very different business domains.  On one project, you could be in an investment bank, sitting in a room next to the trading floor; or, you could be studying the differences between 5 different designs on presenting a retail trade show, and you are within earshot of a fashion shoot.

Such differences in the physical working environment scream of an indicator of how you may need to adapt your ways of working.  Adapting your ways meaning that you need to tweak how you communicate and deliver your ideas to your audience so that the message can be heard in the correct way.  Same everywhere else, same for Agile.  The specific method of execution needs to be tailored to the specific needs, wherever you are.

Some of these so-called differences are apparent, for example, working environment or physical space that the project is located, others are more subtle and is picked up through interaction.  As analysts, we not only learn about the kind of tools that help facilitate people, but in what situations you would apply them and how.  By acknowledging these differences, it may help you to identify the best possible approach you take whatever project you are in.

Here is a sample of things that have helped me through various projects.

Adapt your tools

Capturing requirements on the fly from day zero is a big part of analysts.  Just because you are capturing requirements, it does not have to be done in one rigid way.  At some point, you may be doing this on 4″x6″ index cards, it may be on Excel if you are faster at typing, or you might even be doing this on Mingle.  Choose the method that is best for you and the situation.  What’s important as an analyst is that the essence of the story and the ideas behind the conversation are being captured.  You can do this quickly as long as you can recall such conversations or the high-level idea, because it allows you to go back to the people who first came up with them and continue with those conversations.  That is the main goal of your actions.

For instance, when you are in a time-pressured scenario such as story writing workshops, you could not afford to spend all your time in one afternoon discussing a handful of stories only (if you did that your inception would probably last for months, and would lose all the other valuable conversations that you could probably have had instead).  Scribble things using pen and paper, carry a fancy Moleskine to not lose the scraps of drawing (or the notebook even).  What about the white board and taking photos on your smart phones?  Present it on your iPad?

Adapt your methods

How you present your captured requirements is just as important as what you have written.

In a previous project, the clients were extremely visually oriented people and do not respond well to lists, documents or narratives well.  Or anything that consists of reams and reams of text.  In these circumstances you either go ahead and do it anyway, running the risk of your clients losing interest in the meeting, or you think of other methods of communication that will capture your audience and convey the same message well.  This resulted in facilitating a prioritisation workshop with images drawn on  cards.  I sometimes capture conversation points on a mind-mapping tool — simply because visual tools speak louder to me and I love being able to present this to the client.

Adapt your own interpretation to the local domain

Not literally the local language (though I have done this), but adapt your vocabulary to the client’s.  Immerse into their world.  Use their domain language to break the communication barrier, and you will find that you would not be fighting so many battles based on trivial things such as “We call it Iteration and you call it Sprint”, and instead focus on solving real world problems.

Continuous improvement and continuous learning

Agile is not a prescribed set of methods that, once utilised step-by-step, it will solve all your problems.  It defeats the name and defeats the point, really.  The trick is not apply any single tool so blindly that you hinder yourself from spotting a different way to solve a problem.  I have seen far more dangerous practices / restrictions that have been applied to projects or departments that, in the end, did more harm than good.  Just because you do stand-ups, you are not Agile (you are still practising waterfall methodology everywhere else).  It is not a label associated with a practice.  It is the underlying principles of Continuous Improvement that so many overlook; of knowing that you are not here to adhere or conform to the set of rules, but to continuously look for a better method of doing things; constantly asking yourself this question, knowing that you will inevitably find those improvements that will outdo and outsmart your previous ways.

It is not about coming up with the smartest, sophisticated system and let monkeys run wild with it; it is actually putting the smartest people you can find in any system and trusting them that they will come up with the smartest system for themselves.