Agile: good, bad and ugly (random thoughts)
My very first encounter with Agile-methodology can be traced back to 1999. Like many others before and after me, I was left with a peculiar, not exactly pleasant aftertaste. Furthermore, this subjective impression pretty much proved to reflect objective reality with its many hidden traps.
At that time the relatively tranquil life of our close-knit outsourcing team was disturbed by a delegation from a metallurgical plant. The messengers wanted us to develop specific software, since their in-house solution had almost given up the ghost. When faced with real production volumes, the program buzzed, glitched, went bananas and croaked, which finally pushed the plant management to the realization that their tasks needed a more adequate solution.
The technical section of the delegation was headed by the author of the above-mentioned application, a man with position of a charge mixer in his employment history. I never really understood the path or the driving force that turned a charge mixer into a software developer, unless you count the fact that the system code has a distinctive smell of furnace among other smells. :)
The charge mixer was accompanied by a clean-shaven young man clad in an expensive suit. He was undoubtedly well-read, and flavored his speech with such professionalisms as «eXtreme programming», «pair programming», «unit-test», etc. I must say, we all were very much impressed.
The feeling of awe lasted for about a week until he dragged a massive folio bearing a proud title of «Technical requirements» into our office. The volume was packed with pretty much everything on working procedures and metrics, and held virtually nothing concerning use cases, requirements and other necessary details of technical requirements as such.
- What the..? – we wondered.
- Well, after all, it IS Extreme Programming! – said the expensively suited young man.
Since the folio expected us to name our methods S45K312UP(AB12 a1, AZ13 a2) and the like (I am not kidding!), suggested the payment we receive depends on the number of code lines, and, last but not the least, did not explain what we actually were supposed to develop – there was no happily ever after for our cooperation with the metallurgical plant. Having compared the number of hidden traps to the payment offered we parted company with the burdening machine operator and his friend in a good suit. The whole situation left many of us with a mixed feeling of disappointment and disgust towards all Agile technologies taken together.
However, a couple of months later, when debugging legacy code in another system we were amazed to discover that pair programming can actually be of assistance. To be honest, not only of assistance but rather of paramount importance. No, we did not adopt pair programming as the leading method for 100% of our projects, but started using this technology for development and debugging of bottlenecks and other tricky code sections. Later, other Agile technologies also struck roots in our development practice.
Today Agile has become a buzzword, and situations similar to the one I’ve just described are gaining more and more omnipresence. However, in most of these situations the problem stems from one and the same thing. We all know that «There’s no such thing as a silver bullet», any tool is just a tool with its own limitations and requirements: budget and qualification requirements, workflow and even hardware specifications. Sadly, these limitations are often forgotten when a bonus or another kind of manager’s carrot is looming up. This is when the Agile turns ugly.
Certainly, potential mistakes of Agile implementation have been extensively discussed by incomparably more competent and experienced authors. What I have in mind, though, is examining the question of what we need Agile technologies for, what purposes they serve, what limitations they have – and then try to outline some of the traps awaiting someone who is not aware of these purposes and limitations. I also hope that this overview will help to understand where Agile is necessary, and where it is not only not needed, but even harmful. The overview does not claim to be exhaustive – it will just give examples of the bad and ugly situations I have had the honor of observing or even feeling on my own back.
Hopefully, it will come in handy.
At that time the relatively tranquil life of our close-knit outsourcing team was disturbed by a delegation from a metallurgical plant. The messengers wanted us to develop specific software, since their in-house solution had almost given up the ghost. When faced with real production volumes, the program buzzed, glitched, went bananas and croaked, which finally pushed the plant management to the realization that their tasks needed a more adequate solution.
The technical section of the delegation was headed by the author of the above-mentioned application, a man with position of a charge mixer in his employment history. I never really understood the path or the driving force that turned a charge mixer into a software developer, unless you count the fact that the system code has a distinctive smell of furnace among other smells. :)
The charge mixer was accompanied by a clean-shaven young man clad in an expensive suit. He was undoubtedly well-read, and flavored his speech with such professionalisms as «eXtreme programming», «pair programming», «unit-test», etc. I must say, we all were very much impressed.
The feeling of awe lasted for about a week until he dragged a massive folio bearing a proud title of «Technical requirements» into our office. The volume was packed with pretty much everything on working procedures and metrics, and held virtually nothing concerning use cases, requirements and other necessary details of technical requirements as such.
- What the..? – we wondered.
- Well, after all, it IS Extreme Programming! – said the expensively suited young man.
Since the folio expected us to name our methods S45K312UP(AB12 a1, AZ13 a2) and the like (I am not kidding!), suggested the payment we receive depends on the number of code lines, and, last but not the least, did not explain what we actually were supposed to develop – there was no happily ever after for our cooperation with the metallurgical plant. Having compared the number of hidden traps to the payment offered we parted company with the burdening machine operator and his friend in a good suit. The whole situation left many of us with a mixed feeling of disappointment and disgust towards all Agile technologies taken together.
However, a couple of months later, when debugging legacy code in another system we were amazed to discover that pair programming can actually be of assistance. To be honest, not only of assistance but rather of paramount importance. No, we did not adopt pair programming as the leading method for 100% of our projects, but started using this technology for development and debugging of bottlenecks and other tricky code sections. Later, other Agile technologies also struck roots in our development practice.
Today Agile has become a buzzword, and situations similar to the one I’ve just described are gaining more and more omnipresence. However, in most of these situations the problem stems from one and the same thing. We all know that «There’s no such thing as a silver bullet», any tool is just a tool with its own limitations and requirements: budget and qualification requirements, workflow and even hardware specifications. Sadly, these limitations are often forgotten when a bonus or another kind of manager’s carrot is looming up. This is when the Agile turns ugly.
Certainly, potential mistakes of Agile implementation have been extensively discussed by incomparably more competent and experienced authors. What I have in mind, though, is examining the question of what we need Agile technologies for, what purposes they serve, what limitations they have – and then try to outline some of the traps awaiting someone who is not aware of these purposes and limitations. I also hope that this overview will help to understand where Agile is necessary, and where it is not only not needed, but even harmful. The overview does not claim to be exhaustive – it will just give examples of the bad and ugly situations I have had the honor of observing or even feeling on my own back.
Hopefully, it will come in handy.
Comments
Post a Comment