We are excited as the whole iFountain software development team that we are delivering new products and/or upgrades to the existing ones at an increasing pace. Our agile software development methodology is really starting to make a big difference as we get more comfortable with it.
We will occasionally share with you our passion and excitement with the process that is enabling us to deliver high quality products.
Here at iFountain, we have embraced eXtreme Programming as our core software development methodology but still doing a lot of reading and experimentation with other agile methodologies. We sometimes make minor customizations to the methodology and keep it very dynamic which helps us to increase the buy-in among the team members. We make the process our own and fully commit ourselves to following it.
I will not get into the specifics of why we thought eXtreme Programming is the right methodology for us although this might be an interesting topic for some other time. This article is not for or against any methodology either. There is enormous amount of information on this subject many of which have been produced by people a lot more qualified than myself. However, I cannot be impartial since I do not believe all methodologies are created equal.
What I want to do is to share my own views on how to make sure that a software team follows the methodology picked.
First of all, I assume that every team member understands the benefit of following a methodology even though they may not agree on what to follow and to what extent. Although some environments allow individual developers to diverge from the process a little bit without impacting the coherence of the process selected, team has to be in agreement regarding the general principles of the methodology.
Even with this initial agreement, an agreed-upon methodology will soon be the target of criticism/attacks as the initial excitement and hope wears out. Without regular care and maintenance, it will soon take its place among the discarded projects which "did not work".
I see 2 major risks endangering the livelihood of a methodology which are opposite in direction but equally deadly: Too much change and no change.
Any methodology should be given enough chance to prove that it is not a collection of randomly selected items but a coherent whole where each principle supports the others. I have witnessed many times, teams attacking and tearing apart the methodology until it becomes totally incapable of functioning as a software development process. Being too eager to customize something that is not yet fully understood is very unlikely to yield anything useful. Somehow, many software development teams are quick to believe that they are very unique and no established methodology can possibly address their software development needs. Hence, the strong urge to fix something that can actually do wonders if applied correctly. Finally, everybody realizes that the methodology does more harm than good and it is abandoned.
The other extreme is holding the methodology sacred. This usually manifests itself in the form of draconian enforcement of the methodology by the management despite objections from the team. When something is treated as sacred text, understanding the significance of each principle and their relationships is forbidden or at least not encouraged. This approach lets many valid concerns, feedback go unnoticed or completely ignored and makes the management and the development team adversaries of an unnecessary dispute. Evolution is the foundation of life and a methodology should be given the chance to adapt to its environment if it is to prosper. Without this vital renewal, each minor inefficiency spreads like a decease. Dissent grows and the team alienation dooms the process. Sabotage of the methodology, intentional or subconsciously, becomes widespread. Finally, ... you guessed it, even the management realizes that the methodology does more harm than good and it is abandoned.
I hope it logically follows from the discussion above that there is a happy medium. At least I believe so and this is what we are trying to accomplish here at iFountain. We are striving to acquire more expertise in the agile methodologies area. We are identifying process problems we are trying to solve and studying how components of a methodology are addressing these problems either by themselves or in coordination with other components of the methodology.
Not surprisingly, this leads us to make some modifications, hopefully in line with the spirit of the methodology. We keep asking the following question to ourselves:
Is there a better adaptation of any part of our methodology that will help make the whole methodology more successful.
This is where every team member is asked to provide his/her educated input for evolving the methodology in a more directed way. This inclusive approach helps everybody really feel that this is our own methodology which is invaluable in making sure that we will do our best to follow it.
We will continue share our experimentations with you and tell you what worked and what did not for us. I hope you will find our trials and errors informative and fun to read.
