Print

From the Editors: Agile is dead... as a term



Email
March 15, 2011 —  (Page 1 of 2)
Enough with “agile” already! It’s been 10 years since the Agile Manifesto, and the conclusion is inescapable: Agile methodologies are a key part of the foundational software development universe. As the Artful Dodger sings in “Oliver!”

Consider yourself at home, consider yourself one of the family. We've taken to you so strong, it's clear we're going to get along.

After a decade, we at SD Times are going to try hard to stop distinguishing between agile software development and non-agile software development. While we might talk about specific methodologies from time to time; Scrum, let’s say, or XP, or Test-Driven Development, or the oft-derided Waterfall—it’s all software development now.

That’s how things work in our industry. New concepts come in, are explored and adopted, and then become part of the furniture. Remember back when most developers worked with structured programming in languages like C, Fortran, Pascal, COBOL and PL/I? In our conversations and writing, many of us differentiated that new-fangled object-oriented programming and design stuff for years... And then, after a while, OOP languages and methodologies became standard. That’s not to say that all development is OOP—there’s still plenty of C going on—but for all intents and purposes, we don’t need to call it out for special mention.

We believe that the broad acceptance of agile software development, and its validation broadly throughout our industry, says that agile is mainstream. That’s not to say that we’re not going to use the “A-word” ever again, but rather we’re going to change how we talk about it. Our intent is to stop treating agile development as something new, unusual, niche or experimental. Will a decade’s worth of habits be hard to break? Certainly. But that’s where we’re going—along with the rest of the industry.

With Hudson and Jenkins, forks are good
One of the strengths of the open-source software model is that (licenses permitting) if one party doesn’t like how a project is going, it can fork the project and take it in another direction. If the fork results in new vibrancy or opens up the project to new users, the fork is good. If the fork, however, merely results in confusion and incompatibility, and divides scarce resources, then the fork is bad.



Related Search Term(s): agile, Hudson, Jenkins

Pages 1 2 


Share this link: http://sdt.bz/35356
 


Comments


03/19/2011 04:04:41 PM EST

Interesting. So should we just call it 'software development' from now on without specifying the "Agile" part? That'll be a hard habit to break...

United StatesAgile Scout


03/21/2011 09:31:13 AM EST

Although you do have a point, Software Development *is* Software Development, the truth is that there are HUGE differences between agile and non-agile Software Development. For instance Agile software development projects seem to be correlated with better job satisfaction (study to be published in Finland some time next year), and the people who experiment with Agile Software Development don't usually want to go back to non-agile software development (internal study, cannot share unfortunately). I would say that you are wrong in stopping the differentiation and would encourage you to review your decision. I've written a post and given presentations about this topic that you can find here: http://bit.ly/goojat

FinlandVasco Duarte


close
NEXT ARTICLE
IIST: Knowledge of testing essential for successful agile development
Organization provides agile testing certification in order to ensure software testing roles in agile Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
APRIL 2014 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?