AGILE 101

TODAY’S AGENDA

INTRODUCTION TO AGILE

DIFFERENCE BETWEEN ‘DOING’ AND ‘BEING’ AGILE

DIFFERENT FRAMEWORKS/METHODS/TECHNIQUES UNDER AGILE UMBRELLA

INTRODUCTION TO SCRUM

IMPLEMENTING/ADOPTING AGILE

TOOLS AVAILABLE FOR IMPLEMENTING AGILE

TARGET AUDIENCE

Scrum is the most used Agile methodology. The Agile Scrum

course is suitable for all professionals looking to keep their
knowledge up to date with the latest developments in the
fields of IT and Project Management, specifically those
participating in or leading projects. In particular, these
certifications are suitable for professionals working in an Agile
context and who have the ambition to facilitate a Scrum team
by assuming the role of a Scrum Master.
INTRODUCTION TO AGILE
WHAT IS AGILE?

It works by breaking projects down

Agile is a time boxed, iterative approach
into little bits of user functionality
to software delivery that builds software
called user stories prioritizing them,
incrementally from the start of the
and then continuously delivering
project, instead of trying to deliver it all
them in short up to 4 weeks cycles
at once near the end.
called ‘Sprints’ (iterations)
WHAT IS AGILE?

• The various agile methodologies share much of the same philosophy, as well as many of the same
characteristics and practices. But from an implementation standpoint, each has its own recipe of practices,
terminology, and tactics.
WATERFALL VS AGILE

WHAT IS WATERFALL METHODOLOGY? WHAT IS AGILE METHODOLOGY?

• Agile methodology is a practice that helps

• Waterfall Model methodology which is
continuous iteration of development and
also known as Liner Sequential Life Cycle
testing in the software development process.
Model. Waterfall Model followed in the
In this model, development and testing
sequential order, and so project
activities are concurrent, unlike the Waterfall
development team only moves to next
model. This process allows more
phase of development or testing if the
communication between customers,
previous step completed successfully.
developers, managers, and testers.
WATERFALL VS AGILE
WATERFALL VS AGILE
WATERFALL VS AGILE
AGILE PRINCIPLES

1 2 3
Our highest priority is to Welcome changing Deliver working software
satisfy the customer through requirements, even late in frequently, from a couple of
early and continuous delivery development. Agile processes weeks to a couple of months,
of valuable software. harness change for the with a preference to the
customer's competitive shorter timescale.
advantage.
AGILE PRINCIPLES

4 5 6
Business people Build projects around motivated The most efficient and effective
and developers individuals. method of conveying
must work together Give them the environment information to and within a
daily throughout and support they need, and development team is face-to-
the project. trust them to get the job done. face conversation.
AGILE PRINCIPLES

7 8 9
Working software is the Agile processes promote Continuous attention to
primary measure of progress. sustainable development. technical excellence and good
The sponsors, design enhances agility.
developers, and users
should be able to
maintain a constant
pace indefinitely.
AGILE PRINCIPLES

10 11 12

Simplicity--the art of The best architectures, At regular intervals, the team

maximizing the requirements, and designs reflects on how to become
more effective, then tunes and
amount of work not emerge from self-organizing
adjusts its behavior accordingly.
done--is essential. teams.
AGILE PRINCIPLES
SPEED TO MARKET:
Agile lets you get your concept to your users as quickly as possible. During every sprint an agile project delivers something of value.
At any point, you may determine you want to launch what has been delivered and start building a user base or testing your
hypothesis.

FLEXIBILITY:
Agile is based on accommodating change. Software projects consistently change. As a product comes to life or the market expands,
you should be able to react and update the product accordingly. Agile also realizes that great ideas are bound to come mid-project
and being locked into a scope doesn’t let you take advantage of these realizations.
BENEFITS OF AGILE
RISK MANAGEMENT:
Incremental releases means that the product can be used early in the process by stakeholders and users. This lets you identify issues
and
feature deficits early in the process. Being adaptable to change means it isn’t a problem to change the scope midway
through the project, something that would be impossible in a waterfall style project.

COST CONTROL:
Unlike a fixed budget project, agile is flexible with regard to scope. More often than not, our clients realize features they originally
requested are no longer necessary. This allows them to launch sooner and pay less. Agile isn’t about paying a lot with uncertainty, it’s
about paying for only what you need. Need to stick within a budget? No problem! We can rearrange the product backlog so that
critical new features are implemented at the expense of less important features, not your budget.
BENEFITS OF AGILE
QUALITY:
Agile integrates testing throughout the process. Consistently delivering tested software means higher overall quality and less
time spent on QAing the full application.

RIGHT PRODUCT:
Incremental releases let you test your product early and often. Even if you don’t release it to the public, it’s much easier to locate
flaws and things that can be improved when you have an actual product to play with vs a series of designs.

TRANSPARENCY:
Agile lets you see, feel and use a project consistently throughout the project. You don’t see things in compartmentalized silos; you see
how things work together
AGILE WAY OF THINKING
THE AGILE: SCRUM FRAMEWORK AT GLANCE
WHAT IS SCRUM?

Definition of Scrum
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively
delivering products of the highest possible value.
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master

Scrum is a process framework that has been used to manage complex product
development since the early 1990s.
SCRUM THEORY

Scrum is founded on empirical process control theory, or empiricism. Empiricism

asserts that knowledge comes from experience and making decisions based on
what is known. Scrum employs an iterative, incremental approach to optimize
predictability and control risk.

Three pillars uphold every implementation of empirical process control:

Transparency Inspection Adaptation.

THREE PILLARS

Transparency Inspection Adaptation

• Scrum users must frequently inspect • If an inspector determines that one or

• Significant aspects of the process Scrum artifacts and progress toward a more aspects of a process deviate
must be visible to those responsible Sprint Goal to detect undesirable outside acceptable limits, and that
for the outcome. Transparency variances. Their inspection should not the resulting product will be
requires those aspects be defined by be so frequent that inspection gets in unacceptable, the process or the
a common standard so observers the way of the work. Inspections are material being processed must be
share a common understanding of most beneficial when diligently adjusted. An adjustment must be
what is being seen. performed by skilled inspectors at the made as soon as possible to minimize
point of work. further deviation.
SCRUM VALUES

‘CFORC’
Commitment
Courage
Focus
Openness and
Respect

When these values are embodied and lived by the Scrum Team, the Scrum pillars of transparency,
inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn
and explore those values as they work with the Scrum events, roles and artifacts.
SCRUM ROLES
ORGANIZATION – ROLE SUMMARY
THE SCRUM TEAM

• Product Owner
The Scrum Team consists of a • The Development Team, and
• A Scrum Master

Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work,
rather than being directed by others outside the team. Cross-functional teams have all competencies needed to
accomplish the work without depending on others not part of the team. The team model in Scrum is designed to
optimize flexibility, creativity, and productivity.

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries
of “Done” product ensure a potentially useful version of working product is always available
THE PRODUCT OWNER

• The Product Owner is responsible for maximizing the value of the product and the work of the
Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
• The Product Owner is the sole person responsible for managing the Product Backlog.

Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Optimizing the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum
Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed
THE PRODUCT OWNER

• The Product Owner may do the above work, or have the Development Team do it.
However, the Product Owner remains accountable.

• The Product Owner is one person, not a committee. The Product Owner may represent the desires
of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s
priority must address the Product Owner.

• For the Product Owner to succeed, the entire organization must respect his or her decisions. The
Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is
allowed to tell the Development Team to work from a different set of requirements, and the
Development Team isn’t allowed to act on what anyone else says.
THE DEVELOPMENT TEAM
Development Teams have the following characteristics:

• They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to
turn Product Backlog into Increments of potentially releasable functionality;
• Development Teams are cross functional, with all of the skills as a team necessary
to create a product Increment
• Scrum recognizes no titles for Development Team members other than Developer, regardless of the
work being performed by the person; there are no exceptions to this rule;
• Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need
to be addressed like testing or business analysis; there are no exceptions to this rule; and,
• Individual Development Team members may have specialized skills and areas of focus, but
accountability belongs to the Development Team as a whole
THE DEVELOPMENT TEAM

• Optimal Development Team size is small enough to remain nimble and large enough to complete significant
work within a Sprint. Fewer than three Development Team members decrease interaction and results in smaller
productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the
Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members
requires too much coordination. Large Development Teams generate too much complexity for an empirical
process to manage. The Product Owner and Scrum Master roles are not included in this count unless they are
also executing the work of the Sprint Backlog.

• The Development Team consists of professionals who do the work of delivering a potentially releasable
Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the
Increment.

• Development Teams are structured and empowered by the organization to organize and manage their own
work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.
THE SCRUM MASTER

• The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters
do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules
• The Scrum Master is a servant-leader for the Scrum Team.
• The Scrum Master helps those outside the Scrum Team understand which of their
interactions with the Scrum Team are helpful and which aren’t.
• The Scrum Master helps everyone change these interactions to maximize the value created by the
Scrum Team.
• Attributes of a Good Scrum Master:
Responsible Humble
Collaborative
Committed Influential
Knowledgeable
EVENTS IN SCRUM

• Scrum prescribes four formal events for inspection and adaptation

✓ Sprint Planning
✓ Daily Scrum
✓ Sprint Review
✓ Sprint Retrospective
TIME BOXING
THE SPRINT

• Each Sprint may be considered a project with

no more than a one-month horizon. Like
projects, Sprints are used to accomplish
something. 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.
• Sprints are limited to one calendar month.
When a Sprint’s horizon is too long the
definition of what is being built may change,
complexity may rise, and risk may increase.
Sprints enable predictability by ensuring
inspection and adaptation of progress toward
a Sprint Goal at least every calendar month.
Sprints also limit risk to one calendar month of
cost.
THE SPRINT
• The heart of Scrum is a Sprint, a time-box of one month or
less during which a “Done”, useable, and potentially
releasable product Increment is created. Sprints best have
consistent durations throughout a development effort. A new
Sprint starts immediately after the conclusion of the previous
Sprint.
• Sprints contain and consist of the Sprint Planning, Daily Scrums, the
development work, the Sprint Review, and the Sprint
Retrospective.

• During the Sprint:

• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the Product
Owner and Development Team as more is learned.
SPRINT PLANNING
• The work to be performed in the Sprint is planned at the Sprint Planning. This plan is
created by the collaborative work of the entire Scrum Team.

• Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches the
Scrum Team to keep it within the time-box.

• Sprint Planning answers the following:

• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?
DAILY SCRUM
• The Daily Scrum is a 15-minute time-boxed event for the Development
Team to synchronize activities and create a plan for the next 24 hours. This
is done by inspecting the work since the last Daily Scrum and forecasting
the work that could be done before the next one. The Daily Scrum is held
at the same time and place each day to reduce complexity. During the
meeting, the Development Team members explain:

• What did I do yesterday that helped the Development Team meet the
Sprint Goal?
• What will I do today to help the Development Team meet the Sprint
Goal?
• Do I see any impediment that prevents me or the
Development Team from meeting the Sprint Goal?
SPRINT REVIEW

• A Sprint Review is held at the end of the Sprint to inspect the

Increment and adapt the Product Backlog if needed. During the
Sprint Review, the Scrum Team and stakeholders collaborate
about what was done in the Sprint. Based on that and any
changes to the Product Backlog during the Sprint, attendees
collaborate on the next things that could be done to optimize
value.

• This is a four-hour time-boxed meeting for one-month Sprints

SPRINT RETROSPECTIVE

• The Sprint Retrospective is an opportunity for the Scrum Team

to inspect itself and create a plan for improvements to be
enacted during the next Sprint.
• The Sprint Retrospective occurs after the Sprint Review and
prior to the next Sprint Planning. This is a three-hour time-
boxed meeting for one-month Sprints
• The purpose of the Sprint Retrospective is to:
• Inspect how the last Sprint went with regards to people,
relationships, process, and tools;
• Identify and order the major items that went well and potential
improvements;
and,
• Create a plan for implementing improvements to the way the
Scrum Team does its work.
SCRUM ARTIFACTS

• Scrum’s artifacts represent work or value to provide

transparency and opportunities for inspection and
adaptation. Artifacts defined by Scrum are specifically
designed to maximize transparency of key information so that
everybody has the same understanding of the artifact.

A. Product Backlog
B. Sprint Backlog
C. Potentially shippable Increment
D. Definition of “Done”
PRODUCT BACKLOG

• The Product Backlog is an ordered list of everything that

might be needed in the product and is the single source of
requirements for any changes to be made to the product. The
Product Owner is responsible for the Product Backlog,
including its content, availability, and ordering.

• The Product Backlog lists all features, functions, requirements,

enhancements, and fixes that constitute the changes to be
made to the product in future releases. Product Backlog items
have the attributes of a description, order, estimate and value

• Higher ordered Product Backlog items are usually clearer and

more detailed than lower ordered ones. More precise
estimates are made based on the greater clarity and
increased detail; the lower the order, the less detail
SPRINT BACKLOG
• The Sprint Backlog is the set of Product Backlog items selected
for the Sprint, plus a plan for delivering the product Increment
and realizing the Sprint Goal. The Sprint Backlog is a forecast by
the Development Team about what functionality will be in
the next Increment and the work needed to deliver that
functionality into a “Done”Increment.

• The Sprint Backlog makes visible all of the work that

the Development Team identifies as necessary to
meet the Sprint Goal.

• The Sprint Backlog is a plan with enough detail that changes in

progress can be understood in the Daily Scrum. The
Development Team modifies the Sprint Backlog throughout the
Sprint, and the Sprint Backlog emerges during the Sprint. This
emergence occurs as the Development Team works through the
plan and learns more about the work needed to achieve the
Sprint Goal
POTENTIALLY SHIPPABLE INCREMENT
• The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous
Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum
Team’s definition of “Done.” It must be in useable condition regardless of whether the Product Owner decides to actually release it.
DEFINITION OF “DONE”
• When a Product Backlog item or an Increment is described as “Done”, everyone
must understand what “Done” means. Although this varies significantly per Scrum Team,
members must have a shared understanding of what it means for work to be complete, to
ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess
when work is complete on the product Increment.

• The same definition guides the Development Team in knowing how many Product Backlog
items it can select during a Sprint Planning. The purpose of each Sprint is to deliver Increments
of potentially releasable functionality that adhere to the Scrum Team’s current definition of
“Done.” Development Teams deliver an Increment of product functionality every Sprint. This
Increment is useable, so a Product Owner may choose to immediately release it. If the
definition of "done" for an increment is part of the conventions, standards or guidelines of the
development organization,
DOING ‘AGILE’ & ‘BEING’ AGILE
DOING AGILE VS BEING AGILE
DOING AGILE VS BEING AGILE

• Doing Agile can be learned in a 2-3 day class that teaches the basics of Scrum and Kanban.
Being Agile requires much more: a cultural shift to an agile mindset as well as changes to the
way employees are managed, motivated, trained and hired.

• Doing Agile by itself leads to certain benefits: improved communication and visibility to what
each team member is working on, some increases in productivity and perhaps the ability to set
priorities with intent as conditions change.

• But the transformative benefits occur from Being Agile, by which we mean
consistently, predictably responding quickly in the face of change, delighting customers
and achieving excellence through engaged employees all working together towards
common goals.
JOURNEY TOWARDS ‘BEING AGILE’

• Self-organizing Teams
• The ability for a team to self-organize around the goals it has been given is fundamental to all
agile methodologies, including Scrum. In fact, the Agile Manifesto includes self-organizing
teams as a key principle, saying that “the best architectures, requirements, and designs
emerge from self-organizing teams.”
• "Self-organizing teams choose how best to accomplish their work, rather than being directed
by others outside the team.” "Development Teams are structured and empowered by the
organization to organize and manage their own work." "Development Teams have the
following characteristics: They are self-organizing. No one (not even the Scrum Master) tells
the Development Team how to turn Product Backlog into Increments of potentially releasable
functionality"
USER STORIES,MONITORING
USER STORIES
INFORMATION RADIATORS

• Information Radiators:
• The purpose of information radiators is to
help keep the team focused on what really
needs their attention and to promote
transparency.
• Information Radiators makes information
visible
• Examples: Burndown Charts/Kanban Board
etc…
KANBAN BOARD
TOOLS AVAILABLE FOR
IMPLEMENTING AGILE
TOOLS TO CULTIVATE AGILE METHODOLOGY IN
YOUR ORGANIZATION

• Trello. Trello is one of the most widely-used

project management tools that is popular for
its simple UI and feasible usability. ...
• Visual Studio Team Services (VSTS) ...
• Jira. ...
• Axosoft. ...
• Asana. ...
• Zoho Sprints. ...
• Wrike.
• Kanbanize
KANBANIZE
 OTHER AGILE
FRAMEWORKS
 Devops

OTHER AGILE FRAMEWORKS Lean

Agile
SCRUM

ATern
AGILREMEMBER OTHER FRAMEWORKS AND METHODOLOGIES: LEAN,
DSDM, DEVOPS, ITIL, CMM ETC…

Scrum: A framework within which people can address complex adaptive

problems, while productively and creatively delivering products of the highest
possible value.

Scrum is:
• Lightweight
• Simple to understand
• Difficult to master
DevOps

• The word DevOps is a contraction of ‘Development’ and ‘Operations’.

• DevOps combines a highly automated, repeatable, and testable Continuous Delivery framework with a
unified team that extends through the full lifecycle of delivering capabilities to production. With a
DevOps approach, we can take small batches of requirements quickly from concept to deployment,
monitor the results, and use what we learn to change the product and the process.
• DevOps is commonly recognized to be primarily about creating a culture of effective and seamless
collaboration but this is often the hardest piece to enact when it involves changing an existing culture
(as opposed to creating a culture from scratch in a startup type environment and having the luxury of
hiring individuals with certain mindsets and defining working practices from day one).
CMM

• CMM is a framework that describes practices that an organization employs in developing software.
CMM consists of five levels, numbered 1 through 5.
• Level 1 (immature organization) means that the organization doesn’t have any defined, repeatable, or
improvable approach to building software; basically, developers hack their way to a solution. At level 5
(mature organization), an organization has a defined, repeatable, and improvable set of practices for
developing software. At each level, the practices that should be employed are defined as Key Practice
Areas (KPAs). If an organization believes that it has thoroughly implemented the KPAs for a specific level,
it can engage someone who has been certified by SEI to assess this. If the organization is compliant, it is
so certified. Certification is a big deal, because some companies and
governmental agencies won’t hire any professional services firm that isn’t certified to at least
CMM level 3.
THANK YOU
62