11 
240 
As you probably know already, I consider "new" methods like SCRUM a YAM, a Yet-Another-Method. And there are a lot of YAM's. Like potatoes they are root-vegs and you can find them everywhere in any vegetable shop. Very versatile and you can bbq, bake, smoke, boil, fry, grill or even eat them raw with the right recipes. Some have other bumps and dents but at the end of the day, they all taste more or less alike.
Well, coming back to earth, you know that a YAM, the Yet-Another-Method and not the vegetable, in the Application Development context is a box stuffed with techniques and tools of which probably most of the time more than 80% are "borrowed" from earlier emerged YAM's. Perhaps with another footprint or selection, other tools, given other names and acronyms, put in another context or changed just slightly enough to make them (false) distinct. There is a complete industry around YAM's and tools (YAT's ???) and many vendors make a living of it. I have nothing against that, it drives professional innovation but it make the life of the humble IT-professional a bit awkward.
SCRUM in my view is just another representation of other agile YAM's like IAD, DSDM, Lean Development, XP, RAD, Essential UP, SMART, DevOps and I am sure I missed a few dozen others. Sometimes it's even a bit embarrassing to see people so excited about "new" methods like SCRUM or DevOps. I can only hope that the "SCRUM-Masters" have enough knowledge and experience to learn from the past and look over the SCRUM-fence, But to give all the original YAM-inventors some credit, every YAM is usually based on some very good and new ideas to improve our profession indeed. Sometimes a YAM is just connected to a tool of the same vendor to create a complete (lock-in) package. But obviously, in an attempt to deliver a full size and complete new method, the "borrowing" from others is unavoidable.
Yes, agile projects have sprints, iterations, time-boxes or what ever you call them. A short period of time with a working and implemented piece of software at the end with real business value. And yes, that forces to use other workflows, techniques and sometimes tools than we are used to in a waterfall environment. But no, actually there shouldn't be anything against using good "agile techniques" like workshops, standup meetings, backlogs and the like in any kind of project. And to be honest, they have been used in all sorts of linear projects for decades. Conversely, still looking at any agile method like SCRUM as a YAM, lots of the (intermediate) deliverables in agile are quite similar to those in linear ones. Maybe a different presentation but it's not another planet. We're still building and implementing IT applications.
So then, what are the real differentiators between agile and a linear projects?