This document provides an overview of Agile and Scrum frameworks. It begins with introductions and then discusses what Agile is, comparing it to the traditional Waterfall model. Key aspects of Scrum like roles, meetings, events and artifacts are explained. The document argues that Agile is not just for software teams and discusses how Atlassian uses Agile to promote innovation through a culture that provides employees freedom, time, collaboration, funding and experimentation.
Report
Share
Report
Share
1 of 98
Download to read offline
More Related Content
Agile, not just for software
1. JOHN PAZ • IX WRITER • ATLASSIAN
Agile, not just for software
An explanation of Agile (and Scrum), and why it’s essential for innovation
5. John Paz
IX Writer
American Atlassian fanboy
From stuffy defence contractors to cutting
edge software producers.
Variety of experience
Worked on a wide variety of projects, from
military simulators to video games.
10 years working in tech
Been with Atlassian for 1.5 years, been a
fan of Atlassian for many more.
6. My Agile
experience
Agile in practice
Defense contractors.
My introduction to Agile
Two-weeks of training for the entire
company.
Anti-agile companies
Agile done right: doesn’t get in the way.
Agile done wrong: useless meetings,
unfocused project.
11. • Big cool statistic
• 2,56
9
• Add-Ons in Marketplace
12. • Big cool statistic
• 2,56
9
• Add-Ons in Marketplace
13. Waterfall
Change takes forever
The traditional, linear approach.
Segmented
One group of functional specialists
passes the baton to the next group.
Relay race
Change is inevitable, and traditional
waterfall makes it hard to adjust.
15. Origin
Every project phase must be
completed before the next can begin.
Agile manifesto (2001)
Reinforcement of big idea - use no
more than two lines of text here.
Waterfall (<2001)
17. • Big cool statistic
• 2,56
9
• Add-Ons in Marketplace
18. Responding to
change
Working software
(or product)
Individuals &
interactions
Agile: The Agile Manifesto (4 values)
Customer
collaboration
over comprehensive
documentation.
over process and tools. over following a plan.over contract negotiation.
19. Agile: The twelve Agile principles
1. Customer satisfaction by early and continuous delivery of valuable software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be trusted
6. Face-to-face conversation is the best form of communication (co-location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity—the art of maximizing the amount of work not done—is essential
11. Best architectures, requirements, and designs emerge from self-organizing teams
12. Regularly, the team reflects on how to become more effective, and adjusts accordingly
21. Origin
Scrum (2009)
Every project phase must be
completed before the next can begin.
Agile manifesto (2001)
Reinforcement of big idea - use no
more than two lines of text here.
Waterfall (<2001)
This text box is not intended to
contain a bunch of copy.
27. Scrum: Roles - Product owner
•Single person responsible for maximizing the ROI of the project
•Responsible for product vision
•Constantly re-prioritizes the Product Backlog, adjusting any longterm
expectations such as release plans
•Final arbiter of requirements questions
•Accepts or rejects each product increment
•Decides whether to ship
•Decides whether to continue development
•Considers stakeholder interests
•May contribute as a team member
28. Scrum: Roles - The Team
•Cross-functional, self-organizing / self-managing, without externally
assigned roles
•Negotiates commitments with the Product Owner, one Sprint at a time
•Has autonomy regarding how to reach commitments
•Intensely collaborative
•Most successful when located in one team room, particularly for the
first few Sprints
•Most successful with long-term, full-time membership. Scrum moves
work to a flexible learning team and avoids moving people or splitting
them between teams.
•3-9 members (originally 7 ± 2 members)
29. Scrum: Roles - (optional) Scrum Master
•Facilitates the Scrum process
•Helps resolve impediments
•Creates an environment conducive to team self-organization
•Captures empirical data to adjust forecasts
•Shields team from external interference and distractions
•Enforces timeboxes
•Keeps Scrum artifacts visible
•Promotes improved engineering practices
•Has no management authority over the team
•Not a coordinator
30. Scrum: Roles - (optional) Scrum Master
Anyone with authority over the team is by definition not its
ScrumMaster
31. Scrum: Roles - Stakeholders
•Anyone that has a stake in the outcome of the team.
•The ones who have desires, wants, and needs, and are the reason
the team is working on the project in the first place.
•The source of validation for the project.
•Hold the Product Owner accountable for the outcome of a project.
•Can be anyone within the company, but more than likely is a
manager, executive, business owner, or someone else responsible
for influencing outcomes.
33. Scrum: Meetings/Events - Sprints
•What is a Sprint?
•The heart of Scrum is a Sprint.
•An increment of work to achieve a specific goal (the Sprint Goal).
•Time-boxed (one month or less) during which a “Done”, useable, and
potentially releasable product increment is created.
•Have consistent durations throughout a development effort.
•New Sprints start immediately after the conclusion of a previous
Sprint.
•Sprints contain and consist of Sprint Planning, Daily Scrums (or
Standups), development work, Sprint Review, and Sprint
Retrospective.
34. Scrum: Meetings/Events - Sprints
•Why sprinting is useful:
•Sprints enable predictability by ensuring inspection and adaptation of
progress toward a Sprint Goal at least every calendar month.Time-
boxed (one month or less) during which a “Done”, useable, and
potentially releasable product increment is created.
•Sprints limit risk to one calendar month of cost.
•Each Sprint has a definition of what is to be built, a design and
flexible plan that will guide building it, the work, and the resultant
product. And, two sequential Sprints don’t have be concerned with
building the same thing.
35. Scrum: Meetings/Events - Sprint Planning
•Sprint Planning is done by the team (not just the Product Owner).
•Sprint Planning answers:
•What can be done this Sprint? This is the Sprint Goal.
•How will the work get done, and by whom?
•If the team determines it has too much or too little work, it may
renegotiate the selected Product Backlog items with the Product
Owner.
•Successful Sprint Planning produces a Sprint Goal, and subsequent
Sprint Backlog of work that will be accomplished when the Sprint is
over.
36. Scrum: Meetings/Events - Daily Standup
•The Daily Standup, or Daily Scrum, is:
•A 15-minute time-boxed event for the team to synchronize activities
and create a plan for the next 24 hours.
•For inspecting progress toward the Sprint Goal and to inspect how
progress is trending toward completing the work.
•Facilitated by a Scrum Master, who ensures people stay on track with
their updates.
37. Scrum: Meetings/Events - Daily Standup
•At every Standup, each team member answers 3 questions:
•What did you do yesterday?
•What will you do today?
•Is there anything impeding your progress?
Daily standups improve communication, eliminate other meetings,
identify impediments, highlight and promote quick decision-making, and
improve the team’s level of knowledge.
38. Scrum: Meetings/Events - Sprint Review
•Team + stakholders.
•A Sprint Review is held at the end of the Sprint to inspect the work
accomplished and adapt the Product Backlog if needed.
•The team demos the increment of work, if possible.
•The team and stakeholders collaborate about what was done in the
Sprint.
39. Scrum: Meetings/Events - Sprint Retrospective
•Team only.
•Occurs after the Sprint Review and prior to the next Sprint Planning
•An opportunity for the team to inspect itself and create a plan for
improvements to be enacted during the next Sprint.
•Create a plan for implementing improvements
42. Scrum: Artifacts - Product Backlog
•Owned by the Product Owner
•An ordered list of everything that might be needed in the product.
•The single source of requirements for any changes to be made to the
product.
•Evolves as the product and the environment evolves; it’s a living
document.
•Lists all features, functions, requirements, enhancements, and fixes
that constitute the changes to be made to the product in future
releases.
•Should be groomed by a Product Owner regularly.
44. Scrum: Artifacts - Sprint Backlog
•Owned by the Sprint Team.
•A set of Product Backlog items selected for the Sprint, plus a plan for
delivering the product Increment and realizing the Sprint Goal.
•Makes visible all of the work that the Development Team identifies as
necessary to meet the Sprint Goal.
•At any time, represents the summation of remaining work and work
accomplished for a given Sprint.
46. Scrum: Artifacts - Increment
•Owned by the Sprint Team.
•The sum of all the Product Backlog items completed during a Sprint.
•Must be in useable condition, regardless of whether the Product Owner
decides to actually use it.
•For research Sprints (called “Spikes”), the increment can be a
document that aggregates the findings. But, there should always be a
deliverable artifact as the result of a Sprint.
57. Importance
of Agile
Helps get shit done
Essential to develop new products
quickly and flexibly.
Increases engagement
Stimulates learning, encourages
experimentation, inspires
understanding.
Vital for innovation
Enhances accountability and team
communication.
62. Two types of
innovation
Providing more-effective products,
processes, services, technologies, or
business models to customers.
Creating new ideas
Generating ideas that can change
perceptions of what's possible. Game-
changing ideas that drive real growth.
Increasing efficiency
64. Two types of
innovation
Providing more-effective products,
processes, services, technologies, or
business models to customers.
Creating new ideas
Generating ideas that can change
perceptions of what's possible. Game-
changing ideas that drive real growth.
Increasing efficiency
72. Employees on the frontline are more likely to
come up with game-changing innovations
than senior executives.
HUGH MOLOTSI, “HIDDEN ASSETS”
“
”
73. 5 facets of
innovative work
environments
1. Freedom
2. Time
3. Collaborative culture and tools
4. Funding and support
5. A culture of experimentation
- Hugh Molotsi
Innovative workplace cultures provide employees with:
74. 5 facets of
innovative work
environments
Employees are given autonomy to
explore ideas they are passionate
about.
Freedom
- Hugh Molotsi
#1
75. 5 facets of
innovative work
environments
Employees are given self-directed
time, carved out from their day jobs,
to work on their own projects.
Time
- Hugh Molotsi
#2
76. 5 facets of
innovative work
environments
Employees can self-organize and
form teams across departments, with
tools that enable this collaboration
and help employees learn about what
other employees are working on.
Collaborative culture
and tools
- Hugh Molotsi
#3
77. 5 facets of
innovative work
environments
Things like resources, tools, training,
and mentoring to develop employee-
directed projects. And a formal
process to allow projects to
“graduate” to officially funded
initiatives.
Funding and support
- Hugh Molotsi
#4
78. 5 facets of
innovative work
environments
A safe workplace to share your ideas
is crucial; the ideal workplace is
where management decisions are
transparent, and the ideas of a
frontline employee can be tested
alongside ideas from senior leaders.
A culture of
experimentation
- Hugh Molotsi
#5
79. Be sure to check out Hugh and Jeff’s site
grassroots.guide
… and keep an eye out for their book.
80. 5 facets of
innovative work
environments
1. Freedom
2. Time
3. Collaborative culture and tools
4. Funding and support
5. A culture of experimentation
- Hugh Molotsi
Innovative workplace cultures provide employees with:
81. Our culture
As Atlassian grows
guide our business, our product
development, and our brand.
Our North Star
They're the rudder in our sailboat.
These values are what we look for in
every potential employee.
5 company values
these five values remain constant.
83. Atlassian embraces transparency
wherever practical, and sometimes
where impractical. All information,
both internal and external, is public by
default. We are not afraid of being
honest with ourselves, our staff and
our customers.
Open company,
no bullshit
85. Building with heart means really
caring about what we're making and
doing–it's a mission, not just a job.
When we build with balance we take
into account how initiatives and
decisions will affect our colleagues,
customers and stakeholders.
Build with heart
and balance
87. When we make internal decisions we
ask ourselves "how will this affect our
customers?" If the answer is that it
would 'screw' them, or make life more
difficult, then we need to find a better
way. We want the customer to
respect us in the morning.
Don't #@!% the
customer
89. We want all Atlassians to feel like
they work with Atlassian, not for
Atlassian. We think it's important to
have fun with your workmates while
working and contributing to the
Atlassian team.
Play, as a team
91. Gandhi had it pretty right when he
said "We need to be the change we
wish to see in the world". At Atlassian
we're constantly looking for ways to
improve our company, our products
and our environment.
Be the change you
seek
96. The (not so)
secret sauce:
Agile
Why Agile?
Agile is fluid
Lots of opportunities to change on the
fly.
Unpredictability - Acute market
changes, emerging technology, or
employee crises.
Every project aspect
the code, requirements, design, etc.
— is continually revisited throughout
the lifecycle.