There are lots of resources on agile/scrum. I will simply list some of the main resources for future reference:
- The agile manifesto: http://agilemanifesto.org/
- The main principles: http://agilemanifesto.org/principles.html
- Some "history" can be found here: https://en.wikipedia.org/wiki/Agile_software_development
- The scrum guide (official) can be found here: http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf
Personally, I like the simplicity of the thing (but please bear in mind that agile is not suitable for all development - more on that at the end of this topic). Sometimes the world is changed by people "thinking out of the box". These people (listed here) started in the nineties thinking on alternatives to Waterfall methodologies. Waterfall and other more classic methodologies fit well into mature markets (aerospace, railway and transportation, amongst other), but are not so suited for low level maturity clients, customers that don't know very well what they want (but do not mind paying for the changes they request), product development, research and development as well as other "fast changing" projects.
And as we know that "change is part of life", why not having a way of dealing with it elegantly, or at least with a little "less drama" (scope negotiations, contract negotiations that may do more harm than good to your relationship with the customer)?
Software engineering has been around since the last century, so we might think that everything was perfectly established and defined. We should know everything about doing software right? Right? No: Wrong (just look at the numbers of project failures). So isn't it beautiful that ~40 years after we've been punching bits of code into punch cards, after huge software pieces of noble software having been developed (like any operating system around) some bunch of guys come and "break the rules" like these ones did?
I know the answer and the answer is: YES!
As it has already been said: Agile is not "one size fits all". There are projects that will be better "served" with classic methodologies. So it is a good idea to do a decision analysis (and having a team of people trained on these methodologies) before using it in a company / project (some companies will have a written set of guidelines to help bid / project managers choose the methodology to use). Mainly because it is important to fight the "let's use it because it's new" syndrome, as well as the other one, even worse: "Let's use this because if we do this we don't do things that we don't like" (like writing requirements, doing and thinking on appropriate design, documentation, etc.
Learn a little bit more about Agile/Scrum by following all of the above links as well as these ones:
Learn a little bit more about Agile/Scrum by following all of the above links as well as these ones:
- The "5 line" summary: http://silvaonsoftware.blogspot.com/2016/04/scrum-agile-main-documents-and-5-line.html
- The instructional videos: http://silvaonsoftware.blogspot.com/2016/04/resource-agile-videos.html
(@2016-04-13: link to Scrum Official Guide; small rewording; @2016-04-28: final links)
