When it comes to agile development methodologies, you will probably think of Scrum, Kanban, Lean and Smart. All these methodologies culminated in the Agile Manifesto, a declaration composed of 12 principles and 4 values ​​that guide software development.

These methodologies are very interesting - especially if you are starting to get acquainted with this universe. However, as we will see in this article, we should not get stuck on these processes, but adapt them to the demands of each business and digital product.

Furthermore, we need to understand that agile software development involves not only engineering methodologies, but also design, which plays a key role in problem solving.

The Agile Manifesto: Where it came from and where will it go

Created to enhance results, the Agile Manifesto brings together actions, tools and strategies used in software development.

It all started in the mid-1990s, when specialists in the field questioned traditional methodologies, deeming them ineffective, or even impractical.

The dissatisfaction was fair: industries and technologies change so quickly that ‘traditional methods’ often just can’t keep up. In addition, customers are not always able to clearly and objectively define software requirements, making everything even more difficult.

The solution was to create new processes, capable of adapting to constant market changes and initial uncertainties of a project. That’s where agile software development methodologies emerged, ‘a collection of different techniques and methods that share the same basic values ​​and principles.’ (COHEN et al, 2003, p.2).

Years later (early 2001, to be more exact), 17 creators and representatives of these new methodologies gathered to discuss alternatives. They were emphatic to say that they were not against implementing processes or using methodologies. In fact, they defended modeling and documentation, as long as it wasn’t in excess. They prioritized agility and flexibility, after all, every planning has its limitations and every project is subject to adversity and surprises.

Together, they defined the Agile Manifesto, which is still a reference in software development today. This document expresses the fundamental values ​​of agile methodologies and their 12 principles.

Values and principles of agile methodologies of development

Agile development methodologies are based on 4 core values:

1. Individuals and their interactions above processes and tools;

2. Software in production above exhaustive documentation;

3. Customer collaboration above contract negotiation;

4. Responses to changes above planning execution.

Notice how, currently, these values ​​have been absorbed by various businesses, especially startups and digitally mature companies.

Now, let’s go to the 12 principles of the Agile Manifesto:

1. Our highest priority is to satisfy the customer through the continuous and early delivery of value-added software;

2. Changes to requirements are welcome, even at later stages of development. Agile processes take advantage of changes for competitive advantage for the customer;

3. Working with short production cycles, delivering simple functional software to test hypotheses and reap lessons learned;

4. Developers and other professionals must work together daily throughout the project;

5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done;

6. The most efficient and effective method of conveying information to and among a development team is through face-to-face conversation;

7. A working software is the primary measure of progress;

8. Agile processes promote sustainable development. Sponsors, developers and users must be able to maintain a steady pace indefinitely;

9. Continuous attention to technical excellence and good design increase agility;

10. Simplicity - the art of maximizing the amount of work not done - is essential;

11. The best architectures, requirements, and designs emerge from self-organized teams;

12. At regular intervals, the team reflects on how to become more effective and then adjusts its behavior accordingly.

The main agile development methodologies

If you’ve been working with software development for a while, you should know by heart the agile methods below. But if this is your first trip, then it’s good to pay attention to the next few lines. They can be interesting for your business. 😉

Scrum

Scrum is one of the most well known agile development methodologies on the market. It was created by Ken Schwaber and Jeff Sutherland to facilitate project management and team organization.

It works like this: each team member has specific roles and responsibilities. While the Product Owner manages demands, deadlines, goals and processes, aligning the customer’s needs and objectives with the team; the Scrum Master coordinates everyone’s work, delegating roles and monitoring the execution of tasks so that everything happens as expected. We call the other professionals on the team the ‘dev team’ (development team).

Scrum is divided into Sprints, which are the intervals between the deliverables defined for the development of steps. Each Sprint has an Increment, that is, an ultimate goal to be reached. Once each phase is completed, a Sprint Review takes place, that is, a product review. Once this is done, the dev team, the product owner and the scrum master carry out a Sprint Planning to determine the objective of the next step and what will be done (action plan).

This process is cyclical and ends only when the development of the product is complete.

Kanban

Kanban is a management technique that can be applied at different times.

I have a friend, for example, who uses it to manage the books he wants to 1. read, 2. is reading and 3. has finished reading.

Sounds insane? None of that! Kanban is great for anyone who wants to see the big picture as well as the details. Here’s how it works: A frame, physical or digital, is divided into 3 columns. From left to right we have ‘to do’, ‘doing’ and ‘done’.

Each task is noted on a card and ‘walks’ through the columns as the carriage rides.

Kanban created on Pipefy, a workflow management platform co-created here at ateliware. Find out more here. (Image: Pipefy blog)

Although this agile development methodology is quite simple, it requires constant updating and monitoring by the team. That is, the team needs to be committed and engaged with the method.

You can find a digital version of kanban on Pipefy.

Lean

The Lean methodology is suitable for validating ideas and hypotheses, providing greater flexibility in the development of digital or physical products.

Its main objective is to identify and eliminate possible waste. Therefore, the Lean method contributes to reducing the costs and complexity of tasks, in addition to optimizing productivity, deliveries and information sharing.

Lean is divided into 3 steps: build, measure and learn. Its creator (Eric Ries) recommends the creation of a MVP (Minimum Viable Product) during the development of a software. The MVP is a simplified and functional version of the product, used to validate ideas and generate learning so that the final version fully meets market and business expectations.

The Lean method inspired the creation of the Design Sprint, which is capable of generating solutions in just one week.

Smart

Just like Kanban, you can apply Smart in different contexts. Basically, this agile development methodology was created to set objective and realistic goals.

The Smart method is based on 5 principles, namely:

1. S (from Specific, or Specific): your goals must be clear and specific, without opening up to dubious or mistaken interpretations;

2. M (for Measurable): efficiency calls for tangible metrics, that is, numerical and exact goals. Even subjectivities can be measured;

3. A (from Achievable): challenges motivate us to move forward and to be even better. However, your goals must be achievable. Be realistic;

4. R (for Relevant): Your goals should make sense and impact your business;

5. T (from Time-related): Set a maximum time frame to reach your goals.

Why are you doing this?

Faced with uncertain and competitive scenarios, companies are realizing the need to implement more agile and efficient processes. All of the methodologies we’ve seen above can help you with this - but you shouldn’t get stuck to them.

Let me explain:

During a GOTO Conference, Dave Thomas, one of the creators of the Agile Manifesto, highlighted the following: We must not substitute principles for processes. That is, we must not empty the meaning of agility.

Being agile is not following this or that methodology, but to:

• Realize where you are;
• Take a step forward towards your goal;
• Adjust your goal according to what you have learned;
• and repeat.

How you do this will depend on the available team and structure, business goals, and even the level of digital maturity.

So, before going following a few steps or others, think about it: why are you doing this? Where do you want to go?

Agile Design

What about Design? How can it contribute to agile software development?

In the development of any digital or physical product, Design plays 3 fundamental roles:

1. Ensure that the project has the user at the center;

2. Generate value for the product and business results;

3. Optimize resources (time, money, staff, among others).

To satisfy user demands, we need to understand what they are. Therefore, the ideal is to map them from the beginning of the project. This mapping is carried out based on an analysis of the journey and the behavior of the target audience. During this investigative process, we collect information to identify:

• User behavior;
• Which problem will be solved and, therefore, opportunities to be worked on;
• What is the expected result in the short and long terms;
• Goals to be achieved and whether they are being achieved or not;
• Market trends;
• Restrictions and requirements.

At ateliware, we call this process Discovery. In it, we use Design Thinking and Double Diamond methodologies to map points of attention and opportunities.

It all starts with collecting information, which can be carried out based on qualitative and quantitative research. Then we analyze the results and compare them to the business needs. This step is known as UX Research.

After that, we define the road map, that is, the path we will take until the product launches. The road map shows everything that needs to be done, what the priorities are and when the deliveries will take place.

A roadmap example. (Image: Roadmunk)

In the Discovery we also have user flow, wireframes and prototypes.

The user flow is a drawing of all the minimum functionalities that the product must contain, as well as the sequence of steps performed by the user to reach a certain objective. In it, we also start to work on the information architecture, understanding what will go inside each screen and what each field must contain, for example.

User flow example. (Image: Dribbble)

From these features, we create wireframes, which are representations (usually in low fidelity) of all screens. Here, the objective is to assess whether the flow works and how the page and information will be structured.

Low fidelity wireframe example (Image: Ergomania UX)

In prototypes, we check if the screens are working. When I click on a button, for example, does it take me where it should? Does this path make sense? Does it need to be readjusted? In what way? This test should preferably be carried out with product users to gather feedback on what needs to be changed and avoid cognitive biases.

These tests with wireframes serve to validate ideas, reducing the risk of releasing a failed product, which makes no sense. In addition, they save resources during development, the low-fidelity screens require less time to be built.

At first glance, this process may seem a little onerous. However, the time invested in design at the beginning of a product will certainly save resources later on.

Imagine developing and releasing a software without verifying if it really complies with what your users want and what your business needs. Certainly it will need a lot more maintenance and its scalability will suffer.

Using agile development methodologies is not about doing everything in a hurry, but acting efficiently to avoid problems in the future.