Agile methodology is a team development style that offers quick turnaround and committed goals. Many teams use different variations of Agile that work for them.This isn't a silver bullet to getting your projects done quicker, but it's a step in the right direction. The thing that large companies don't really understand is what they "need". Over the years, I've heard management slam the gavel saying that they NEED a research document. And that they NEED the release notes printed. As a developer, I fail to understand why all this is more important that you NEEDing to get the project done. Agile is a way to "cut the fat" from the old mindset. It's a blueprint to take developers and letting them be productive. In Agile there isn't a manager, there is a "Scrum Master". While it's a funny term, that role is the most important job. It basically shields the developers from the "riff-raff". The "Scrum Master" every day meets with the team and asks what their impediments are. His job is to keep the developers coding and removing road-blocks. I've worked in both environments, a startup and a company. I did the startup on nights and weekends, while trying to balance family and my full-time job. The company I work for (for 13 years) is faster than most, but it's still large and slow to get things accomplished. We are separated into about 6 teams with anywhere from 2-10 people on a team. Over the last 5 years we've moved into an Agile development methodology. Some teams have rebelled and still do "waterfall". Between the 2 methodologies, it's easy to see the vast difference in productivity. "Waterfall" is a development methodology where you have a developer estimate the size of a change. Then they do a research document to write up what changes they would have made. Whenever that gets approved, a developer is assigned to it, and can start working. But wait! The developer that researched it might not be the one who is doing the development (or the research was done months ago and you forgot what to do) so the developer needs to read the research document and program it. If your company does this still internally, then your leadership is from the 1990's, and they shouldn't be driving technology. If you're a manager reading this, and require your developers do this, then please do us all a favor and go put in your 2 weeks.. In my opinion, research documents should only be written when doing work across companies. Agile is the most effective development methodology I've used to date. Although we don't use it exactly how "they say to", we've customized it to fit our teams mindset and be even quicker. For example, we don't do the retro. We sit in a open room and are very vocal about how the sprint is going day-to-day. So sitting down at the end of the sprint and hashing it out again would be pointless for us. We also don't estimate in "story points". We use hours for all our sprints, tasks and velocity. It's just easier for us, because we found ourselves always doing a calculation back to hours anyway. If you haven't tried Agile yet, I highly recommend you do! Here are some great resources to help you get started. http://agilemethodology.org/ www.google.com :)