Hi, I keep hearing and reading a lot about Agile and Scrum development methodologies, but I have no idea of what they can be, or their use, what kind of projects are suited to this method ?
Could you point me out to some useful information about it ?
Where to start ?
What are the advantages ?
That's a pretty broad question. Try read some info on the web. This is a pretty good site with lots of information about SCRUM and some links to other sites as well.
extremeprogramming.org is a good overview of Agile.
Note that Scrum is for project management, it is not a development methodology. Scrum is often used in conjunction with Agile.
What does Agile mean to you?
http://communitycast.tv/2008/10/26/what-does-agile-mean-to-you/
The conference is over... but this video was fun to make. :)
The early approach to software project management usually referred to as “waterfall model” implies a sequence of clearly defined steps necessary to complete any project: define, plan, organise, execute and then close.
This represents a very neat, simple and above all convenient abstraction from the project management theorist point of view. When one stage follows another it is possible to define clear inputs and outputs for each stage, isolate and identify techniques and tools that are most useful at every phase. This is a clear example of reductionism in tackling project management complexity: keep splitting the whole into smaller bits until you get to understand each bit in isolation and then hopefully you will master the mechanics of their totality.
But as soon as the waterfall abstraction was presented it started to leak. Firstly it turned out that real-life process can not be clearly cut into stages, often definition is still changed on what it seems to be planning, organisation or even execution stage. So, in theory, the stages were allowed to overlap and theoreticians started drawing all sorts of diagrams there it’s possible to see how the definition stage gradually runs out as execution starts picking up during the organisation stage. Then, again only in theory, it is possible to accurately estimate during the planning stage how long it is going to take to develop a piece of software. Obviously, in actual practise, the estimates and other plans have to be tweaked right through the execution phase which gave birth to a string of complex yet not very meaningful methods as Earned Value Management.
The chronic problems with the waterfall abstraction gave birth to a number of “agile” project management methods (Agile, Scrum, XP Programming etc) that despite many differences at the more detailed level use the same fundamental principles to tackle product development complexity:
The project is organised as a number of small iterations through the classic project stages (definition, planning, organisation, execution and closure).
Each iteration aims at a relatively small yet semantically complete increment in product functionality or non-functional characteristics.
Strong end-user involvement throughout the project.
Since every iteration goes through a separate definition and planning stage the time horizon for various estimation and planning activities is greatly reduced. It helps achieve greater accuracy, hence make it easier to access feasibility, measure value and costs etc.
Small increments help controlling the scope, evaluate utility of the changes and keep users involved since there is always a fresh version of fully functioning product. It is also much easier to organise a number of teams working on a large project simultaneously when increments are kept small, this really helps tackling task dependencies.
The user feedback is key to iterative methods, since it helps the product evolve gradually in a right direction providing greater utility at the end as opposed to the uncertainly of user reaction that is natural to punctuated equilibrium driven by the waterfall “big-bang” approach.
Agile is a collection of practices. While there is no formal definition of the collection of agile practices, there are studies that have measured the effectiveness of various agile practices.
Broadly, the agile practices can be categories into two groups, management practices and engineering practices. SCRUM is the most popular set of management practices. XP or Extreme Programming is the best known set of engineering practices.
If an agile team only employees the management practices, i.e., SCRUM, they are likely to be unable to maintain a sustainable pace for an indefinite period of time. For example, without automated functional tests, it will take longer and longer to validate each iteration. If you don't use pairing or Test Driven Development, you are likely to find your defects grow out of control.
Management practices enable the team to collaboration successfully with the business partner. Prioritizing what need to be done, working collaboratively against scope in priority order. SCRUM, by itself, will provide benefit immediately. Management practices tend to be the easiest to learn and put into practices.
Examples of management practices are open workspace, product owner, prioritized product backlog, iteration, iteration and release planning meetings, show & tell etc.
While the engineering practices are more difficult to learn and execute well, they are essential if a team is to maintain a sustainable pace of high quality software. Examples of engineering practices are developer pairing, test drive development, simple evolutionary design, automated functional and performance tests, continuous integration and collective code ownership.
There is much written about Agile and even more confusion. If you are interested in using agile find a coach that can help your team learn both the management and engineering practices. You will be rewarded with a team that is high functioning and a business partner that is very pleased.
Please ignore the first answer above as religious nonsense. It is a Stalinist style rewriting of history that bothers me greatly ever time I hear it: "In the beginning there was waterfall, but it was bad, and thus there was Agile and Scrum, and lo the programmers rejoiced." It simply didn't happen like that. It happened like this:
a) A long time ago there was Waterfall, Spiral, and some others
b) A less long time ago there was Iterative development, the UP, the RUP, and a whole plethora of other Iterative development approaches that were all the rage and the evangelists were telling everyone how Iterations mitigated risks
c) Companies still used Waterfall anyway, and the tools to do Iterative development, like Rational Rose and etc were too expensive and too hard to grasp
d) All this complexity caused a number of backlashes, like XP, and eventually the Agile manifesto, which basically reads "Processes and tools are complex and difficult and detract from requirements, so we should just talk informally with the customer more"
e) Agile was quickly adopted by every over-rebellious angsty pubescent programmer on the planet, who carried the Agile manifesto in their pockets in the same way that 4th generation Irish emmigrants still carry the IRA manifesto in theirs.
f) Agile attemps to rewrite history by saying "we used to do waterfall until Scrum came along", and with this and the fact that it is a dumbed-down thicko version of Iterative, Incremental developments of yore, it hopes to make more inroads into the corporate Waterfall culture.
Finally, Scrum is nothing - it is a vocabulary at best. It relies on the strength of a single small team. That is all. Ignore it and it might go away.