Successful projects using agile methods? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

I have been interested in agile methods of late and have found a lot of prescriptions and minute descriptions of a lot of practices. Still, I remember my best projects as run-to-completion spikes followed by some debugging and minimal testing before going live.

I have been asking myself, did Flickr use agile methods? Does Facebook practice TDD? Was Gmail made in 25 minute spans followed by 5 minutes of daydream?

In other words, before I listen further to all the preaching and jump into the manuals, what evidence do I get that thi开发者_JS百科s is the way to be successful in a successful project in a successful company?

Of course, I am asking this because I want to read the answers, not because I want to dismiss an argument.

---

A related question is, how many non-Agile (Waterfall, "Big Design Up Front", etc) projects are successful? In my experience, not many. In fact, I just rolled off a two-phase project in which the first phase was traditional Waterfall and failed pretty significantly, but the second phase was iterative in nature and yielded substantially better results (on time, far fewer defects, end result was closer to client's actual needs than the original spec).

I've been doing Agile development for a few years now and, overall, have found it to be superior to the alternative. A few things I've noticed:

1. Agile != "no process". Agile is about having only as much process as you need and continually refining that process.

2. Agile requires discipline. You not only have to have a process, you have to follow it.

3. Agile won't turn a failing project into a success. It can help you identify that the project is failing sooner rather than later, and help you figure out why it's failing. It's about shortening the feedback loop so that you have a chance to get back on course before it's too late.

Microsoft Research recently posted an article in which they empirically evaluate some Agile methods. It's well worth a read and might provide some of the information you're looking for.

---

Here's a successful project of mine: http://www.sky.com

• Went live after a few months.
• Delivered new functionality to the CMS and servers behind the site weekly - with deployments typically every week or so.
• All done with all the extreme programming disciplines.
• Weekly demos to the customer to go with the weekly iterations.

Here's another agile project (also done strictly with XP), also a big success: http://showbiz.sky.com/

I've also worked on two other successful XP projects:

• Banking A system for cleaning up and distributing fixed income data across investment bank sites in NY, London, Paris and Tokyo. I believe the whole project only had one production incident over the course of a few years.
• Mobile Data A system for configuring mobile phones and PDAs for mobile networks and handset manufacturers. We built the core product incrementally over a number of years and co-ordinated the work over three sites across the world. All done using extreme programming. Customers were some of the largest companies in the mobile business. Our apps provided global support for some of these clients.

I really wouldn't go back to the old way of doing things - and neither would the customers that sponsored the projects I've mentioned above.

---

In most of the big companies (IBM for instance), the methodology is not always the same, Agile or Rational or Waterfall. That depends in a lot of the history of the projects and the experience of the current People and Project Managers.

If you plan to develop on something is always good to check on all the sides before deciding what suits best for your plan.

So the short answer is: It depends.

---

My product (the Sophos Email Appliance) is developed using agile methods. Industrial Extreme Programming, as espoused by Joshua Kerievsky, was used for the first several years of development. Recently I have started to move the team more towards Kanban, visualizing work flow and using pull-based scheduling instead of time-boxed iterations.

---

In other words, before I listen further to all the preaching and jump into the manuals, what evidence do I get that this is the way to be successful in a successful project in a successful company?

There is empirical evidence that most IT projects are not successful (where success means on time, on budget and fully functional here). Given this evidence, it seems reasonable to wonder if a deterministic approach (the waterfall) is well suited for software projects.

"The definition of insanity is doing the same thing over and over and expecting different results." --Albert EinsteinRita Mae Brown¹

If a deterministic process produces failures over and over, we are likely not applying the right process for software development projects and Agile methods are an alternative. The theory behind these methods is that most software projects are not deterministic, they are creative (like in art) and complex (as defined by Ralph Stacey) projects and we can't predict everything. So, instead of trying to predict everything and then fighting against change, we should use an adaptive process. And this is what Agile methods are about.

Now, using an Agile method will never guarantee systematic success (and someone claiming the inverse is a liar) but they'll give you better control over the risks. And, if your project has to fail, it will at least fail fast.

Update: ¹ Actually, this quotation seems to be misattributed to Albert Einstein. The earliest known occurrence, and probable origin, cites to Rita Mae Brown.

---

I believe Doublefine just produced Brutal Legend using Scrum.

---

From what I understand StackOverflow is a successful website built with agile practices and TDD.