My Rant: Introducing New Technology in Agile
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
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.
The second point Ranjan points out about Agile is that:
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.
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.
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.