Often when talking to clients about their requirements, they want to know how much it will cost and also how long will it take. These are very valid questions especially if you are on a budget and a deadline and want to get a minimum viable product (MVP) up and running. However sometimes these are very hard to know or even guess at any stage of a project. How does one let the customer know how much it's going to cost and how long it will take? Enter the Agile Methodology.

Most software development teams use the Agile methodology or some variant of it in their development cycle, but what actually is it? To put it simply, the Agile methodology is a type of project management process, mainly used for software development delivery, where work and associated solutions are developed through the collaborative effort between the "self-organising" teams (e.g. developers) and cross-functional teams and their customers (e.g. Business stakeholders).

In 2001, the Agile Manifesto was developed as an approach to solve the challenges with software development. They wrote four major principles for developing better software:

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

Well what does this mean? In an over simplified explanation, the Agile methodology understands that software is complex and it is very difficult to know everything upfront before development begins. The Agile methodology encourages collaboration between the development team and system stakeholders to identify and agree upon scope for each deliverable. It also allows the solution to "adapt" and "change" as the business changes or an external influence occurs (e.g. government legislation). It follows a multiple cycles of planning, building and testing for each product feature. Feedback at the end of a cycle is then fed into the next cycle. This approach engages the end-user/stakeholders/clients in all phases of a development cycle which helps reduce ambiguity with requirements and manage a user's expectations.

The Waterfall Approach

Traditional software development uses the waterfall methodology. With this approach, all of the system's requirements were documented upfront and then handed to the development team whom would build a solution based on the documented requirements. Waterfall approach relies on teams following a sequence of stages to be completed for the delivery of a solution. For large systems, the requirements phase of the system could take months to complete and in that time, the business may have evolved, causing some of the requirements to be obsolete even before it was built. With this approach, each phase cannot be started until the previous stage has been completed.

Disadvantages of the waterfall model

• Making changes is difficult: Once software is in the "Test" stage, it is very difficult to go back and change something.
• Build stage is late: The "Build" stage is quite late in the process and there may be some technical challenges discovered that were not known at the beginning of the project
• Excludes client/end user input: The requirements phase is the only stage where the client/end user is engaged to identify their requirements. 

LET'S BECOME AGILE

Although the waterfall methodology is still valid for some software, we use Agile and variants of it (such is SCRUM) to deliver high quality solutions not only for software but for other pieces of work. The Agile approach is a great way to develop a solution quickly and without a lot of investment because time is optimised and deliverables are defined by the client. 

We use the variant of Agile called SCRUM. The topic of SCRUM is quite involved and requires another article about it, however, the main benefit of SCRUM is that its is a more formalised methodology specific to software development that the development team and stakeholders adhere to.

At a very high level, when allocating work using SCRUM the following process occurs before each sprint:

• Work is broken down into a list of backlog items called user stories
• User stories are then story pointed (Giving a metric to indicate effort to complete. Often a Fibonacci number )
• Work in the backlog is prioritised by the end-user/stakeholder/client
• Work is time-boxed into 2 weeks of development (These are referred to as sprints). 
• The end-user/stakeholder/client sets the work scope for that sprint
• Work completed during a sprint is verified at the end by the end-user/stakeholder/client
• Backlog grooming occurs, and backlog items are revisited to determine priority and applicability

As each sprint progresses it is more clear how long it will take to complete all of the features of the product and how much it will cost. For us, this is a great approach to building a solution because its transparent and it doesn't allow for any misinterpretation of functionality.

We have been developing software for clients for a long time and Agile and SCRUM are excellent approaches to delivering a product. If your organisation isn't using it at the moment, we can help you set it up. Once it is in place, it is a great way to develop products.