A popular new process for software development is known as Agile. For a technical writer in software documentation, the Agile methodology is useful to know. Agile is a software development life-cycle that was created as an alternative to the Waterfall method. Instead of linear, sequential steps, the Agile process consists of incremental and iterative cycles known as “sprints”. To develop software, people work in small groups through a series of sprints in which design, coding, testing, and customer feedback all occur simultaneously. Requirements and designs are modified as needed which makes the process very flexible and adaptable to change. This is advantageous for the development of useful software. For example, if developers were working on building a website and discovered halfway through that some key functionality wasn’t working for the users, they wouldn’t have to scratch the website and start all over, but rather fix this one issue.
With Waterfall, the process is a lot more rigid with testing and customer feedback happening at the very end of the process rather than throughout. Agile is great for experimental projects as well as cases where a client doesn’t have clear-cut end goals. However, there can also be downsides to the Agile process. For instance, it doesn’t have the clear structure that the Waterfall process has and therefore it can be hard to predict how long an Agile project is going to take to complete as well as how much it is going to cost.
I would improve this by implementing some sort of planning stage beforehand which estimates the number of sprints required to complete a project and sets a maximum budget for additional requirements that might be added during development. If developers know the set budget and number of sprints, they might be able to stick to a more definitive schedule. Also, expectations would be clearer and developers might be less likely to spend time and money on extra functionality for the product if it already meets its basic requirements.