Over a million developers have joined DZone.

My Rant: Introducing New Technology in Agile

DZone's Guide to

My Rant: Introducing New Technology in Agile

· Agile Zone ·
Free Resource

Download the whitepaper on Product Centric Agile Delivery. Brought to you in partnership with Jile.

I’m not typically a person that takes issue with someone or some else’s post on my blog.  I’m of the opinion that blogs are there to put forth your ideas.  However, I happened across two posts today, one that references the other. One I disagree with and another I agree with and have more to add.  The one I disagree with is not out of spite, but I think it perpetuates some false assertions that, can and do, hinder the progress of something both the author and I strongly hold true.  The articles I reviewed were Introducing New Technology in Agile by Paritosh Ranjan and 5 Reasons NOT to choose a Technology by Ellyssa Kroski.

The first point that caught my eye on Ranjan’s article was the generalizations about Agile.

Generally Agile projects are of very short durations. So, introducing new technologies in such a small time frame is always risky.

I will first start off by saying I can’t qualify what a long duration is.  My assumption is that a short duration is less than a year.  I would argue that Agile is exactly the methodology for introducing a new technology.  Agile, in principle, is setup to manage just that, risk. 

The second point Ranjan points out about Agile is that:

In Agile, the team size is pretty small, so if only one person keeps working on the new technology, then the team becomes dependent on him. While pair programming the knowledge about the new technology also distributes in the team and the team has a balanced truck number.

I don't mean to be awkward here but we are talking about two birds of the same flock.

And then there is this:

Most popular open source solutions are extremely well documented and a variety of free and commercial technical support options are available. Due to the nature of community development, documentation and instructions are often written from a variety of viewpoints - creating well-rounded information, instruction and tutorials. In addition, open source projects can't hide usage techniques, due to the free availability of the code. Free technical support is often available in the form of mailing list or newsgroup discussions; nevertheless some background research, knowledge or experience is often required.

Look, I’m a huge fan of FOSS.  And make no mistake I’m a huge M$ fanboy (Another rant for sure BTW).  However, Ranjan’s uses this reasoning to start the argument.

I really like Ellyssa Kroski post.  I wish more people thought like this.  What I would add to the post is defiantly check the availability of talent.  Regional specialties is a real concern.  For example I live in the Dallas – Ft. Worth area.  You will find more Microsoft professionals in Dallas than Ft. Worth.  In Ft. Worth you will find more java folks or specialty IT (Ft Worth is has more manufacturing and Dallas has more ‘corporate headquarters’).  A theory I’m still working on btw.  I would love to see someone produce a demand heat map by city.

Download the whitepaper on Five dimensions of Scaling Agile in Large Enterprises. Brought to you in partnership with Jile.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}