What is the Agile methodology?
The Agile methodology is a project management approach that involves
breaking the project into phases and emphasizes continuous collaboration
and improvement. Teams follow a cycle of planning, executing, and
evaluating. Whereas the traditional "waterfall" approach has one discipline
contributing to the project, then "throwing it over the wall" to the next
contributor, agile calls for collaborative cross-functional teams. Open
communication, collaboration, adaptation, and trust amongst team members
are at the heart of agile. Although the project lead or product owner typically
prioritizes the work to be delivered, the team takes the lead on deciding how
the work will get done, self-organizing around granular tasks and
assignments.
Agile isn't defined by a set of ceremonies or specific development techniques.
Rather, agile is a group of methodologies that demonstrate a commitment to
tight feedback cycles and continuous improvement.
Why choose agile?
Teams choose agile so they can respond to changes in the marketplace or
feedback from customers quickly without derailing a year's worth of plans.
"Just enough" planning and shipping in small, frequent increments lets your
team gather feedback on each change and integrate it into future plans at
minimal cost.
What is scrum?
Scrum is an agile project management framework that helps teams structure
and manage their work through a set of values, principles, and practices.
Much like a rugby team (where it gets its name) training for the big game,
scrum encourages teams to learn through experiences, self-organize while
working on a problem, and reflect on their wins and losses to continuously
improve.
While the scrum I’m talking about is most frequently used by software
development teams, its principles and lessons can be applied to all kinds of
teamwork. This is one of the reasons scrum is so popular. Often thought of as
an agile project management framework, scrum describes a set of meetings,
tools, and roles that work in concert to help teams structure and manage their
work.
Agile vs. scrum
People often think scrum and agile are the same thing because scrum is
centered around continuous improvement, which is a core principle of agile.
However, scrum is a framework for getting work done, whereas agile is a
philosophy. The agile philosophy centers around continuous incremental
improvement through small and frequent releases. You can’t really “go agile”,
as it takes dedication from the whole team to change the way they think about
delivering value to your customers. But you can use a framework like scrum to
help you start thinking that way and to practice building agile principles into
your everyday communication and work.
The difference between agile and the definition of scrum can be found in the
Scrum guide and the Agile manifesto. The Agile manifesto outlines four
values:
● Individuals and interactions over processes and tools
● Working software over comprehensive documentation
● Customer collaboration over contract negotiation
● Responding to change over following a plan
The definition of scrum is based on empiricism and lean thinking. Empiricism
says that knowledge comes from experience and that decisions are made
based on what is observed. Lean thinking reduces waste and focuses on
essentials. The scrum framework is heuristic; it’s based on continuous
learning and adjustment to fluctuating factors. It acknowledges that the team
doesn’t know everything at the start of a project and will evolve through
experience. Scrum is structured to help teams naturally adapt to changing
conditions and user requirements, with re-prioritization built into the process
and short release cycles so your team can constantly learn and improve.
The scrum framework
The scrum framework outlines a set of values, principles, and practices that
scrum teams follow to deliver a product or service. It details the members of a
scrum team and their accountabilities, “artifacts” that define the product and
work to create the product, and scrum ceremonies that guide the scrum team
through work.
Members of a scrum team
A scrum team is a small and nimble team dedicated to delivering committed
product increments. A scrum team’s size is typically small, at around 10
people, but it’s large enough to complete a substantial amount of work within
a sprint. A scrum team needs three specific roles: product owner, scrum
master, and the development team. And because scrum teams are
cross-functional, the development team includes testers, designers, UX
specialists, and ops engineers in addition to developers.
The scrum product owner
Product owners are the champions for their product. They are focused on
understanding business, customer, and market requirements, then prioritizing the work
to be done by the engineering team accordingly. Effective product owners:
● Build and manage the product backlog.
● Closely partner with the business and the team to ensure everyone understands
the work items in the product backlog.
● Give the team clear guidance on which features to deliver next.
● Decide when to ship the product with a predisposition towards more frequent
delivery.
The product owner is not always the product manager. Product owners focus on
ensuring the development team delivers the most value to the business. Also, it's
important that the product owner be an individual. No development team wants mixed
guidance from multiple product owners.
The scrum master
Scrum masters are the champions of scrum within their teams. They coach teams,
product owners, and the business on the scrum process, and look for ways to fine-tune
their practice of it.
An effective scrum master deeply understands the work being done by the team and
can help the team optimize their transparency and delivery flow. As the
facilitator-in-chief, he/she schedules the needed resources (both human and logistical)
for sprint planning, stand-up, sprint review, and the sprint retrospective.
The scrum development team
Scrum teams get s*%& done. They are the champions for sustainable development
practices. The most effective scrum teams are tight-knit, co-located, and usually five to
seven members. One way to work out the team size is to use the famous ‘two pizza
rule’ coined by Jeff Bezos, the CEO of Amazon (the team should be small enough to
share two pizzas).
Team members have differing skill sets, and cross-train each other so no one person
becomes a bottleneck in the delivery of work. Strong scrum teams are self-organizing
and approach their projects with a clear ‘we’ attitude. All members of the team help one
another to ensure a successful sprint completion.
The scrum team drives the plan for each sprint. They forecast how much work they
believe they can complete over the iteration using their historical velocity as a guide.
Keeping the iteration length fixed gives the development team important feedback on
their estimation and delivery process, which in turn makes their forecasts increasingly
accurate over time.
Scrum artifacts
Scrum artifacts are important information used by the scrum team that helps define the
product and what work to be done to create the product. There are three artifacts in
scrum: product backlog, a sprint backlog, and an increment with your definition of
“done”. They are the three constants a scrum team should reflect on during sprints and
over time.
● Product Backlog is the primary list of work that needs to get done and maintained
by the product owner or product manager. This is a dynamic list of features,
requirements, enhancements, and fixes that acts as the input for the sprint
backlog. It is, essentially, the team’s “To Do” list. The product backlog is
constantly revisited, re-prioritized and maintained by the Product Owner
because, as we learn more or as the market changes, items may no longer be
relevant or problems may get solved in other ways.
● Sprint Backlog is the list of items, user stories, or bug fixes, selected by the
development team for implementation in the current sprint cycle. Before each
sprint, in the sprint planning meeting (which we’ll discuss later in the article) the
team chooses which items it will work on for the sprint from the product backlog.
A sprint backlog may be flexible and can evolve during a sprint. However, the
fundamental sprint goal – what the team wants to achieve from the current sprint
– cannot be compromised.
● Increment (or Sprint Goal) is the usable end-product from a sprint. At Atlassian,
we usually demonstrate the “increment” during the end-of-sprint demo, where the
team shows what was completed in the sprint. You may not hear the word
“increment” out in the world, as it’s often referred to as the team’s definition of
“Done”, a milestone, the sprint goal, or even a full version or a shipped epic. It
just depends on how your teams defines “Done” and how you define your sprint
goals. For example, some teams choose to release something to their customers
at the end of every sprint. So their definition of ‘done’ would be ‘shipped’.
However, this may not be realistic of other types of teams. Say you work on a
server-based product that can only ship to your customers every quarter. You
may still choose to work in 2-week sprints, but your definition of ‘done’ may be
finishing part of a larger version that you plan to ship together. But of course, the
longer it takes to release software, the higher the risk that software will miss the
mark.
As you can tell, there are lots of variations, even within artifacts, that your team can
choose to define. That’s why it’s important to be remain open to evolving how you
maintain even your artifacts. Perhaps your definition of ‘done’ provides undo stress on
your team, and you need to go back and pick a new definition.
Scrum ceremonies or events
The scrum framework includes scrum practices, ceremonies, and meetings that scrum
teams perform on a regular basis. The agile ceremonies are where we see the most
variations for teams. For example, some teams find doing all of these ceremonies
cumbersome and repetitive, while others use them as a necessary check-in. Our advice
is to start out using all of the ceremonies for two sprints and see how it feels. You can
then perform a quick retro and see where you might need to adjust.
Below is a list of all the key ceremonies a scrum team might partake in:
Organize the backlog: Sometimes known as backlog grooming, this event is the
responsibility of the product owner. The product owner’s main jobs are to drive
the product towards its product vision and have a constant pulse on the market
and the customer. Therefore, he/she maintains this list using feedback from
users and the development team to help prioritize and keep the list clean and
ready to be worked on at any given time. You can read more about maintaining a
healthy backlog here.
Sprint planning: The work to be performed (scope) during the current sprint is
planned during this meeting by the entire development team. This meeting is led
by the scrum master and is where the team decides on the sprint goal. Specific
user stories are then added to the sprint from the product backlog. These stories
always align with the goal and are also agreed upon by the scrum team to be
feasible to implement during the sprint.
At the end of the planning meeting, every scrum member needs to be clear on
what can be delivered in the sprint and how the increment can be delivered.
Sprint: A sprint is the actual time period when the scrum team works together to
finish an increment. Two weeks is a pretty typical length for a sprint, though some
teams find a week to be easier to scope or a month to be easier to deliver a
valuable increment. Dave West, from Scrum.org advises that the more complex
the work and the more unknowns, the shorter the sprint should be. But it’s really
up to your team, and you shouldn’t be afraid to change it if it’s not working!
During this period, the scope can be re-negotiated between the product owner
and the development team if necessary. This forms the crux of the empirical
nature of scrum.
All the events — from planning to retrospective — happen during the sprint.
Once a certain time interval for a sprint is established, it has to remain consistent
throughout the development period. This helps the team learn from past
experiences and apply that insight to future sprints.
Daily scrum or stand up: This is a daily super-short meeting that happens at the
same time (usually mornings) and a place to keep it simple. Many teams try to
complete the meeting in 15 minutes, but that’s just a guideline. This meeting is
also called a ‘daily stand-up’ emphasizing that it needs to be a quick one. The
goal of the daily scrum is for everyone on the team to be on the same page,
aligned with the sprint goal, and to get a plan out for the next 24 hours.
The stand up is the time to voice any concerns you have with meeting the sprint
goal or any blockers.
A common way to conduct a stand up is for every team member to answer three
questions in the context of achieving the sprint goal:
• What did I do yesterday?
• What do I plan to do today?
• Are there any obstacles?
However, we’ve seen the meeting quickly turn into people reading from their
calendars from yesterday and for the next day. The theory behind the stand up is
that it keeps distracting chatter to a daily meeting, so the team can focus on the
work for the rest of the day. So if it turns into a daily calendar read-out, don’t be
afraid to change it up and get creative.
Sprint review: At the end of the sprint, the team gets together for an informal
session to view a demo of, or inspect, the increment. The development team
showcases the backlog items that are now ‘Done’ to stakeholders and
teammates for feedback. The product owner can decide whether or not to
release the increment, although in most cases the increment is released.
This review meeting is also when the product owner reworks the product backlog
based on the current sprint, which can feed into the next sprint planning session.
For a one-month sprint, consider time-boxing your sprint review to a maximum of
four hours.
Sprint retrospective: The retrospective is where the team comes together to
document and discuss what worked and what didn’t work in a sprint, a project,
people or relationships, tools, or even for certain ceremonies. The idea is to
create a place where the team can focus on what went well and what needs to
be improved for the next time, and less about what went wrong.
Scrum values
In 2016, five scrum values were added to the Scrum Guide. These values provide
direction toward work, actions, and the behavior of the scrum team. They are
considered essential to a scrum team’s success.
Commitment
Because scrum teams are small and agile, each team member plays a significant role in
the team’s success. Therefore, each team member should agree to commit to
performing tasks they can complete and not overcommit. There should be frequent
communication regarding work progress, often in stand-ups.
Courage
Courage for a scrum team is simply the bravery to question the status quo or anything
that hampers its ability to succeed. Scrum team members should have the courage, and
feel safe enough, to try new things. A scrum team should have the courage and feel
safe to be transparent about roadblocks, project progress, delays, and so on.
Focus
At the heart of the workflow for scrum teams is the sprint, a focused and specified
period of time where the team completes a set amount of work. The sprint provides
structure but also focus to complete the planned amount of work.
Openness
The daily stand-up fosters an openness that allows teams to talk openly about work in
progress and blockers. At Atlassian we often have our scrum teams address these
questions:
● What did I work on yesterday?
● What am I working on today?
● What issues are blocking me?
This helps to highlight progress and identify blockers. It also helps to strengthen the
team when everyone shares progress.
Respect
The strength of an agile team lies in its collaboration and recognizing that each team
member contributes to work in a sprint. They celebrate each other’s accomplishments
and are respectful to one another, the product owner, stakeholders, and the scrum
master.
Scrum, kanban, and agile
Scrum is such a popular agile framework that scrum and agile are often misunderstood
to be the same thing. But there are other frameworks, like kanban, which is a popular
alternative. Some companies even choose to follow a hybrid model of scrum and
kanban, which has acquired the name of "Scrumban" or "Kanplan," which is Kanban
with a backlog.
Both scrum and kanban use visual methods such as the scrum board or kanban board
to track the progress of work. Both emphasize efficiency and splitting complex tasks into
smaller chunks of manageable work, but their approaches towards that goal are
different.
Scrum focuses on smaller, fixed-length iterations. Once the time period for a sprint is
finalized, the stories or product backlog entries that can be implemented during this
sprint cycle are then determined. In kanban, however, the number of tasks or the work
in progress (WIP limit) to be implemented in the current cycle is fixed at first. The time
taken to implement these features is then calculated backward.
Kanban is not as structured as scrum. Other than the WIP limit, it is fairly open to
interpretation. Scrum, however, has several categorical concepts enforced as part of its
implementation such as sprint review, retrospective, daily scrum, etc. It also insists on
cross-functionality, which is the ability of a scrum team to not depend on external
members to achieve their goals. Putting together a cross-functional team is not
straightforward. In that sense, kanban is easier to adapt whereas scrum can be
considered as a fundamental shift in the thought process and functioning of a
development team.
Getting started with scrum
The scrum framework itself is simple. The rules, artifacts, events, and roles are easy to
understand. Its semi-prescriptive approach actually helps remove the ambiguities in the
development process, while giving sufficient space for companies to introduce their
individual flavor to it.
The organization of complex tasks into manageable user stories makes it ideal for
difficult projects. Also, the clear demarcation of roles and planned events ensure that
there is transparency and collective ownership throughout the development cycle. Quick
releases keep the team motivated and the users happy as they can see progress in a
short amount of time.
However, scrum could take time to fully understand, especially if the development team
is acclimatized to a typical waterfall model. The concepts of smaller iterations, daily
scrum meetings, sprint reviews, and identifying a scrum master could be a challenging
cultural shift for a new team.
