It is one of the approaches that influenced the Agile Manifesto, which articulates a set of values and principles to guide decisions on how to develop high-quality software more quickly.

Where and when to use Scrum methodology

Scrum is widely used by software development teams. In fact, it is the most popular agile methodology. According to this report, about agile development in companies, about 70% of development teams use Scrum or a hybrid.

Scrum began in the software industry and has since spread to universities, military sectors, the automotive industry, and others.

Even if the advantages of the Scrum methodology are well known (agility, quick feedback, better communication, flexibility, etc.), sometimes we can face the uncertainty of using this framework or following a traditional path for development.

The following 7 aspects can be considered to determine when it is convenient to use Scrum in your project.

• When the requirements are not clearly defined
• When the probability of changes during development is high
• When the need arises to test the solution
• When the Product Owner is available
• When the team has self-management skills
• When the contract is given in hours
• When customer culture is open to innovation and rapid change

Scrum fits in several types of projects with different purposes, but especially if it fits in one or more of the features mentioned above, it is a strong indication that you should use the Scrum methodology to manage the project.

What are the Scrum principles?

Scrum is defined by a group of principles (or values) that should be understood as simple guidelines to work together with the team. They are:

• Courage – especially when it comes to solving difficult problems
• Focus
• Commitment to team objectives
• Respect to team members
• Receptivity to work and to any challenge that may arise

By incorporating Scrum’s values, a team assumes the shared responsibility for the success or possible failure of the project. And unless each member of the Scrum team adheres to these values, the team will not have the necessary basis to be successful.

The main roles within the Scrum methodology

There are three essential roles for scrum success. The Product Owner, Scrum Master, and the development team. And because the scrum teams are multifunctional, the development team includes testers, designers, UX specialists, and operations engineers, in addition to the developers. Let’s talk about each role.

Scrum Master

Even if you have never worked with Scrum, it is very likely that you have heard of the term Scrum Master. The Scrum Master is the team advisor, he or she must help the team members with the planning and execution of tasks.

The scrum master is the person in the team responsible for managing the process and only the process. He is not involved in decision making but acts as a guide to guide the team during the scrum process.

Scrum Master protects the team from external distractions, such as customer feedback or other projects, allowing team members to focus during the sprint and on the selected goal.

While Scrum Master focuses on helping the team produce the best results, the Product Owner works to direct the team to the right goal.

Project Owner

The project owner or Product Owner is usually one of the main stakeholders in the project. Part of his or her responsibilities is to have a vision of what he or she wants to build and to convey that vision to the team. This is the key to successfully starting any agile software development project. The project owner does this in part through the product backlog, which is a list of features considered a priority for the product.

The Project Owner is responsible for prioritizing the backlog during project development, to ensure that the result, at the end of each iteration (Sprint), is closer than he expects at the end of the project.

The Project Owner is usually a leading user of the system or someone in marketing, product management, or anyone with a solid understanding of users, the market, the competition, and future trends for the domain or type of system being developed.

This, of course, varies depending on whether the team is developing software for commercial use, for internal use, hardware, or some other type of product. Ideally, the person in the role of Product Owner should have a vision of the final product that should be built. So that the team can then work with a clear vision of what should be built.

Scrum Team

The third and last role in the management of the Scrum is the Scrum team itself. Although individuals who are part of the team may have traditional titles such as software engineer, programmer, designer, tester, or architect, the Scrum methodology establishes that each person must contribute in every possible way to complete the work of each sprint.

By becoming a member of a Scrum team, those who in the past fulfilled specific roles tend to keep some of these aspects, but to them, new responsibilities can be added.

A typical Scrum team is composed of three to nine people. And instead of climbing and forming a giant team, Scrum prefers to have “teams within teams”. This way, it is easier to manage the team to complete the sprint successfully.

What is a Sprint

A sprint is a short period of time when the team works to complete a certain amount of work. Sprints are the core of Scrum methodology and agile methodologies.

Choosing the right items to work on during the sprint is a collaborative effort between the Product Owner, Scrum Master, and the development team. The Product Owner defines the goal that the sprint should achieve.

Like all scrum events, Sprint also has a maximum duration. Normally, a Sprint has a duration of one month or less. The duration of each sprint is decided during one of the meetings for the beginning of the project.

Scrum meetings

The scrum methodology defines five types of meetings held at regular intervals:

• Sprint Planning
• Daily Standup
• Sprint Review
• Sprint Retrospective
• Refinement of the product portfolio

Sprint Planning

A meeting that is not only part of the Scrum methodology, but of most other agile methodologies. It is held by the Development team, Scrum Master, and Product Owner. It always happens at the beginning of a new Sprint, with the purpose of establishing a work list, with the correct priority for each task, and also to align and motivate the team for success during the sprint.

The Project Owner will be talking about the backlog with the development team, presenting the amount of effort that will be involved. The team then decides how much of the backlog work can be completed in this iteration. Following the best practices of Sprint planning, the duration of this sprint planning can be maintained within 4-6 hours.

Daily Stand-up

An essential synchronization meeting in both Scrum and Kanban methodologies. It is an agile ceremony held for the development team facilitated by Scrum Master. The owner of the product and the interested parties may attend this meeting to answer the questions raised by the development team.

This meeting takes place every day preferably in the same place and is usually held in the morning. The goal of the Stand-up is to keep everyone updated on the general progress of the project.

Each team member is asked to answer 3 questions:

• What did you do yesterday?
• What will you do today?
• Are there any impediments to your tasks?

The daily stand-up should be considered an informal meeting and should not last more than 15 minutes.

Sprint Review

As described in the Scrum Guide, the Sprint Review is performed at the end of each Sprint to evaluate the updates made in the software and adapt the Product Backlog, if necessary.

This is also an informal meeting, aimed at obtaining feedback and establishing collaboration. And since a project may have one or several sprints, the number of revisions will also vary.

During the sprint review, the team and stakeholders evaluate what was done at Sprint. Based on this evaluation and any changes in the Product Backlog during Sprint, participants contribute ideas for the next implementations to optimize the value of the final product.

This meeting should not take many more than four hours during a month of Sprint. For shorter Sprints, the meeting is usually shorter. The Scrum Master must ensure that the event occurs and that the participants understand its purpose.

Sprint Retrospect

The sprint retrospective is an opportunity for the Scrum team to evaluate itself and create an improvement plan to be put into practice during the next Sprint.

The sprint retrospective is usually the last thing to be done in a sprint. Many teams hold this meeting immediately after the sprint review. The entire team, including both the Scrum Master and the Product Owner, must participate.

This session is basically a meeting of “lessons learned” to identify potential pitfalls, past mistakes, and seek new ways to avoid those mistakes.

In other words, this meeting serves to discover what activities and “things” the team is doing well, what activities should be continued, and what can be done to improve.

This is a maximum three hour meeting during a month of Sprints.

Bottom line

The Scrum methodology is an agile process most used for product development, especially software development. Scrum is a project management framework, applicable to any project with aggressive deadlines, complex requirements, and a certain degree of exclusivity. In the Scrum methodology, projects advance through a series of iterations called sprints. Each sprint is usually two to four weeks long, conducted by Scrum Master.

Before, during, and after each sprint, meetings are held with everyone involved in the project including the Project Owner, Scrum Master, and the development team to establish new activities, priorities, and goals.

Write in the comments on how you used the Scrum methodology in some of your projects.

Agile is a group of methodologies that demonstrate a commitment to feedback cycles and continuous improvement.

Often the concept of method and methodology ends up confusing an understanding of the whole concept. I admit that before writing this post I also had my doubts, but I managed to reach a final understanding. Understand that:

Method is simply a research tool, a component of research – for example, a quantitative method such as interviews. Methodology is a system of methods used in a particular area of study or activity.

The image below explains where the set of agile methodologies and each methodology fits into the model.

What is the Agile set of methodologies?

Agile Methodology is an iterative approach to project management and software development that helps teams deliver value to the customer faster and with less headache.

Instead of betting everything on a single release, an agile team delivers work in small increments that can be used. Requirements, plans and results are continuously evaluated so that the team has a mechanism to respond quickly to possible changes or updates.

The original Agile Manifesto did not prescribe any kind of initial rule, such as two-week iterations or an ideal team size. It simply established a set of 4 core values.

• The focus should be on individuals and interactions, rather than processes and tools
• Working software is more important than comprehensive documentation
• Collaboration with the client is more vital than contract negotiation
• The process should respond to changes rather than following a plan

How you and your team will work on these values – whether you use Scrum or mix elements of Kanban and XP – depends entirely on you and your team.

How does the Agile Methodology work?

The agile model adopts an iterative development, and each iteration, also known as a sprint, is designed to be small and manageable to be delivered in a short period of time, usually one or two weeks.

The agile process is a group of development processes, and its main reason is to remove/avoid activities that may not be necessary for the project and remove anything that is a waste of time and effort.

Benefits of the Agile Methodology

Teams generally choose to use agile methodology because it allows them to respond quickly to market changes or customer feedback. Planning and implementation in small and frequent increments allows your team to get feedback on each change and integrate it into future plans at a minimal cost.

But it’s not just a numbers game – first and foremost, it’s about people. As described by the Agile Manifesto, human interactions are more important than following processes to the letter.

Collaborating with clients and teammates is more important than pre-defined rules. And delivering a functional solution to a customer’s problem is more important than hyper-detailed documentation.

But if we needed to list the benefits of agile methodologies, they would be:

• Faster: Speed is one of the greatest benefits of the Agile Model. A faster software development lifecycle also means less time between paying and getting paid.
• Increased customer satisfaction: Following this model, customers don’t wait months or years to get exactly what they didn’t want. Instead, they get iterations of something very close to what they want, much faster.
• Employee value: Employees whose ideas are valued are much more productive than those who are ordered to follow a set of rules.
• Eliminate rework. By involving the customer in more than just the requirements and delivery phases, the project remains in tune with the customer’s needs at each stage. This means less rework and less “off-line” time between the time we do the work and the time the client suggests revisions.

Examples of Agile Methodology

The most popular and common examples are:

• Scrum
• eXtreme Programming (XP)
• Feature Driven Development (FDD)
• Dynamic Systems Development Method (DSDM)
• Adaptive Software Development (ASD)
• Crystal
• Lean Software Development (LSD).

Teams usually choose one or two methods. The most commonly used methods are Scrum and XP, which fit together very well.

Let’s talk about them in a next article.

Bottom line

The agile methodology is an effective process for teams seeking a flexible approach to software development. The agile methodology can be implemented for any enterprise that requires a plan that needs to value collaboration with the client, teamwork, responsive changes and, of course, quality results.

Como a metodologia ágil melhorou a maneira de trabalhar de sua equipe? Não se esqueça de compartilhar suas dicas conosco!

Don’t forget to subscribe to our newsletter to receive all the news. See you next time.

Most of your programming career will be working as a team with other people. Value teamwork as soon as possible.

One of the most common questions developers are asked during interviews is whether or not they consider themselves to be a strong team member.

And although this question is a bit generic and widely used (not to say cliché), it is being asked for a good reason: teamwork is (very) important.

In times of crisis like the one we are living in 2020 with COVID-19, it is interesting to note some facts. Community and teamwork are being of vital importance.

Even if sometimes it’s for strange reasons like buying tons of toilet paper without any apparent reason or to build a hospital in less than 10 days.

We see what power a community has when it unites around a cause. In that case on a global scale.

To a lesser extent, we have our family, friends, people we study with, work with, who live in the same neighbourhood, city, and so on.

This also applies to us, developers, with our team.

Developer dilemma

I know that sometimes what we want is just a comfortable chair, air conditioning, good internet, headset and a good cup of coffee. It’s not too much to ask, is it? And there’s nothing wrong with that. Individualities should be respected. And if you freelance or have your own blog or website that doesn’t require so much work, maybe you can keep up with this lifestyle.

But what’s probably gonna happen most of the time is this. One table, several monitors, developers and mugs. That I can safely say is a much more common environment.

And these guys next to you are the ones who are probably part of your team. We often call teams by their names. Prometheus, BlueSky and Lions were some of the names of teams I’ve participated in.

If you think that in the first scenario you will be more productive or that you will be able to finish the job faster, you may be wrong.

Great teams can be more effective than all the individual skills combined.

Great teams can be more effective than all the individual skills combined. This is known as synergy.

But there is another side to the same coin.

Weak teams can be less effective than the least effective person on the team.

“One bad apple is enough to spoil the bunch”

Just make sure you’re not that apple.

Teams win or fail together

Regardless of the project you’re going to enter and the size of the team. The ultimate goal that should prevail is the collective goal, not the individual goal.

“Better to have one person working with you than three people working for you”

When members think they are in a competition or that individual success is enough, this team undoubtedly has a high chance of failure.

Talent wins games, but only teamwork wins championships.

Michel Jordan

When all team members have the same goals and failure or success is at the team level, not at the individual level the interest of each team member is converted to the interest of the group.

The contagious power of example

Your boss or company may have put you in a team where each member is rated individually and every “we’re in it together” attitude is hard to maintain.

Or, you can hear from the team members themselves something like this: “this is how we work better, it always worked out”. These are definitely teams that have never seen real teamwork in action.

This is a posture that can and must be changed. And it can start with you.

You can choose to show team spirit by slowing down to help a colleague, giving feedback or communicating the overall project status to the team.

Don’t just try to finish your activity as quickly as possible to “show service”. This is not a competition.

The influence of only one person’s example can be powerful.

Teamwork leads to learning

Each person has their own set of skills, strengths and weaknesses. When the whole team works together, people can also take the opportunity to learn from each other.

If you consider yourself the “last cookie in the package”, know that there will always be people who know more or at least have the same level of knowledge as yours.

A project that doesn’t challenge you or take you out of your comfort zone, maybe this is not the ideal project for you to evolve as a developer.

A challenging project will require all the help it needs. This is where teamwork comes in, and you have your chance to increase your portfolio of solutions.

If you’re the smart one at the table, you’re at the wrong table.

Different perspectives help find innovations

Simple as that, sometimes you know only one way to solve a problem, which is great, in the end you will solve the problem. But maybe that’s not the most efficient way.

If someone on your team has been through some similar problem and also knows how to solve it, maybe this is an excellent opportunity for you to learn something new.

If you want something new, you have to stop doing something old.

Peter F. Drucker

Botton line

Nothing great can be accomplished by just one person. A great idea may come from a single person, but putting it into practice requires a team.

As a developer and team member you can and should always:

• Express your opinion

As a developer you are the active part of the project, your opinion and solutions are valuable and you should always share them. And this not only shows that you are actively involved in the discussion, but also shows your concern for the good of the team and the project.

• Be ready to take one step further

If you want to be a good team member, you should always be ready to walk the team a little further. Helping in a task that is completely out of your scope is a great way to help the team finish the project. Not to mention that this kind of attitude will undoubtedly create strong bonds between you and the team members.

Recognise the individual effort of your colleagues, value the lessons learned. Value teamwork.

Signup for the newsletter and be notified when new content is released!