To start with, I would like to acknowledge that there are several views and interpretations of what Agile as a thought, methodology, process, model and framework for software development or maintenance is. To pick one and/or comment on what is the correct view is not the intent of this discussion. The underlying principles that represent Agile, in my words –
- Seamless, in-the-face and short-cycle communication across all stakeholders to ensure faster decision-making and homogeneous understanding of all project and product aspects
- Rapid and iterative approach to software solution building that facilitates a ‘completed product view’ despite being in-process so everyone sees it in the same light and are able to contribute tangible value-added changes instead of a virtual and imaginary idea that takes shape much later
- People-centric rather than process-centric action allowing great deal of flexibility to focus on the what, when, where and which rather than the hows and whys
Extreme programming or XP advocates a similar line of thinking vis-à-vis the methodology adopted in Agile though it has the added ‘no-frills’ approach to core programming on how functionality is coded and features kept to the bare minimum et al.
So now that we have set the ground on what we are discussing about, let us turn our focus to the question I posed to start with. So what’s new about Agile or XP?
I have vivid memories, from more than a couple of decades back, of groups comprising some pretty tech-savvy business users and power users sitting alongside a bunch of programmers and programmer analysts (I must admit whatever that role or title means has always intrigued me!) who understood a bit of the business, a lot of the functionality, had limited analysis or design exposure but were solid to awesome programmers sitting together and doling out mid-sized enhancements to large applications and building small applications by huddling together for a few hours, days and weeks. And the folks that I considered granddads of the trade then had told me the same tales from a decade further back, which sounded pretty similar!
A lot of us have had experiences of sitting together with a business user or power user and building apps from scratch without writing the BRDs, SSDs, URSs, HLDs, LLDs, ABCs, PQRs and XYZs! Many of these apps are still in use, are robust and have since been modified a zillion times over by future generations beyond recognition. So what’s all the fuss about? That was, essentially, as Agile and XP as anyone would care.
It is amusing to see the Sprints and the Scrums and the Scrum Masters, extreme programmers and the whole tribe and its rituals. And the fact that there is a solid commercial value attached to the jamboree not just on doing software development and maintenance in this manner but also on learning how to do so (there are certifications galore to prove the point and your worth, if you care)!
In summary, there is no novelty in Agile or XP. There is merit in choosing to go that path when the situation demands increased velocity and when the torque factor on requirements is a lot more than usual. And it’s been done for donkey’s years. There are multiple ways in which a software development or maintenance project could be carried out. There are multiple methodologies and models to choose from, all with their inherent advantages and disadvantages. The folks on the ground are the best judges of what is required in a given situation and for them to choose one model over another, the least we can do is to keep it simple to understand and demystify the myth rather than creating more of them!
You may also find some interesting perspectives on this and related themes in
Note: The views expressed here and in any of my posts are my personal views and not to be construed as being shared by any organization or group that I am or have been associated with presently or in the past.
I agree with Murali's view point. We have been doing this since ages but its only recently that we have seen the SCRUMS/SCRUM Masters and others glorifying terms coming in to play. Maybe it is a way to formalize an otherwise unstructured way (probably a decade ago the older way of doing Agile came in to picture more often than not in crises situations which impacted schedule and cost). It is also possible for some parts of the fraternity to create a hype about all this and capitalize on the hype. Now that the larger fraternity has accepted AGILE, having a formal structure is any day better than not having one but what has other wise changed continues to be though provoking.
ReplyDelete