Agile Methodology: change your work practice

There are many studies and methodologies on how to manage a project. The most widespread practice has been the Waterfall model. It is still a very common practice in the software engineering industry. This model has a big advantage to be easy to understand and implement. It seems like a good idea, especially consideting that, for instance, the implementation can only be done when the requirements and design have been agreed and accepted. What this archaic model does not take into account is the flexibility of software engineering projects, may it be due to new technologies available, bugs identified, new ideas, shifting of priorities, or changing customers' requirements.

Petersen, Wohlin, and Baca (2009) explain that “a survey of 400 waterfall projects has shown that the software being developed is either not deployed or if deployed, it is not used”. This is a dramatic ascertainment, as the objectives are not met if the software is not deployed and/or is unusable. Another issue with this model is the difficulty to improve the code and make changes during the verification/testing phase. Imagine thousands of lines with a testing only at the end, that can create a considerable loss of time and money if something is not right with the code produced.

Simple solution: next time use the Agile methodology. You will work in sprints (preferrably 2 to 4 weeks), and you will be able to review your teamwork very quickly, possibly pivot or persevere after client feedback.

Agile methodology only focuses on results, compared to historical approaches (which emphasize on the production of code). Layton (2012) explains the four values of the Agile Manifesto:

• Value 1: Individuals and interactions over processes and tools 
• Value 2: Working software over comprehensive documentation 
• Value 3: Customer collaboration over contract negotiation 
• Value 4: Responding to change over following a plan

Try it, you’ll love it ;-)