1. The traditional method
This involves analysing the requirements, defining a product on the basis of a comprehensive set of specifications, formulating the product, developing it and testing it. A project may thus take several months to several years. The project manager has to set the key milestones for each stage. The study and analysis stages remain completely theoretical until the developers encounter problems that no one could have foreseen. The time taken up by the development stage of a project is therefore particularly unpredictable and often exceeds the duration and/or budget originally allowed for it.
2. Agile methods
These methods began to be developed in the United States, in 2001, with the dawning realisation of the increasing number of project development failures. So, a team of experts met and drew up a strategy setting out the approach that should be adopted to adapt the most readily to change and thus to respond best to clients’ expectations.
The principle on which these methods are based is to divide the project up into several iterations, which cover the functions that come together to make up the final product. There are several advantages to working on a number of mini projects rather than one large project:
• Developers no longer feel as if they are not making progress
• The clients are regularly involved in the test stage of each function and give their input as required.
• A “virtuous circle” is established.
The Scrum approach
Scrum is the most popular of the Agile methods. It involves defining all of the functions of the application in a backlog. The development team meets every 2 or 4 weeks to establish the functions it will implement during the coming 2 or 4 weeks. The cycle is repeated until the backlog tasks have been completed. These iterations are known as “sprints”. Once a sprint has been completed, there is a debrief and then the work begins again on a new set of functions.
I find this method worthwhile, if you cut out all of the meetings it involves. Here is a list of all the occasions when the team has to meet for discussion:
• Sprint planning: This is when the priorities are established for the upcoming sprint (allow half a day per sprint)
• Daily scrum: This involves a meeting lasting several minutes every morning so that everyone involved can talk about what they did the day before, any difficulties they experienced and what they are going to do today. In theory, it shouldn’t last more than 15 minutes, but all it takes is for one person in the team to have a habit of talking for a bit too long and your morning is already almost over.
• Backlog refinement: This involves estimating the time each task will take. This duration calculation is estimated in terms of points. So, in addition to being completely arbitrary and incomprehensible (1 point = how many hours?), the time spent on calculations in relation to functionality would often have been long enough to cover actually developing it (allow half a day per sprint).
• Sprint review: This is the time set aside for reviewing the sprint that has just been completed. The conclusion: it is often concluded that the number of tasks scheduled was excessive and plans are made for the following sprint to be perfect! (The following sprint in fact goes as poorly as the previous one, and half a day per sprint must furthermore be set aside).
All of these meetings are very time consuming. On average, a team of 4 developers loses “10 man-days” in meetings, every two weeks.
The expression “agile” has become meaningless. In theory, the team ought to be able to adapt immediately to change. Unfortunately, I have attended meetings at which the project manager could not add a small task to the current sprint because this went “against Scrum methodology”.
To conclude, the rapid sprints and iterations proposed by the Scrum method represent genuine progress in the management of projects. On the other hand, the excessive number of meetings and the lack of adaptability diminish the benefits of this method.
In the next episode, I will talk about GitHub!