Are we past the period of "Agile vs. Traditional"arguments?
Using Twitter and various industry newsletters, I try to keep up on the state of systems delivery methodologies and techniques (or whatever noun you like to describe these things). For a long time in the first decade of this century, you could hardly go a day without someone weighing in on the "Agile vs. Traditional"topic; in the early days, it got quite emotional and vitriolic at times. The debates and discussions got more civilized over time, and now I see little or no debate.
So, did Agile "win"? Or has it been absorbed into some new overall way of doing things? I still see many articles on Agile, but they seem to be more on how to make it work rather than why you should use it.
Let me propose this "new way" as follows: we need to move our focus from agile systems development to developing agile systems. Thoughts?
3 comments:
David, I think the two discussions are independent from each other. The first focus on strengths and weaknesses of system development methods, the second (if I'm interpreting correctly) on how to create applications that are easier to maintain, change, and evolve.
From my perspective, in the first discussion, "agile vs. traditional", integrative thinking won -- the notion that software development methods should not be looked at as an "either-or" proposition, but rather as an opportunity to build superior models that borrow from agile and traditional approaches as needed to fit the characteristics of each individual project.
The second discussion is even older than the first one, but a much more complex problem to tackle. I see many industry-driven models purporting to have the solution without much evidence to support the claims. For that reason, I agree it's a better topic for discussion and research than the old "agile vs. traditional" topic.
I think we agree for the most part. What I hope we avoid is that the resolution of the first discussion does not blind us to the importance of the second, especially that better methods of creating software does not help if the nature of the software delivered hasn't changed.
What I am mainly referring to is the need to maintain and enhance software almost from the day it is delivered, when it should be able to deal with expected changes such as process improvements and business rule adjustments. Business can't wait for IT to change code, test and install upgrades, that is the real challenge we face now.
Business Process Management and Business Rules Management are the start of addressing this; they are not perfect yet, but getting better --> software that handles change, not software that needs changing.
It is what interests me going forward, anyway. I hope others want join us in the conversation, and in doing it too.
"Business Process Management and Business Rules Management are the start of addressing this; they are not perfect yet, but getting better"
I was going to mention the same examples on my first comment before realizing it was getting too long :-). I agree -- they are far from perfect but getting better, and are good examples of systems that make it possible to make some types of changes (e.g., how the system responds to an event).
I also think that once you start to develop "software that handles change", as you put it, the need to adopt agile approaches will become less and less relevant. Developers won't need to rely as much in "early and frequent user feedback" to produce software fit for purpose, if the business can go ahead and make updates without having to wait for IT to deliver them.
Post a Comment