Archive for February, 2008

Agile India – Myth Buster

February 12, 2008

 Introducing Agile in India, the Agile India 2005 conference jointly organized by the Agile Software Community of India (ASCI) (founded by a group of enthusiastic Agile practitioners from companies that practice Agile Software Development methodologies) and Symbiosis Institute of Computer Studies and Research (SICSR) saw a lot of serious discussion and a lot of fun.  It was also a huge success, evident from the fact that Agile / XP are becoming more and more popular in the Indian Software Community.  Which, a bunch of Agile enthusiasts in Bangalore proved by forming an Agile India Users group.  Research on Google searches and you will notice that a large volume of agile development searches are coming from Bangalore, India’s answer to the Silicon Valley in California, US of A.

And, while the rumour floated says, the original Agile Manifesto was drafted by all white males, Primavera Systems Inc., a vendor of enterprise project management software, busts the myth that agile processes will keep development jobs in the United States, by using the agile development process and outsourcing product development to the Indian operation of product engineering outsourcer Symphony Services Corp.  Symphony that uses agile development techniques for eight software companies.

Along similar lines of the East West Great Divide, we have Michael Hugos writing for CIO magazine and website – a part of International Data Group (IDG), the world’s leading technology media, research and event firm, stating that his experience and observations have lead him to conclude, India is capable of being just as agile as America.  A 30-Day Blitz in India and matching his Indian experience with that of IT teams in the United States, he found that on both continents agile concepts slowly took hold, while agility proved to be as much of a challenge for some team members, as it came more easily to others.

Thus, for the bleached half of the Great Divide to debate whether the relative newness of these ideas and cultural norms would make it harder for Indian developers to embrace these concepts is not only racist in nature, it shows that the West continues to suffer insufferably from a superiority complex, a lingering hangover from their colonial days.  It’s just like saying ‘White guys can’t jump’ or in Michael Hugos own words: “What I see though, is that it’s unfair to say Indians can’t be agile just as it’s unfair to say that white guys can’t dance (being a white guy myself, I’m very sensitive to that particular generalization…).”

Hugo writes that across the Great Divide Agile behaviour transcends cultures, with people on both sides starting off with a ‘can-do’ attitude and a high level conceptual system design, followed by a deeper probe into production system creation details, negotiation attempts to cut scope, and much resisted by business people.  This was followed by teams going off to put together the hardware and software components, and on testing saw the components actually worked as envisioned, their enthusiasm was once again fuelled, with renewed cooperation and exploration of options replacing earlier reluctance and bargaining, as the agile spirit manifested itself and they sprinted to the finishing line.

Ergo, not only is it politically incorrect but also down right ridiculous to question Indians or for that matter any ethnic community’s ability to be Agile.  One cannot say traits exhibited in Agile teams are cultural traits, they are traits of an individual and there are people in both American and Indian culture, including other cultures who manifest these traits.  And, for a country like India who is fast turning into a very entrepreneurial country, entrepreneurship means agility, and as history proves that Indians have exhibited more agile entrepreneurship than any other race or culture in their travels and setting down roots across the globe.

While, it is true that India is less experienced in Agile tactics and techniques, it does not mean they cannot and are not learning fast.  Already, a number of firms, such as, Net Solutions and Xebia, employing Agile techniques with considerable success, recommend agile approaches to software development because they deliver value to organizations and end users faster and with higher quality.  As for, Thoughtworks India, their projects are ‘pure Agile’.  So much for generalisations about agility being the exclusive domain of any one culture!  That’s like Hitler and his Nazi’s ludicrous claim that Aryans are a race of blond, blue-eyed giants.  To bust that myth, I’m an Aryan of warm golden skin, brown eyes and black hair.  That makes me feel like jigging to on Boney M’s song:

‘Brown Girl in the Ring!

Tra la la la la!There’s a brown girl in the ring!

Advertisements

Agile Testing

February 2, 2008

As new and better software development ways are being uncovered, the following holds much value i.e.:

  1. Individuals and interactions over processes and tools.
  2. Working software over comprehensive documentation.
  3. Customer collaboration over contract negotiation.
  4. Responding to change over following a plan.

 Two key imperatives underlying these values are: 

Work Code

A general thumb of rule is that programmers are more comfortable getting on the computer and getting it to do something, than writing documentation.  Similarly, Agile believes in the Hands-On Imperative and extends it even to users.  Why?  Because, most mental activities need external resources, with different resources making us think in different ways.  And, that is why people who document or design models, think differently from those working on software.

Because, Agile projects understand that, they deliver working software (or perhaps executable proto-types) as quickly and as frequently as practical.  Development is a rapid series of functionally complete releases the user can try out.  Each release being the first chance a user’s had to think about new features, means re-work on the release is just part of the job, not a crisis. 

Open Communication

With little or no documentation, Agile projects keep everyone in synch due to increased human contact i.e. face-to-face conversation and collaboration.  XP has people programming in pairs, with most often a customer representative working most days in the bullpen with the developers.  Scrum holds daily stand-up meetings that create and preserve group understanding.  Crystal, perhaps the least dogmatic process conceivable, nevertheless insists on frequent retrospectives.  All these techniques tend to foster communication that documents cannot replace.

And, since all Agile methods want a customer to be part of the team, with a suitable customer representative on hand, one does not require a detailed requirements document.  You have a question, simply turn around and ask it!  Worried the right question won’t be asked?  Well, you can implement something and show it to your customer for a quick reaction.  Without much ado about nothing, you’ll quickly learn if you’re going off track. 

Agile Testing

These same imperatives can also underlie Agile Testing, and most obviously apply to Agile development projects.  However, they work, though less well on conventional projects, as well.

But, first abandon the idea that communication is about one party communicating with requirements and design documents, while the other comes back with test plans and bug reports.  You know full well that documents tests are based on are flawed i.e. incomplete, incorrect, and ambiguous and to be viewed only as interesting texts, partly fictional, often useful.

Agile testing communication should be all about joining in and encouraging ongoing project conversation.  Testers and developers need to sit in the same bullpen or share offices.  Testers should be made help particular developers, rather than just testing how pieces of the product work.  ‘Drop-in meetings’, short, informal discussions, etc. help in test status reports via big, public, simple-to-read charts that answer specific development questions, such as, which product parts are working well.

Communicating with the customer is as important as communicating with developers, as more often than not, the customer is trying to figure out what is needed, what they want, whether they are getting it.  And, they can only do this by testing the working code and talking to the developers and testers.  Testers should sit down with them as try out the product sample, as creating tests together is an excellent way for both to learn what matters.

Hands On helps developers improve and complete the product and value tests they can run as they develop.  While, Agile Testing may not be the answer to all projects, neither are any of the Agile Methods.  Acutally, no single approach is, but experimenting with different project styles is essential if a standardised software development practice is to be arrived at.