Posts Tagged ‘agile’

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!


Taking Agile Mainstream

January 9, 2008

This blog, perhaps, repeats what we talked about in Agile Introduction For Dummies – Part I and Agile Introduction For Dummies – Part II, but it is essential to ensure that one understands the dynamics of Agile methodology clearly.  So, here we go once again!

The past few years have seen software methodology adopting a new style and going agile!  Well knownas Agile Methods, the style is adaptive; people oriented in nature and have stirred up a whole lot of interest.  It is also seen as an antidote to bureaucracy or licence to hack. A reaction to engineering or plan driven methodologies, agile methods are an attempt at compromising between no process and too much process, providing just enough process to gain a reasonable pay-off.  As well, Agile Methods tend to be:1.       Adaptive rather than predictive.  Engineering methods mean a planned detailed software process covering a long time span and a nature that resists change.  Agile methods, however, welcome it, trying to be processes that adapt and thrive on change, even to the point of changing themselves.2.       People-oriented rather than process-oriented.  Engineering methods work at defining processes that will work for whoever uses them.  Agile methods assert a process cannot match the skills of a development team, only playing a support role in development team work. Exploration of the differences in detail makes it easier to understand what adaptive or people-centred processes are about, their benefits, drawbacks, and usefulness if used by developer or software customer. 


Separating Design and Construction

Design and construction, two fundamentally different activities show that difficult to predict design requires expensively creative people, while construction is easier to predict, and only once design is in place, can easier to predict construction begin. 

Unpredictability of Requirements

In every project, developers can be heard complaining that the problem with the particular project is that requirements are always changing.  Not surprising, as in building business software requirements, changes are the norm.  The question is what is to be done as software development is a design activity that is hard to plan for and estimate the cost for, as basic materials change rapidly and much depends on which individual people are involved resulting in unpredictability. 

Is Predictability Impossible?

Generally speaking, one cannot say predictability is not predictable.  While, it is very desirable, however letting it go does not mean reverting to uncontrollable chaos.  All one needs is a process that gives control over unpredictability, which easily explains what adaptability is all about. 

Iterations – Controlling an Unpredictable Process

So, what is the key to an unpredictable world?  Is it iterative development or frequent production of the final system working version with a sub-set of the required features?  While iterative development is short on functionality, it is otherwise faithful to the demands of the final system; hence these features should be fully integrated and carefully tested as the final delivery for best results. A far better process than traditional methods where before doing anything else, the entire process is documented, and as one knows documents can hide all sorts of flaws, as does untested code.  However, sitting in front of a system and working with it, allows these flaws to become truly apparent, both in terms of bugs and misunderstood requirements. Agile, an iterative and incremental development process is adaptive in nature and can totally deal with changes in required features.  This means fluid long term plans, as the only stable plans are short term plans made for single iterations.  AS well, iterative development also gives a firm foundation to each iteration, which means later plans can be based around it. The key question is, how long should iteration be.  Different Agile methods suggest different time frames, e.g. XP suggests iterations of one or two weeks, SCRUM suggests a month, Crystal stretches it further.  However, the tendency is to make each iteration, as short as can be got away with, as this not only provides more frequent feedback, but allows you to know where you are more often. 

Adaptive Customers

An adaptive process requires adaptive customers, since it gives them much more control over software development processes.  They, not only get to check progress made at every iteration, they can also alter the direction of software development, which often results in a much closer relationship with the software developers, a true business partnership. The customer benefits, as there are a number of advantages to using agile methods, such as, much more responsive software development and an usable, although minimal system that goes into production early on.  As well, the customer can change system capabilities according to changes in business, and is also able to learn how the system is used in reality allowing for risk control, which is indeed, a key advantage of iterative development.  Further, keeping iteration lengths small means variations can be seen in different ways. 


Another attraction of agile methods is that they put people first, since adaptive process execution is not easy task and requires a very effective team of developers i.e. effective both in quality of the individuals, as well as, team blending.  Adaptivity requires a strong team and it bodes well for agile method application to a project, since it is a well known fact that most good developers prefer an adaptive process. 

People Oriented Process Management

A people oriented process, agile process acceptance requires commitment and active involvement of all the team, as these methods like Extreme Programming (XP) requires a lot of discipline to execute, with the less disciplined Crystal approach, far more suited to a wider audience. As well, developers are required to be able to make all technical decisions, with XP getting to the heart by stating that only developers are allowed to estimate how much time it will take to do the work.  This shift in technical leadership requires developers and management to share responsibility and an equal place in project leadership.  While, management still plays a role, it also recognizes the expertise of developers. 

The Role of Business Leadership

However, technical people cannot do the whole process themselves and require guidance in terms of what a business needs, which highlights another important adaptive processes aspect i.e. close contact with business expertise. 


The term agile refers to a philosophy of software development which includes many specific approaches under its broad umbrella, approaches, such as, Extreme Programming, SCRUM, Lean Development, etc., each of them having their own particular approach and own ideas..

Extreme Programming (XP)

While, during the late 1990’s, Extreme Programming got the lion’s share of attention, in many ways it still does and it beings with five values (Communication, Feedback, Simplicity, Courage, and Respect).  It further elaborates these into fourteen principles, and again into twenty-four practices, placing a strong emphasis on testing.   While, all processes mention testing, not much emphasis is placed on it.  However, XP believes testing is the foundation of development and has every programmer writing tests and production code, simultaneously, which are then integrated into a continuous integration and build process, yielding a highly stable platform for future development. 


In the 1980’s and 1990’s, Scrum also developed as a highly iterative development methodology that concentrates on the management aspects of software development, dividing development into thirty day iterations (called ‘sprints’) and applying closer monitoring and control, by holding daily scrum meetings.  It places much less emphasis on engineering practices, with many people combining its project management approach with extreme programming engineering practices. 


The Crystal family of software development methods approaches tailored to different size teams approach.  Despite varying, all crystal approaches share common features and have the following priorities:

  • Safety (in project outcome, efficiency, habitability.
  • Frequent Delivery,
  • Reflective Improvement, and
  • Close Communication.

Lean Development

Lean movement pioneered at Toyota was an inspiration to many of early agilists, but one should be wary of the engineering separation between design and construction.  However, there are still interesting ideas to be got from the lean direction.


Using an agile method is not for everyone.  However, these methodologies are widely applicable their use should be seriously considered.  The most common methodology of code and fix often results in chaos, showing that the discipline and lightweight agile approach found missing in heavyweight methods is the better method. Start by finding projects that agile methods can be tried on, and since methods are so fundamentally people-oriented, it is important to start with a team receptive to being agile.  As well, you will also need to find someone experienced in agile methods, having learnt through making mistakes.  And, then you may find out about the many advantages of going agile! 

Agile Introduction For Dummies – Part I

January 7, 2008

In my previous post I wrote about Waterfall vs. Agile.  This post is all about introducing Agile Methods to people who know zilch about them.

Creating a buzz in the software development community, Agile Methods have drawn their fair share of advocates and opponents, with some considering agile methods to be the best thing to happen, while others are not so kind. Agile Methods are a reaction to traditional ways of developing software and acknowledging the “need for an alternative to documentation driven, heavyweight software development processes”.  Traditional methods begin work by eliciting and documenting a ‘complete’ set of requirements, followed by architectural and high-level design, development, and inspection.  Frustrating, as fast moving industry and technology requirements ‘change at rates that swamp traditional methods’, and customers are unable to state their needs even while, they expect more from their software.  As a result, several independent Agile methods and practices have been developed, methods that are actually a collection of different techniques (or practices) that share the same values and basic principles. As the development world changed and it became more and more obvious that traditional methods did not always work as intended, new people-oriented and flexible practices became necessary to cope with the changing requirements, such as:

  • Customer satisfaction takes precedence over conforming to original plans.
  • Change happens, instead of preventing it, far better to cope and reduce the cost of change throughout the development process.
  •  Change elimination means unresponsiveness to business conditions, quite simply it can spell business failure.
  • The market demands and expects innovative, high quality software that meets its needs, and meets them sooner rather than later. Thus, a discussion of new software developments methods saw the emergence of Agile methodology with representatives of Extreme Programming (XP), SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others convening and putting together an Agile Manifesto dedicated to uncovering better ways of developing software through valuing:
  • Individuals and interaction over process and tools:  Traditional software engineering lays too much emphasis on process, while it is already a known fact that people matter more than process.
  • Working software over comprehensive documentation: While documentation is important, building software is the ultimate goal.
  • Customer collaboration over contract negotiation: Contracts are important, however, customer collaboration is more so, and without which nothing goes well.
  • Responding to change over following a plan: Customers and users do not always know what they want at the outset of a software project, therefore it is essential they remain open to change during project execution. 

Agile Methods aim at allowing organizations to deliver quickly, change quickly and change often.  While, Agile techniques vary in practice and emphasis, they share common characteristics, including iterative development and a focus on inter-action and communication.  Maintaining regularity allows development teams adapt rapidly to changing requirements, and working in close proximity, focusing on communication, means teams can make decisions and act on them immediately, rather than wait on correspondence.  It is also important to reduce non-value adding intermediate artefacts to allow more resources to be devoted to product development for early completion. 

Agile movement is all about programmers that add maneuoverability to the process, so that an Agile project can identify and respond to changes more quickly than one using a traditional approach.  Agile Methods are not about practices used, but about recognising people to be primary drivers behind project success, coupled with intense focus on effective maneuverability.  True agility is not just a collection of practices; but also a frame of mind, and while other processes may look Agile, they do not feel Agile.

 To be continued in Part II


January 4, 2008

There is no IT meeting that does not talk and debate endlessly about Waterfall vs. Agile development methodologies.  Feelings run strong on the subject with many considering Agile ‘so of the moment’, just so right, while Waterfall is thought to be passé!  But, before deciding which is more appropriate, it is essentially important to provide a little background on both.


A classically linear and sequential approach to software design and systems development, each waterfall stage is assigned to a separate team to ensure greater project and deadline control, important for on-time project delivery.  A linear approach means a stage by stage approach for product building, e.g.

1.      The project team first analyses, then determining and prioritising business requirements / needs.

2.      Next, in the design phase business requirements are translated into IT solutions, and a decision taken about which underlying technology i.e. COBOL, Java or Visual Basic, etc. etc. is to be used.

3.      Once processes are defined and online layouts built, code implementation takes place.

4.      The next stage of data conversion evolves into a fully tested solution for implementation and testing for evaluation by the end-user.

5.      The last and final stage involves evaluation and maintenance, with the latter ensuring everything runs smoothly.

However, in case a glitch should result, changing the software is not only a practical impossibility, but means one has to go right back to the beginning and start developing new code, all over again.  That’s Waterfall for you!  Now, as for minimal risk Agile, it is a low over-head method that emphasizes values and principles rather than processes.  Working in cycles i.e. a week, a month, etc., project priorities are re-evaluated and at the end of each cycle.  Four principles that constitute Agile methods are:

1.      The reigning supreme of individuals and interactions over processes and tools.

2.      As does, working software over comprehensive documentation.

3.      Likewise, customer collaboration over contract negotiation.

4.      And again, responding to change over plan follow-throughs.

To synopsise the difference between the two, one can say the classic waterfall method stands for predictability, while Agile methodology spells adaptability.  Agile methods are good at reducing overheads, such as, rationale, justification, documentation and meetings, keeping them as low as is possible.  And, that is why Agile methods benefit small teams with constantly changing requirements, rather more than larger projects.

Agile, based on empirical rather than defined methods (Waterfall) is all about light maneuverability and sufficiency for facilitating future development.  By defined methods what one means is that one plans first and then enforces these plans.  However, Agile methods involve planning what one wants and then adapting these plans to the results.  Extreme Programming (XP) is an excellent example of Agile methodology i.e.:

1.      Communication between customers and other team members;

2.      Simple, clean designs;

3.      Feedback given on Day 1 of software testing;

4.      Early delivery and implementation of suggested changes. 

Agile methodology means cutting down the big picture into puzzle size bits, fitting them together when the time is right e.g. design, coding and testing bits.  So, while there are reasons to support both the waterfall and agile methods, however, a closer look clarifies why many software and web design firms make the more appropriate choice of employing Agile methodology.  The following table enumerates the raison d’être for choosing Agile methodology over the Waterfall method.

  1. Once a stage is completed in the Waterfall method, there is no going back, since most software designed and implemented under the waterfall method is hard to change according to time and user needs.  The problem can only be fixed by going back and designing an entirely new system, a very costly and inefficient method. Whereas, Agile methods adapt to change, as at the end of each stage, the logical programme, designed to cope and adapt to new ideas from the outset, allows changes to be made easily.  With Agile, changes can be made if necessary without getting the entire programme rewritten.  This approach not only reduces overheads, it also helps in the upgrading of programmes.
  2.  Another Agile method advantage is one has a launchable product at the end of each tested stage.  This ensures bugs are caught and eliminated in the development cycle, and the product is double tested again after the first bug elimination.  This is not possible for the Waterfall method, since the product is tested only at the very end, which means any bugs found results in the entire programme having to be re-written.
  3. Agile’s modular nature means employing better suited object-oriented designs and programmes, which means one always has a working model for timely release even when it does not always entirely match customer specifications.  Whereas, there is only one main release in the waterfall method and any problems or delays mean highly dissatisfied customers.
  4. Agile methods allow for specification changes as per end-user’s requirements, spelling customer satisfaction.  As already mentioned, this is not possible when the waterfall method is employed, since any changes to be made means the project has to be started all over again.
  5. However, both methods do allow for a sort of departmentalization e.g. in waterfall departmentalization is done at each stage.  As for Agile, each coding module can be delegated to separate groups.  This allows for several parts of the project to be done at the same time, though departmentalization is more effectively used in Agile methodologies.

 In conclusion, though on the plus side, waterfall’s defined stages allow for thorough planning, especially for logical design, implementation and deployment, Agile methodology is a sound choice for software development and web design projects.  More and more firms are becoming Agile!