Agile development and selective implementation of methodologies

Abraham Lincoln said, “If you call a tail a leg, how many legs does a dog have? Four. Because calling it a leg doesn’t make it a leg.”

In the same vein, calling a project team agile does not really make it agile. Lets admit it. The term "agile" is a buzzword that is cool to use. Sometimes (or should it be oftentimes) folks pick up some aspects of a methodology that suits them and then attempt to fit it into their existing process with even worser results than before. And then they wonder why the new methodology isn't working ! The same situation occurs with adoption of agile. In this entry we look at some of the agile principles/practices that are easy to selectively pick and choose.

a) An agile team is capable of releasing the software to customers at the end of each iteration (generally between 2-4 weeks duration). Yes, be able to ship it to the customers, all developed, integrated, tested, wrapped up and mailed. Customers are able to see a working software that has features being available in increments and understand the progress being made. Of course, customers can provide quick feedback to enable any course corrections as needed too. Decisions can be made on whether additional features are to be added, existing functionality to be changed, or even to stop further development without having to wait for the complete release time frame.

When an organization selectively chooses to implement this aspect of agile without following the other aspects of the chosen agile methodology, it can lead to compressed release schedules and require squeezing of activities such as development and testing to get a product out sooner. Merely, compressing schedules will only lead to worser results than before while following non-agile methods.

b) Agile does away with distinct phases of development. With agile, you are no longer required to have distinct phases such as coding followed by testing and so on. This means that developers and testers (along with other required functions) work together in parallel as one team. However, this can be easily misinterpreted as a license to keep coding until the last minute when the release is due. And we can easily realize what happens when development continues coding till the end of the release while following a non-agile development methodology.

c) In the agile context, the software is a moving target. In agile, change is the norm. Developers can add new features or make changes at any time. In traditional methods, testers push for an early code freeze so they have time to test the software that is feature-complete. However in an agile context, this is not usually possible. This can have significant challenges for testing software. At the same time, this freedom can easily be misused by allowing developers to continue making random changes to the software at any time without fully embracing an agile methodology. It isn't too hard to imagine the consequences when we have developers making changes all through the release until the end while the organization follows a mostly non-agile methodology or a mix of agile and non-agile techniques.

d) Agile values working software over comprehensive documentation. This reduced emphasis on documentation in agile is substituted with increased human face-to-face communication and collaboration. For example in Scrum (an agile methodology) there are daily standup meetings where the team (developers, testers, etc.) get a common understanding of where each one on the team is, any obstacles to progress, achievements, etc. Also, techniques such as retrospective meetings, co-location and others foster communication which documents cannot match. It is however, easier to just pick this one aspect as an excuse to do away with documentation entirely or reduce it to an insignificant activity that sits on the back-burner. Needless to say, traditional methodology minus good documentation is a recipe for a poor quality product.

e) An agile software development team can add features in any order. Yes, but it can quickly get out of hand if this is not implemented right. In the context of agile development, features are added in the order that they make the most business sense. That is a significant change from allowing developers to choose features they wish to add. The natural propensity of developers would be to add features they think are best for them or easy or cool to add. This may not be the best order for the customers or business. Given the fact that there is limited time and resources available to deliver a product with a set number of features, it would seem that the best thing to do would be to add those features that have the most relevance to the customer/business within the available time. Focus on adding the important (from customer point of view) features as early as possible leaving the less important features towards the end of the project. That way, if the project were to run out of time or resources, we know that the features that could get dropped from the release are the ones that are of lesser priority.

These are some of the common agile principles that are easy to pick and adopt, albeit incorrectly and inappropriately. As Alexander Pope's poem states, "A little learning is a dang'rous thing; Drink deep, or taste not the Pierian spring: There shallow draughts intoxicate the brain, And drinking largely sobers us again …
Liked this entry? Join my community of professional testers to receive fresh updates by email. Use this link to add your email address to the community. Rest assured, I will neither spam nor share your email address with anyone else. Your email id will remain confidential. Subscriptions are handled by Google's FeedBurner service.