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.
While scrum is structured, it is not entirely rigid. Its execution can be
tailored to the needs of any organization. There are many theories
about how exactly scrum teams must work in order to be successful.
However, after more than a decade of helping agile teams get work
done at Atlassian, we’ve learned that clear communication,
transparency, and a dedication to continuous improvement should
always remain at the center of whatever framework you choose.
And the rest is up to you.
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.
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
"Kanban," 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.
What is Scrum of Scrums?
Scrum of Scrums is a scaled agile technique that offers a way to connect
multiple teams who need to work together to deliver complex solutions.
It helps teams develop and deliver complex products through transparency,
inspection, and adaptation, at scale. It’s particularly successful when all high-
performing scrum team members work towards a common goal, have
trust, respect, and are completely aligned.
The purpose of Scrum of Scrums
A Scrum of Scrums is a virtual team consisting of delegates with embedded
links to the originating delivery teams. Compared to typical organizational
hierarchies or project-based teams, these interlinking team structures reduce
communication paths. The aim is to coordinate smaller, independent teams.
Teams who apply Scrum of Scrums not only coordinate delivery, but ensure
a fully integrated product at the end of every sprint. Therefore, Scrum of
Scrums acts as a release team that delivers value to customers.
Organizations typically use this approach as a first step to scale agile and
organize delivery of larger and complex products.
Scrum of Scrums - the scaled structure
The newly formed Scrum of Scrums team applies nearly the same practices,
participates in the same events, and has the same roles as a Scrum team. To
deliver an integrated, potentially shippable product at the end of every
sprint, additional roles might be required, like architects or quality assurance
leaders.
For instance, there is the Chief Product Owner role. The chief product owner
is responsible for overseeing the product owner team and helping to guide
the overarching product vision.
This role doesn't need to be performed by a dedicated person and the role
should have the same responsibilities as a product owner, just at scale.
Another new role is the Scrum of Scrum Master, who should focus on
progress and impediment backlogs visible to other teams, facilitating
prioritization or removal of impediments and continuously improving the
effectiveness of the Scrum of Scrums.
These new roles use the 15 minutes scaled daily scrum as a key meet-up
align, improve and tackle impediments. A representative of each team or the
product owner should discuss team impediments, risks to achieving the
sprint goal or dependencies on other teams followed by discovered
improvements that can be leveraged by other teams.
When teams are ready, here are some considerations that may be useful:
Keep the scaled daily scrum meeting to 15 minutes, mirroring your
team daily scrum
Conduct the scaled daily scrum for 15 minutes after the last team daily
scrum
Establish a working agreement for the Scrum of Scrums
Agree on the collective and individual definition of completed, and of
course, share it!
Establish a routine or agenda to keep the scaled daily scrum focused
Start tracking the number of days you're blocked by impediments
Track how many scaled daily scrums were started and finished on time
Focus on delivering stories that have dependencies first to reduce risk
and enable other teams
Track and visualize the days until the demo meeting
Truth be told, there’s no right way to scale agile. But many organizations
have had great success evolving their processes, teams, and cultures using
frameworks for scaling agile. Learn more about the top scaled agile
frameworks used today and more in the Agile at Scale section of the Agile
Coach.
Roadmaps
A product roadmap outlines how a product or solution develops over time. A
roadmap in agile development provides important context that empowers
teams to reach both incremental and project-wide goals. Roadmaps are
composed of initiatives, which are large areas of functionality, and include
timelines that communicate when a feature will be available. As the work
proceeds and teams learn more, it's accepted that the roadmap will change
to reflect that new information - possibly in subtle or broad ways. The goal is
to keep the roadmap focused on current conditions that impact the project
and long-term goals in order to effectively work with stakeholders and
respond to the competitive landscape.
Requirements
Each initiative in the roadmap breaks down into a set of requirements. Agile
requirements are lightweight descriptions of required functionality, rather
than the 100-page documents associated with traditional projects. They
evolve over time and capitalize on the team's shared understanding of the
customer and the desired product. Agile requirements remain lean while
everyone on the team develops a shared understanding via ongoing
conversation and collaboration. Only when implementation is about to begin
are they fleshed out with full details.
Agile runs on trust
Agile processes cannot function without a high level of trust amongst team
members and therefore create trust. It requires candor to have difficult
conversations regarding what's right for the program and the product.
Because conversations happen at regular intervals, ideas and concerns are
regularly expressed. That means team members need to be confident in
each other's ability (and willingness) to execute on the decisions made
during those conversations.
