Getting to Grips with Agile: Basic Concepts Explained

Agile has become mainstream. Since the moment the term was first coined nearly 2 decades ago, it has steadily replaced the waterfall method for many development teams. By now, agile methods are the most used around the world -more than any other type of methodology. However, as many companies have already experienced, adopting Agile doesn’t automatically equal success.

One of the challenges that comes with adopting Agile is a lack of skills and experience in applying and using Agile methods (13th Annual State of Agile Report –CollabNet/VersionOne). While the number of professionals expected to work in an Agile way is increasing, not all of them receive enough education or training. In order to help people become well-versed in Agile a number of new learning options have appeared, making these challenges easier to overcome.

To give professionals a flying start in the world of Agile, EXIN chose to create a certification program that combines Agile and Scum. It offers professionals a certification that features knowledge about Agile principles and the Scrum framework. The certification program starts off with EXIN Agile Scrum Foundation. This is ideal for professionals who have just started their Agile journey or those who are already working as part of an Agile team.

The certification covers all of the terms, concepts, and knowledge that are important for anyone who wants to starting working in an Agile way. To get you started, we’ve created a glossary below that focuses on the main terms. Naturally, the Agile Scrum Foundation certification goes into these terms, and other important information, in more depth.

What is Agile?

When people first hear about Agile, they sometimes mistakenly think it is a framework or a methodology. It’s also not as simple as saying ‘Agile is a mindset’. Although Agile does require a certain mindset, it is based on a set of principles that are designed to guide the Agile working process.

Agile is the name given to an iterative approach to project management and software development. This focus on iterative development enables teams to respond quickly to change. Traditionally, you would plan a product or project in full on paper before start. However, in Agile, you start creating a product step by step so that at different stages of the process, feedback from the customer can be incorporated to ensure that what is being produced is still what is desired.

Core Agile Principles

Agile came about in response to the inability of traditional project management methods to meet the demands of the changing digital world. The existing processes were document driven and heavy. In response to this, a group of developers came together in 2001 and wrote the Agile Manifesto. These seventeen experienced professionals put together a list of 4 values that should guide those working in an Agile way. They also created 12 principles that are behind the Agile Manifesto –the underlying ideas that led to these 4 key values. The group consisted of people from all over the world, including Arie van Bennekum –who is now also the Chief Examiner for the EXIN Agile Scrum program.

This group, who called themselves the ‘Agile Alliance’, chose the following values:

1. Individuals and Interaction over Processes and Tools

Due to the nature of software development, this first value is often hard to fulfill. There is often too much focus on ‘scientific management’, meaning that people view the software development process from the perspective of the tools used to do it. However, the point is to value the people and what they do over the tools and processes they use. This is because the human factor is important. People will create the product or solution, the tools and processes are simply helpful in enabling them.

2. Working Software over Comprehensive Documentation

Before the concept of Agile emerged, there was an emphasis on working in a document driven way. Very often, all information would be documented formally throughout the project and a complete and detailed plan was made before even beginning. After a project was completed, this documentation often never saw the light of day again. The focus should be shifted towards creating working software to prevent unnecessary effort being spent on documentation that is not of long-term use.

3. Customer Collaboration over Contract Negotiations

Collaboration with the customer is central to Agile. Customers should be encouraged to give feedback and ask for new requirements –at any stage of the project. This should not be a one-way street. Collaboration is truly working together towards the end product. It is important not to think of the team and the customer having different end goals. The end goal is to create value for the end user. In that respect, creating a detailed contract doesn’t make sense because of the iterative nature of Agile projects.

4. Responding to change over Following a plan

Agile is not about following a set plan. Agile is about following the creative process. Instead of deciding what to do before you start, the team adjusts their approach depending on how the project develops. This allows customers to give feedback throughout the process which helps ensure that the end product is what they actuallyneed and not what they thought they wanted.

Agile Methodologies and Techniques

There are many different Agile methodologies that are used by people in a variety of industries. The methodologies below are amongst the most popular ones being used in software development at this moment.

DSDM (Dynamic Systems Development Method):

Dynamic Systems Development Method is an Agile methodology that keeps the scope of the product dynamic, just like most Agile methodologies/frameworks, but also fixes the time aspect. Where Scrum projects can go on until the product is fully finished, DSDM timeboxes the entire project, meaning it will end once the time has passed. The team will then deliver everything they have done in that time, irrespective of whether they achieved the goals or not. The decision then needs to be made as to whether to continue in a new timeboxed project or start an entirely new and different project.

Extreme Programming (XP):

XP is an Agile practice much more technical than Scrum. It contains many practices focused on testing everything and having specific standards for how the programming code should be formatted. In XP you work in pairs, alternating between coding yourself and watching besides a colleague who’s coding. This increases the overall quality of the code as well as making sure that there is more than one person who is familiar with the specific task.

KanBan:

Originally a technique that was used in manufacturing, Kanban has now been picked up in IT. In Kanban, it is important to work visually. This is done with a Kanban board that shows 3 stages of work (at least 3, but often more) –to do, doing, and done. Each stage of the development can have a maximum number of Work-in-Progress (WIP) items assigned to it. Every time a WIP item is done it, it should be moved to the next stage. However, it cannot be pushed to the next stage unless there is room for it. So the developers must pull an item into the next stage when they have room for it. If necessary, developers from other stages can help them with their WIP items to clear up space for the flow to continue. This ensures that developers are focused on the entire process and not just their own tasks.

MoSCoW:

MoSCoW is a way of prioritizing the features within the scope of the project. It divides these features in 4 categories:

• Must Have: These features are criticalfor the final product. They must be included for it to work.
• Should Have: These are features that are very important for the final product. However, it can be held back until later or another way to satisfy the requirement can befound.
• Could Have: The features that are desirable for the product but there would not be any issues if they are not included.
• Won’t Have (this time): The features that are nice to have, but are not worth investing in now.

Story-point Estimation methods

One thing that many Agile methodologies have in common is that they use estimation to ensure that a software development team is able the manage their workload properly. There are a number of different ways to estimate. The methods below are the most used.

Affinity estimation:

Affinity estimation creates a ranking of relative effort for all user stories from least amount of effort to the most. They are the grouped into buckets and given a story point value. By creating a ranking based on relative effort the team can see which user stories will take roughly the same effort, and then estimate them at the same value.

Planning Poker:

This method gives every team member a group of cards with point values on them. When estimating a user story, every member picks a story point value. All cards are then shown at the same time. If the values are very similar, the average or mean of the values is picked, if there are big differences the team discusses why this might be. The method of showing a selected card at the same time ensures that members are not influenced by others.

Triangulation estimation:

Triangulation is a way of double-checking the estimation for story points. This involves using existing user stories that have been estimated to compare the effort they required compared to a new user story. Naturally, a user story that is valued at 5 story-points should be 5 times the work of an item with 1 story-point and half the effort of an item with 10 story-points. By comparing user stories on both side of the estimate, you can increase the reliability of the assigned points.

Agile Practices

There are a number of different agile practices that have gained popularity in the software development domain. Continuous integration and test-driven development are two of the most used.

Continuous Integration:

Continues Integration is a practice in which new code must be integrated into the existing code. The entirety must then be tested to see if anything has broken as a result of the addition of the new code. If it did, these issues must befixed by the person(s) that integrated the code. It doesn’t matter whether they change the existing code or the new code to do so.

Test-driven development (TDD):

This method focuses on creating tests that must be passed in order to drive development. The first thing the team does is to create a test. They then start writing enough code to pass it. The test is designed to reflect the requirements of the feature. By having the test in place before starting to code, developers are always able to see if their new code does or doesn’t break anything in the existing one. This method enables developers to be focused on the problem instead of the solution.