What does Agile mean in software development?

First of All, Agile Isn’t a Project Management Methodology. Instead, We Need to Think of Agile as a Mindset, Rather Than a Methodology. It’s not a specific group of tools and practices, but instead an attitude that shapes the way a work is approached. The ‘magic’ of Agile is that it develops a way of thinking; it teaches people how to adapt to a dynamically changing environment, whilst also quickly delivering the highest business value. This is far more beneficial than simply providing people with a rigid toolbox of solutions, as any problem will be tackled more efficiently.

Doing Agile doesn’t always equal being Agile. By solely applying Agile practices — such as Iterations, User Stories, Standups and Artifacts — you can’t get the best results. Getting an Agile mindset requires a shift in behaviours, attitudes, and habits. For example, many teams just adopt several aspects of Scrum  — Stand-Up Meetings and bi-weekly Planning Sessions — but don’t actually adopt the Agile way of thinking. They follow some of the practices, without being able to actually say what purpose is served by those practices.

Before Agile, the Waterfall Model was used to manage the majority of software development projects. This model, however, had several drawbacks:

In the Waterfall Method, progress flows downwards, like the namesake suggests. Projects go through sequential stages: Conception > Initiation > Analysis > Design > Construction > Testing > Production > Maintenance.

Because of this, the end product can differ greatly from the initial expectation and design: 

• Once an application is in the testing stage, it’s very difficult to go back and change something not planned-for in the concept stage. 
• No working software is created until late in the project. 
• High amounts of risk and uncertainty. 
• Not suitable for projects susceptible to changing mid-development.

• Once an application is in the testing stage, it’s very difficult to go back and change something not planned-for in the concept stage. 
• No working software is created until late in the project. 
• High amounts of risk and uncertainty. 
• Not suitable for projects susceptible to changing mid-development.

In response to these issues, the Agile Manifesto was introduced in 2001. In Agile, the scope of work is flexible, rather than fixed, and the projects are divided into several chunks with frequent reviews and feedback.

This allows several benefits: 

• It is easier to manage a smaller amount of work at once 
• Project deadlines are met. 
• Regular reviews and feedback lower potential risk. 
• In the end, the customer receives the product that they wanted.

• It is easier to manage a smaller amount of work at once 
• Project deadlines are met. 
• Regular reviews and feedback lower potential risk. 
• In the end, the customer receives the product that they wanted.

What Are Agile Development Methodologies? 

Essentially they’re a set of Methodologies, principles and values applied to an empowered and self-directed team. Through these factors, they are able to provide quality business value, quickly and iteratively.

Contrary to the Waterfall Model, the Agile method is built upon the following Manifesto:

12 principles are drawn from this manifesto. A huge strength of Agile methods are that they balance flexibility with stability, whilst retaining high quality production.

Agile Development Is Built Upon Several Lean Principles:

• The goal is to deliver a product that solves the problem it was designed for, through long-term thinking and bringing value to the project (instead of churning out software). 
• Anything which unnecessarily sacrifices time, effort and resources will be considered waste: paperwork, switching people between tasks, managerial overhead, and waiting for other teams. 
• Software value is measured in fitness for use, and not conformance to requirements. Different ideas will be tried, tested, and given frequent feedback. 
• The faster an end-product is delivered without major issues, the sooner feedback will be received and incorporated into the next iteration. By being quick, customer needs will be fulfilled — not the needs of yesterday. 
• Agile adopts the philosophy of “find good people, and let them do their own job” — this encourages progress, catches errors and removes impediments, without micro-management. 
• Build quality is maintained to a high standard from the very beginning, and not just within the final product. 
• Avoiding detailed discussions of items not currently in development, in order to stop energy being wasted on plans that will only be rebuilt later. 

• The goal is to deliver a product that solves the problem it was designed for, through long-term thinking and bringing value to the project (instead of churning out software). 
• Anything which unnecessarily sacrifices time, effort and resources will be considered waste: paperwork, switching people between tasks, managerial overhead, and waiting for other teams. 
• Software value is measured in fitness for use, and not conformance to requirements. Different ideas will be tried, tested, and given frequent feedback. 
• The faster an end-product is delivered without major issues, the sooner feedback will be received and incorporated into the next iteration. By being quick, customer needs will be fulfilled — not the needs of yesterday. 
• Agile adopts the philosophy of “find good people, and let them do their own job” — this encourages progress, catches errors and removes impediments, without micro-management. 
• Build quality is maintained to a high standard from the very beginning, and not just within the final product. 
• Avoiding detailed discussions of items not currently in development, in order to stop energy being wasted on plans that will only be rebuilt later. 

• The team will not operate up a hierarchy — instead, it will operate horizontally, with a focus on the customer. 
• The approach is one of enabling self-organization, and not a controlling set of rules. 
• Plans are iterative and continuously in flux, rather than static and concrete. 
• The workplace is an interesting and inspiring area, channelled via people who are given autonomy. 
• The customer is central, and not absent; the aim of the team is to satisfy the customer’s business needs. 

• The team will not operate up a hierarchy — instead, it will operate horizontally, with a focus on the customer. 
• The approach is one of enabling self-organization, and not a controlling set of rules. 
• Plans are iterative and continuously in flux, rather than static and concrete. 
• The workplace is an interesting and inspiring area, channelled via people who are given autonomy. 
• The customer is central, and not absent; the aim of the team is to satisfy the customer’s business needs. 

Agile Development is actually an umbrella term that encompasses several variations. Scrum is one of these, along with XP, Crystal, FDD, DSDM, etc. It’s useful to think of these as different variations of Agile Development.

Scrum is one of the most popular ways that Agile is integrated into a team; so much that many people think they are one inseparable thing. It’s incredibly important to analyze your business value stream, and to pinpoint the specifics of the product/business goals before choosing a Development Methodology to follow. If you are unsure or have doubts, feel free to contact us and we’ll help you to choose the best option for your specific needs.

The easiest way to identify Scrum, is how it composes a team. There are three key roles: Product Owner, Scrum Master, and the Development Team.

• The Product Owner lays out the requirements for the project, and is responsible for the correct product being created. They know what is needed for potential users and stakeholders, and when it is needed. 
• The Scrum Masters aim to make the workflow as efficient as possible, by removing impediments, overseeing and continuously improving the development process. 
• The cross functional and self-motivated Development Team are there to provide technical solutions to business problems, whilst ensuring reliability, scalability, monitoring, and alerting the Product Owners/Scrum Masters of any issues. 

• The Product Owner lays out the requirements for the project, and is responsible for the correct product being created. They know what is needed for potential users and stakeholders, and when it is needed. 
• The Scrum Masters aim to make the workflow as efficient as possible, by removing impediments, overseeing and continuously improving the development process. 
• The cross functional and self-motivated Development Team are there to provide technical solutions to business problems, whilst ensuring reliability, scalability, monitoring, and alerting the Product Owners/Scrum Masters of any issues. 

All three roles combine their responsibilities to create a functionally appropriate, on-time, and competent product. A good Scrum team contains an array of skills, and members cross-train each other so that no person bottlenecks progress. They are usually tight-knit, work in the same space, and are composed of 5-7 members. The best Scrum teams approach projects with a ‘we’ basis, and helping each other is a key part of work. 

• First, a Product Owner creates a Product Backlog — a list of prioritised needs/requirements. 
• The team then takes a small chunk from the top of this list, and creates a Sprint Backlog. They then decide how best to carry out these pieces and achieve the Sprint Goal set by the Product Owner, in a process called Sprint Planning. 
• A Sprint often lasts one to four weeks, and this is the amount of time the team is given to carry out their Sprint Backlog. Every day, they meet to assess the progress they have made. 
• The Scrum Master oversees these sprints and facilitates all Meetings, helping the team to keep focus. 
• The product at the end of a Sprint should be potentially shippable. It’s given a Sprint Review, and retrospective. 
• The next part of the list is then turned into a second Sprint backlog and planning, and the next Sprint begins. 

• First, a Product Owner creates a Product Backlog — a list of prioritised needs/requirements. 
• The team then takes a small chunk from the top of this list, and creates a Sprint Backlog. They then decide how best to carry out these pieces and achieve the Sprint Goal set by the Product Owner, in a process called Sprint Planning. 
• A Sprint often lasts one to four weeks, and this is the amount of time the team is given to carry out their Sprint Backlog. Every day, they meet to assess the progress they have made. 
• The Scrum Master oversees these sprints and facilitates all Meetings, helping the team to keep focus. 
• The product at the end of a Sprint should be potentially shippable. It’s given a Sprint Review, and retrospective. 
• The next part of the list is then turned into a second Sprint backlog and planning, and the next Sprint begins. 

This process is efficient at giving a customer constant updates. They are completely aware of how their project is progressing, and receive working Product Increments at the end of each Sprint. It’s now quite obvious why the word ‘Scrum’ was used as a metaphor; the Regular Meetings are the Scrums themselves, the Sprints are the play in between, the referee lays out the requirements for the match, etc.

Overall, the final outcome is predictable, and they ultimately receive the working product they asked for from the start.