How is agile different from the way in-house developers have always worked?

Question

in-house in this context means developers working in a company department, where software is used only by that company (defined due to subtleties in translation)

I've been confused by this for a while; Agile advocates tend to claim it's a new approach to dealing with development.

I've reviewed the manifesto, and can't see anything in there that many in-house developers (as opposed to a software-publisher) weren't doing well before 2001.

I'd appreciate it if people could indicate when their career started in their answers - this provides a good indication of whether or not they're talking from industry experience, or trusting 3rd party sources.

NOTE This may be unintentionally confrontational; I am genuinely here to be convinced. I must be missing something for there to be so many books and speakers on the subject.

Based on responses so far, I'm learning that my experiences are somewhat atypical, quite possibly due to my primary sector (financial markets).

Answer 1

Agile Manifesto, and methods which are build over it, weren't meant to invent new techniques, approaches or values. If someone treat Agile Manifesto and agile movement as whole like that I dare say they misinterpret agile.

I can hardly think about any single practice which wasn't used earlier, before it became a part of one of agile methods. From this perspective you're right that it probably isn't that different to what some teams, or in-house developers if you prefer, used as their method of choice.

However, the trick here is the definition of "some." I believe way more teams, those working on in-house solutions included, hadn't been following principles which were later reflected by Agile Manifesto (or other, similar and reasonable set of principles for that matter).

So while in specific case the answer might be "there wasn't much difference" in general case difference was significant, and it doesn't really matter what kind of solution a team was working on. What agile movement changed is it made specific attitude become mainstream, which is a kind of mixed blessing by the way but that's a different story.

PS. My career started in 2000 and included both working on in-house solutions and commercial projects of different type (off-the-shelf, fully customized, etc.)

Answer 2

Phil, you're right, it's a new, old approach.

I've been in the industry 25 years now. Although that doesn't make my responses any more valid than anybody else's.

I think there were some mitigating factors in the past that led to the popularity of plan-driven (waterfall) processes. Software used to be built from the bottom-up with little if any reuse, systems were expected to have a large lifespan, compilers were so much slower than they are now and there was the popular notion that software engineering should learn from the construction industry (good idea, wrong industry).

Today we see that empirical approaches to software development are more successful and yes of course, they have been around for a very long time as has the plan driven approach.

Those who crafted the Agile Manifesto are to be commended on their courage in challenging the status quo and giving a brand name and some momentum to this new/old way of building products.

Answer 3

When 10 years ago I started working as a developer in a small company we didn't know what agile was but we were already using some of what will have became agile techniques, but not very many and not very consciously.

What is important to me is to have a clear and reliable approach, so the point is not if it's new or old, but the fact that it is complete, documented and reliable.

It is also about which tools works better together to cover with the maximum efficiency the process.

Then, taking SCRUM e.g. I'm not sure many companies were using burndown charts before study about it.

Answer 4

Well, Agile Manifesto is a strange thing a bit like an iceberg. Seeing it is one thing, but the understanding and imagination of what remains unseen is another.

I started coding in 90's. It was pascal I think. First time I got payed for coding in 2000 or 20001. Industry experience since 2003 or 2004.

Maybe, back then, it happened to be agile somewhere (but named differently). In my world, developers weren't so educated about project management and coding rules were foggy and unclear as well. Everything was slowly evolving and experience was gathered here and there. Agile Manifesto looked like this:

Individuals and interactions over processes and tools

Of course there was not so much knowledge about processes and not so much tools. In-home developers worked - back then and now as well - in small teams of friends where project management isn't so easy to implement and tools are usually too expensive. So it leaves you with individuals and interactions alone.

Working software over comprehensive documentation

I really do not know even single one developer who would like to work on documentation. Really. In-home developers do documentation only when sponsor asks them to do so. Quality of such documentation is the other thing as well as "working software" term. Today we know many indicators of quality and customer satisfaction and collaboration so "working software" means whole different thing than years before. TDD, user stories, code coverage is relatively new and even now I wouldn't bet in-home developers do all of that.

Customer collaboration over contract negotiation

Responding to change over following a plan

Few years ago it was almost impossible to sign an agreement where sponsor would not get: clearly described what product he will get, when it will be ready, how much will it cost and what milestones you should achieve to get paid at all. Collaboration meant that customer will change the requirements in the middle of the project (sponsor would name it being more descriptive) without changing the contract or a milestone plan.

I am not making it up. It was common mindset among the customers. It took years to change it but don't ask me who did it.

Only now I can imagine signing a contract where there will be rather description of some iterative developement process with two-side involvement than a nice looking, strict plan that nobody understand in the same way.