Agile methodology is not a set of practices, processes and tools.

Agile is not a manual. It's not a set of directions. It's not a checklist. As one of its creators said “It’s a mindset and a culture – and it takes the buy-in of the entire organization to be successful”, this sentence is valid for all process methods, without the general commitment of the company or organization to the possibility of failure. it's big. The expression Agile comes from the English Agile software development, that is, agile software development. It is a name given to a set of practices for software projects that are considered innovative for breaking certain paradigms that existed until then in software engineering but that are already applied in other fields. Agile provides multiple opportunities for stakeholder and team engagement - before, during, and after each Sprint. By involving the customer at all stages of the project, there is a high degree of collaboration between the customer and the project team, providing more opportunities for the team to truly understand the customer's vision.

Delivering working software early and often increases stakeholder confidence in the team's ability to deliver high-quality working software and encourages them to become more deeply involved in the project. An agile approach provides a unique opportunity for customers to be involved across the entire project, from prioritizing features to iteration planning and review sessions, to frequent software builds containing new features. However, this also requires customers to understand that they are seeing a work in progress in exchange for this added benefit of transparency. By using Sprints with a fixed schedule and a time-box of 1-4 weeks, new features are delivered quickly and frequently, with a high level of predictability. This also provides the opportunity to release or beta test the software earlier than planned if there is sufficient business value. Since each Sprint has a fixed duration, the cost is predictable and limited to the amount of work that can be performed by the team on the fixed-schedule schedule.

Combined with the estimates provided to the customer prior to each Sprint, the customer can more readily understand the approximate cost of each feature, which improves decision making about feature priority and the need for additional iterations. While the team needs to focus on delivering an agreed upon subset of product features during each iteration, there is an opportunity to constantly refine and prioritize the overall product backlog. New or changed backlog items can be planned for the next iteration, giving you the opportunity to introduce changes every few weeks.

Don't confuse Agile methodology with Agile method tools.

Yesterday in an interview among countless questions I was asked two that made me change this article. How do you apply Agile in the company or organization? the purpose of the question was what tool do i apply but i only realized when at the end of my answer the person said "no, do you work with scrum or kanban?" and the second was if I applied a certain Portuguese term that I had never heard, I have Scrum, Scrum Master, UX and others certification and I didn't know what it was referring to, it may be ignorance on my part, after all I don't know everything but it bothers me the use of regionalized expressions or terms. The interviewer was very friendly and solicitous and was probably following a booklet prepared by someone, but it was a lesson for me as not everyone has this clear concept.

You can apply Agile methodology and concepts without necessarily opting for a tool or method like Scrum, Lean, Kanban, Extreme Programming (XP), Smart, Feature Driven Development (FDD), Microsoft Solutions Framework (MSF), Dynamic Systems Development ( Dynamic System Development Model), etc... Using a tool or method is like following a cake recipe, there are several chocolate cake recipes and following the recipe to the letter will lead you to the final goal, but which recipe takes to the best chocolate cake? Probably the one that uses the best of each recipe. However, for this to happen, you must delve into the best recipes, in the same way that happens in the application of the Agile methodology. This requires extensive experience and knowledge, knowing how to identify in an organization which recipe, method or tool to apply is the hardest part. Why and who told you that using Scrum or Kanban is better for your organization? maybe not.

By breaking the project into manageable units, the project team can focus on high-quality development, testing, and collaboration.

By allowing the customer to prioritize resources, the team understands what is most important to the customer's business and can deliver the resources that provide the most business value. Agile typically uses user stories with business-focused acceptance criteria to define product features. By focusing resources on the needs of real users, each resource incrementally adds value, not just an IT component. This also provides the opportunity to test beta software after each Sprint, gaining valuable feedback early in the project and providing the ability to make changes as needed. In addition, by producing frequent builds and conducting testing and analysis during each iteration, quality is improved by finding and fixing defects quickly and identifying mismatches in expectations early.

During our own experience in adopting Agile software development practices, we have seen solutions delivered on time and with a higher degree of customer satisfaction. By incorporating the ability to change, we were able to better incorporate feedback from demos, usability testing, and customer feedback. Agile is a powerful concept for software development, not only providing benefits to the development team, but also providing a number of important business benefits to the customer. Agile helps project teams deal with many of the most common project pitfalls (such as cost, schedule predictability, and scope creep) in a more controlled manner. By reorganizing and rethinking the activities involved in custom software development, Agile achieves these same goals in a leaner, more business-focused way.

Agile development and testing practices have worked wonders for countless organizations. The positive aspects of Agile are not hidden but very evident in areas such as reduced time to market, improved communications or lower costs. Many well-known software professionals have been quite successful with the advantages of Agile, while a few have also faced the disadvantages. When does Agile fail? These moments are characterized by chaotic processes, inferior quality, lack of communication and various other problems that cause Agile deficiencies.

Advantages of the Agile model:

1. Customer satisfaction through fast and continuous delivery of useful software.
2. People and interactions are emphasized over processes and tools. Customers, developers and testers constantly interact with each other.
3. Working software is delivered frequently (weeks instead of months).
4. Face-to-face conversation is the best form of communication.
5. Close and daily cooperation between entrepreneurs and developers.
6. Continuous attention to technical excellence and good design.
7. Regular adaptation to new circumstances.
8. Even late changes to requirements are welcome.
9. Greater alignment between the team and with customers and quick resolution of possible problems and conflicts;
10. Risk reduction and high quality end result;
11. Saving resources through more assertive deliveries;
12. Agility and efficiency in deliveries and in the execution of the project as a whole;
13. Flexibility to propose alternatives and reach the best possible solution.

Disadvantages of Agile:

1. For some software deliverables, especially large ones, it is difficult to assess the effort required early in the software development lifecycle.
2. There is a lack of emphasis on the required design and documentation.
3. The project can easily get sidetracked if the customer representative is unsure of the end result they want.
4. Only senior programmers are able to make the kind of decision needed during the development process. So there is no place for novice programmers unless combined with experienced resources.

Agile developments also sometimes fail due to unrealistic expectations - what agile really is and what it can help you achieve. It is commonly believed that Agile is a set of practices, processes and tools, when in fact, Agile is really more of a mindset and culture.

When to use the Agile model:

• When new changes need to be implemented. The freedom that Agile gives to change is very important. New changes can be implemented at very low cost due to the frequency of new increments that are produced.
• To implement a new feature, developers only need to waste a few days' work, or even just hours, to roll back and implement it.
• Unlike the waterfall model in the agile model, very limited planning is required to start the project. Agile assumes that end-user needs are always changing in a dynamic business and IT world. Changes can be discussed and features can be affected or removed based on feedback. This effectively gives the customer the finished system they want or need.
• Both system developers and stakeholders find that they also have more freedom of time and choice than if the software were developed in a more rigid sequential fashion. Having options gives them the ability to leave important decisions until more or better data or even entire hosting programs are available; which means the project can keep moving forward without fear of coming to a sudden halt.

The agile development model is also a type of incremental model. The software is developed in rapid, incremental cycles. This results in small incremental releases with each release based on previous functionality. Each version is fully tested to ensure that the quality of the software is maintained. It is used for time critical applications. Extreme Programming (XP) is currently one of the most popular agile development lifecycle models.

What is the difference between SCRUM and its main competitors?

WHAT IS SCRUM?

Scrum is a framework within which people can solve complex adaptive problems while delivering the highest possible value products in a productive and creative way. Scrum is a lightweight framework that helps people, teams, and organizations generate value through adaptive solutions to complex problems. In short, Scrum requires a Scrum Master to foster an environment where:

1. A Product Owner orders work for a complex issue in a Product Backlog.
2. The Scrum Team turns a selection of work into an increment of value during a Sprint.
3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.
4. Repeat

Scrum is simple. It is the opposite of a large collection of intertwined mandatory components. Scrum is not a methodology. Scrum implements the scientific method of empiricism. Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and self-organization to deal with unpredictability and solve complex problems. The graphic below represents Scrum in action, as described by Ken Schwaber and Jeff Sutherland in their book Software in 30 Days, taking us from planning to software delivery.

This short video provides a simple overview of Scrum, allowing viewers to learn about the roles, artifacts, and events and how they come together to deliver a product to market.

The Scrum Values

While always considered part of Scrum and often written about, the Scrum Values have been added to the Scrum Guide. These values include Courage, Focus, Commitment, Respect, and Openness.

The Scrum Team

The fundamental unit of Scrum is a small team of people, a Scrum Team. The Scrum Team consists of a Scrum Master, Product Owner and Developers within a Scrum team, there are no sub teams or hierarchies. It is a cohesive unit of professionals focused on one goal at a time, the Product Goal.

Where does your current role fit in?

Scrum defines three responsibilities, the Product Owner, Scrum Master and Developer. But what happens if you have a different job title? That doesn't mean you're out of luck or out of a job; in most cases, it means just the opposite, with your work expanding to deliver more value to the Scrum Team. So where do you fit in Scrum?

Similarities common to all Agile Methodologies

Some of the most used agile methodologies in companies today are Scrum and Kanban. What they have in common, in addition to Agility, is a set of practices based on certain values, broken down in the Agile Manifesto as:

• Prioritize individuals and interactions over processes and tools. All the people involved in the process must work together on a daily basis, communicating constantly and openly. Everyone should always seek to maintain a sustainable work environment that provides support, motivation and trust.
• Value the smooth running of the software over comprehensive documentation. Functional software made quickly and with quality is the primary measure of progress.
• Collaborating with the client more than negotiating contracts.
• Responding to change more than following a plan. Evaluate project progress every cycle and accept requirements changes even at the end of development. So the customer can take competitive advantage.
• Maximize the amount of work that didn't need to be done by focusing on technical excellence of team members and simple and intuitive design and usability.
• Build, through daily coexistence, self-organizing teams. Team members reflect on ways to increase their productivity and effectiveness based on the results of each cycle. Thus, they adjust their behavior in order to optimize their synergy and increase their frequency of deliveries.

Differences between Scrum and Kanban

What differentiates them is:

• Scrum is about self-management and how developers interact and what they do when they're not writing code.
• Kanban is about avoiding wasted resources and optimizing production. This happens by limiting each developer's workload. The visualization of the flow of resources on the production line is created with post-its on a board.

Kanban is continuous and Scrum is iterative. Scrum has closed loops with defined goals that repeat, while Kanban is best suited for teams that have unplanned work in sight. For example, support issues and emergency-required functionality – as it has no cycles.

Difference between Scrum and Agile

It is common to have the impression that these terms are the same. However, Agile is a set of methods and practices based on the values expressed in the Agile Manifesto.

Scrum is not a process or a technique for building products. It is an incremental methodological framework (or framework) that is used to implement Agile development. You can employ various processes or techniques for this.

Scrum makes clear the effectiveness of the companies' product management and development practices in which it is implemented, so that they can improve those practices.

The framework consists of Scrum teams associated with roles, performed by team members during events, with the help of artifacts.

As described in the Scrum Guide, each component within the framework serves a specific purpose and is essential to the use and success of Scrum. Rules integrate events, roles, and artifacts, managing the relationships and interactions between them.

Scrum Events

Events are used in Scrum to create regularity and minimize the need for unforeseen meetings. All events are timeboxed, which means they have a minimum time and a maximum duration time.

All Events are linked to the Sprint, which is the main one, and they all repeat each time a Sprint ends and another begins. Hence the iterative nature of Scrum.

Before the Sprint starts, ideally in the first Sprint Planning of the project, its duration is fixed by the Scrum Master. It cannot be reduced or increased.

The remaining events also have timeboxes but may end earlier than expected if the proposed objective for each of them is reached faster. This ensures that an appropriate amount of time is spent without allowing waste in the process. Scrum Events are:

Sprint Planning: the planning

• Before starting a Sprint, the Product Owner presents to the Scrum Master and the developers the most priority items in the Product Backlog. The team selects the items that will be part of the Sprint Backlog.
• After that, the SM and PO withdraw from the meeting so that the “dev” team can technically define how the Sprint Backlog items will be developed. This definition is supported by Planning Poker, which we will see later in the article. These are the two steps of Sprint Planning.
• During the first stage, the Product Owner presents the Product Backlog items from a business perspective, showing the reasoning used by him to define which items have higher priority. The team can clear up doubts with the PO and already idealize which are the possible technical solutions for each item, since these items will form the Sprint Backlog.
• After the Sprint Backlog is formed, the full Scrum team will define a goal for the Sprint, succinctly describing what the team should focus on for this iteration.
• During the second stage, the developers get together so that they can outline the technical planning for each item in the Sprint Backlog. Each item is broken down into smaller tasks or turned into User Stories if necessary. Estimated time will be spent on them. This estimation is usually done with Planning Poker.
• The analysis of the effectiveness of the Sprint Planning will take place in the Sprint Review.
• It is important for team members to remember any time off, vacations, holidays, travel, or any other scheduling details that will occur during the Sprint that could affect your progress. In this way, they will be able to estimate as accurately as possible how much work will be done.

Planning Poker: the game and its rules

Teams that use Story Points also often use a poker game-like exercise. Playing cards are used to estimate the effort that will be spent on each task. The dev team will take an item from the backlog and briefly discuss it. Each of the members will think of an amount of Story Points that they consider adequate for their execution. Everyone picks up and shows the others a playing card with the number equivalent to their estimate. If everyone agrees, the exercise ends here. If there is disagreement, each developer must understand the logic behind the different estimates. Estimation must be a high-level activity. That means disagreements can't be too blatant. If some members estimated 1 Story Point while others estimated 5, talk some more, until those numbers get closer.

The team must agree on the maximum number of Story Points, hours of work, or whatever measure the team members choose.

Sprint Retrospectives are a time for the team to reflect on the accuracy and effectiveness of previous iterations of that project. This reflection includes the accuracy of your estimates.

How accurate is it necessary to be?

In a Planning Poker session, imagine that half the team estimated 3 Story Points and the other half estimated 5 Story Points for a Story. It's easy to accept 4 Story Points as the estimate and move on to the next task, but the team must have enough synergy and maturity to understand that it's not productive to do so. This only generates a false sense of precision. There is no need to be 100% accurate. What is needed is to be precise enough to ensure that the Sprint is running smoothly and to plan everything in advance. In addition, there may be a loss of transparency in the process if the easiest decision is made. This decision leads to a decrease in team communication. Maybe 5 Story Points is a better estimate and you'll never know if you don't talk about it.

Sprint and its States (To Do, Doing, Done)

A Sprint is a cycle with a beginning and an end, with a predetermined length of time by the Scrum Master. The Sprint is the heart of Scrum. All other events and artifacts revolve around him and his execution. At the end of each Sprint, there is a new functionality to be validated or blocked by the Product Owner. Then, definitively implemented or modified until it is within the rules and business values proposed by him.

The Duration of Sprints

The SM needs to analyze the stability of the product and project scopes before defining the duration of the Sprints. If one of them is very mutable and these changes are related to lead time, it is more prudent for the Sprints to be a week or two long. If the resources available to scopes are more stable, two to four week sprints may work best.

It is neither common nor recommended that the Sprints of a project vary in size, as this generates instability and unpredictability in the execution speed of the same. The Sprint ends when the duration time defined for it expires or when the objective defined during Sprint Planning is reached. For the Sprint to end successfully, a software increment must be delivered. During the Sprint, each task has a state. This state serves to indicate where your execution is.

Sprint States

Something common, and similar to what is done in Kanban, is to divide Sprint tasks by columns on a physical or virtual board. Each of them is equivalent to the status of a card. This card moves through the columns as what is described in it is implemented. The most common states are:

• Backlog. Designates the Product Backlog.
• Blocked. It contains tasks that cannot be inserted in To Do due to some impediment.
• To Do (To Do). Designates the Sprint Backlog.
• Doing or Work in Progress. Lists tasks that are being done, indicating the developer responsible for doing them in each card.
• Verify. Where are the tasks already developed that need to be tested.
• Done (Done or Done). These are tasks that have already been completed.

Mandatory states are just To Do, Doing and Done.

So that all stakeholders are aligned on what it means to complete a task, there is a document called the Definition of Done. In it there is a generic description of what are the minimum steps for the completion of deliverables. This document is like a quality assurance of the increments. It can be modified over the iterations as it is revised in each Sprint Review. It is mandatory that all stakeholders comply with the Definition of Done so that there is transparency and trust between them during the project.

Daily Scrum: the daily meetings

Every day, the team meets to talk about the progress of the current Sprint. The goal here is to promote ongoing alignment among all team members and help the Scrum Master predict what might actually be delivered at the end of the Sprint. This daily meeting is called the Daily Scrum or just Daily. It usually lasts around 15 minutes. It can be extended with specific team members depending on what is discussed and possible impediments that may arise. Full team participation is mandatory. For this event, this always includes the Scrum Master but not always the Product Owner. The participation of other stakeholders, such as managers from other sectors or the customer, is less common but can occur, but they will only be listeners.

The Daily should not delve into technical discussions. Any issue that arises during it should only be extended to members directly involved or affected by that issue. If necessary, what was discussed in this step is briefly passed on to members who were not involved. The questions that must be answered by developers at Daily, thus reporting their progress to the Scrum Master, are:

• “What I did yesterday” or “what I did since the last Daily”;
• “What I intend to do today” or “what I intend to do until the next Daily”; and
• “There are the following impediments for me to complete my tasks” or “there are no impediments to my tasks”.

Given what has been answered, the Scrum Master must work to eliminate the impediments. If they do not exist, you must work so that what is still missing in this Sprint is completed with quality and on time.

Sprint Review: reviewing the cycle

After the end of the Sprint, the team shows how the development of the deliverables happened. Usually present in the Sprint Review are the Product Owner, the Scrum Master and the customer or the stakeholders that represent it. The focus of the meeting is to demonstrate the new features with as few bugs as possible and working relatively well. Ideally, the duration of the Review should not exceed two hours. Increments should be revised according to the Sprint objective that was agreed in the Sprint Planning. The team must always strive to achieve this goal.

Sprint Retrospective: reflect to improve

The last Scrum Event is the Retrospective. The team reviews the performance of the Sprint that has just ended and talks about ways to improve their work processes for the next Sprint. There is discussion and exposure of difficulties and how the team thinks they can avoid them.

This is related to a few factors. Are they:

• the commitment of each developer,
• the division of tasks done in Sprint Planning,
• and the impediments pointed out in the Daily, in addition to the SM's decisions to resolve them.

The team decides how to proceed from there to improve its efficiency in the next Sprint. Members must aim to increase their productivity without losing quality. Like the Daily, the Retrospective also has an ideal duration. In this case it is one hour, but those involved in a more complex issue can continue talking after the meeting.

One of the Retrospective techniques is the start-stop-continue:

• “Devemos come?ar a fazer…” (start)
• “Devemos parar de fazer…” (stop)
• “Devemos continuar a fazer…” (continue)

Scrum of Scrums: the solution for large projects

Scrum of Scrums or Meta Scrum is a scalability engine created at IDX Systems (now GE Healthcare).

It is defined by the Agile Alliance as “a technique for scaling Scrum to large groups (more than a dozen people), consisting of dividing the groups into agile teams of 5 to 10 members”.

Still, it is defined by Jeff Sutherland as “responsible for bringing the software of all teams to the Definition of Done at the end of the Sprint, or to releases during the Sprint”. While working at IDX, Jeff Sutherland and Ken Schwaber implemented it as a technique for scaling individual Scrum teams to the corporate level.

Managing a Scrum of Scrums

Coordination of the various teams is done in a Scrum of Scrums meeting. This meeting can be held daily, twice a week, or at least once a week. Every Scrum team has its representative. He can be the Scrum Master or another team member chosen by the other team members. If the topic one of the teams wants to discuss is very technical, both the technically qualified team member and the Scrum Master may want to participate. The Scrum of Scrums meeting is performed very similarly to the Daily Scrum. Despite not having a predetermined length of time, it is common for it to last 15 minutes, just like the Daily of common Scrums. At the Scrum of Scrums meeting, each “ambassador” from each Scrum team must respond:

• What has your team accomplished since the last meeting?
• What problems occurred (if they occurred) and how they negatively affected your team;
• What does your team want to accomplish before the next meeting?
• What actions by your team in future Sprints can interfere with the Sprints of other teams;
• And if your team sees any interference coming from other teams.

The purpose of the Scrum of Scrums meeting is to ensure coordination and integration of the results of the various teams, eliminating all impediments. This may involve involving two or more teams working together for a while or renegotiating responsibilities. This needs to be managed with a Scrum of Scrums Product Backlog and maintained by the Scrum Master elected as head of this process. Or, still, by a Project Manager who has the Scrum of Scrums Product Backlog as his main demand.

How to Organize the Scrum of Scrums

A Scrum of Scrums framework can be effective even in larger organizations with multiple teams. Or on projects with Scrums distributed in different locations. As long as his own meetings are conducted properly. The emphasis should be on coordinating the various teams and resolving impediments. The objective is to ensure that individual teams meet their goals. Thus, the overall project objective of all teams will be achieved. Waste of time, work and resources are minimized to the maximum by a team formed specifically to assist the Scrum Master or Project Manager in charge of the Scrum of Scrums. Members are selected from each Scrum or are exclusive members. This ensures that transparency and good communication is maintained across all Scrum teams. Ken Schwaber called this Integration Scrum in his book The Enterprise and Scrum. Having at least one release every three months is the goal.

How to implement Scrum in your company

Implementing Scrum has a lot to do with implementing digital transformation. In addition to Scrum being a Digital Transformation tool, both processes directly depend on changes in organizational culture. These changes can only take place effectively if they are made gradually and with a lot of engagement from company leaders and employees. Leaders will always have to balance the pros and cons with transparency in front of their teams, aiming to integrate all sectors of the company.

Agile Methodologies for Organizations

What happens in organizational implementations of agile methods is not the use of Scrum itself, but of modified frameworks. They are also based on the principles of the Agile Manifesto, but with this integration of sectors already considered since their conception. An example of such frameworks is SAFe, which addresses all layers of an organization. Dean Leffingwell, the creator of SAFe, defines it as “a framework for implementing agile practices at an enterprise scale”.

Transition to Scrum

The transition from traditional to agile must be careful and very well aligned internally. Just like any other organizational culture change, due to the impact it will have on employees. The teams of each sector must be multidisciplinary. Organizational silos must be reduced as much as possible so that synergy between sectors is always prioritized. This synergy and multidisciplinarity will help in Agility, as employees who are proficient on several fronts will be able to help each other and bring different visions to the company. It is expected that some of the employees will show resistance to the transition process. This is where the main role of industry leaders comes in. They must always transparently align expectations and explain what improvements will be obtained for each sector with the implementation of Scrum – or any other agile methodology.

I hope you have understood a little more about agile methodology and implementation tools with their concepts.