> Agile is at is core just some suggestions for teams to work well together I don't think that's right. Agile is a way to manage projects as an alternative to

> Agile is at is core just some suggestions for teams to work well together I don't think that's right. Agile is a way to manage projects as an alternative to waterfall. The 'communication' stuff on top of that might work well with it, but that's all to do with how you run your agile process. Agile itself is just about the order you do stuff. Imagine that for your project, there 3 'features' that are needed. Each feature needs, designing, implementing and validating (testing it works). You end up with this grid of all the work that needs doing: F1 F2 F3 Desi Impl Vali In waterfall, you progress through this grid top to bottom. You design all the features, then you implement all the features and then you validate all the features. In Agile, you progress through the grid left to right. First you work on feature 1, doing design, implementation and validation, and only then you move on to feature 2, then feature 3. The reasons for doing this are many and varied. The obvious ones being that in waterfall you don't have anything useful until everything is done, whereas in Agile at least you have F1 fully done a third of the way through. This also means that you can decide that F3 is more important than F2, and then later that F4 which you'd never heard of is needed when F2 isn't (and you can decide this as you go along). This bare concept of agile is almost always what you want to do, particularly for software projects. The concepts of backlogs, sprints etc. are all the process that has built up to make this work in real life. Approaches such as Scrum have then built on top of that giving a whole lot of extra practices about how teams should work. A lot of that is variable in usefulness and how well it is used. You don't want to get away from the underlying value of the agile process though.