Why Agile

Why Agile?Why Agile?Why Agile?Why Agile?
Context and BackgroundContext and Background
19-Jan-09 1®2009 Entinex, Inc. ***PROPRIETARY*** ALL RIGHTS RESERVED

TopicsTopics
The Agile Manifesto Typical Agile Conceptsg
Perceptions/Abuse of
CMMI
yp g p
Scrum In a Nutshell
RolesCMMI
Correct Understanding
Models
Roles
Components
Models
Assumptions
Sprints in Detail
Management Tools
Overlap
Over-Optimization
g
Development Activities
Over Optimization

Agile ManifestoAgile Manifesto
“We are uncovering better ways of developing software
by doing it and helping others do it.
Through this work we have come to value:
individuals and interactions over processes and tools
ki ft h i d t tiworking software over comprehensive documentation
customer collaboration over contract negotiation
That is while there is value in the items on the right
responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.”

Perception/Abuse of CMMIPerception/Abuse of CMMI
CMMIE i ti P CMMIExisting Processes

Correct UnderstandingCorrect Understanding
CMMI is a Model FRAMEWORK for building process
improvement systems…
Not a standard
Not a life-cycle
Improvement vs ComplianceImprovement vs. Compliance
Description vs. Prescription
d l f b f hA model for business process improvement for the
management of development processes
Appraisal looks for evidence that a model has been
followed.

How we use ModelsHow we use Models
15 April 2008 6®2008 Entinex, Inc. ***PROPRIETARY*** ALL RIGHTS RESERVED

Assumptions & ApproachAssumptions & Approach
You’re already successful.y
Your people know how to deliver working products.
You’re doing *something* right!g g g
Each CMMI practice seeks to avoid some risk.
Successful companies know how to avoid thoseSuccessful companies know how to avoid those
risks.
If we seek what your people are doing to avoid they p p g
same risks, we can map what they’re doing to CMMI.
Identify your working practices.y y g p
If there are gaps, you probably could use the
improvement.
719-Jan-09®2009 Entinex, Inc. ***PROPRIETARY*** ALL RIGHTS RESERVED

Practice/Process OverlapPractice/Process Overlap

OptimizationOptimization
Extreme Extreme
Optimized Optimized
Extreme
CoreCoreCore
CMMI
Principles
Agile
Principles
Agile
Principles

Typical Agile Concepts &Typical Agile Concepts &
TechniquesTechniquesqq
Iterative, incremental, and
ti b d d l t
Everyone is accountable
f littime-boxed development
Customer embedded with
developer
for quality
“Fail early & often”
Requirements developeddeveloper
Tacit knowledge is the key
Low risk when trust (with
t & t ) i hi h
Requirements developed
JIT
Change is “embraced”*customer & team) is high
Continuous integration
Each increment delivers
Change is embraced
Empowered co-located
teams
Each increment delivers
value (not only product)
Test written first, then the
Status meetings:
ceremony replaced with
frequent interactions,
code
Tools reverse engineer
a tifacts
frequent interactions
Regularly evaluate and
adjust process
artifacts
j p
Continuous re-planning

Lean and TQMLean and TQM
“Agile” is the result of applying “lean” concepts to
software.
CMMI is the result of applying TQM concepts to
systems and software development.y p
TQM and “lean” came from the same source!TQM and lean came from the same source!

Scrum in a NutshellScrum in a Nutshell
Definition
How Scrum WorksHow Scrum Works
Scrum CharacteristicsScrum Characteristics
S Lif C lScrum Life Cycle
Why Scrum Works

DefinitionDefinition
An iterative, incremental process for developing products and
i l d f fservices – mostly used for software.
Consists of a series of planned sprints, each sprint producing
something of valuesomething of value.
Between sprints, stakeholders evaluate progress and
reevaluate technical and business requirements. Tasks areq
assumed by the team for the next sprint.
Identifying and adhering to roles and rules is the key to its
success
Customer
ManagementManagement
Product Owner
Scrum Master
Scrum Team

How Scrum WorksHow Scrum Works
A bottom-up empirical approach based in process
control theory,
Vice top-down “command and control.”
Intended to give the team control of its time andg
destiny.

Scrum CharacteristicsScrum Characteristics
Product Backlog – prioritized list of all product requirements
hi h i d d d i i i d i lwhich is updated and re-prioritized continuously.
Sprint Backlog – identified, self-contained list of prioritized
work to be completed by the Sprintwork to be completed by the Sprint.
Sprint – set time period for each iteration during which the
work is not changed from outside the sprint although as workwork is not changed from outside the sprint, although as work
occurs in the sprint, additional work may be uncovered.
Scrum Master – a management representative whichg p
enforces Scrum practices
Daily Scrum – short daily meetings where a team identifies
what work was just done, what work will be done next, and
what is impeding work.
S i t i ti i ti f th d t i tSprint review meeting – inspection of the product increment

Scrum Life CycleScrum Life Cycle
Notional

Why Scrum WorksWhy Scrum Works
Self-organizing -- team meets to figure out how to
live up to its “Sprint goal”.
Responding empirically -- focusing on what is
possible.
Visibility -- The work being performed and anythingy g p y g
getting in the way of its completion is made visible
every day.
Focus -- The work being performed right then is
identified and assessed.
Incremental delivery -- showing progress earlier
and often.

RolesRoles
Customer & Management
Product OwnerProduct Owner
Scrum MasterScrum Master
S TScrum Team

Customer & ManagementCustomer & Management
Customer
Pays for the project and provides developers with
project, product and agreement expectations.
Usually its interface to the project is via the Product
Owner who understands Scrum and assumes
ibilit b h lf f th C tresponsibility on behalf of the Customer.
Management
Allows Scrum to happen: provides resources, top-
h b d h jnotch team members, and worthy projects.
Otherwise, stays out of the way. Communicates to
Sc m team ia Sc m MasteScrum team via Scrum Master.

Product OwnerProduct Owner
“Owns” the Product Backlog.
Sets Product Backlog priorities.
Officially responsible for the project.Officially responsible for the project.
Who it is depends on the project.
Customers are usually not Product Owners since mostCustomers are usually not Product Owners since most
organizations don’t want the Customer “officially
responsible for the project”.p p j
Scrum Masters are usually not Product Owners
because of potential conflict of interest and/or
potential to bend Scrum meeting rules.

Scrum MasterScrum Master
Responsible for ensuring that Scrum values,
practices, and rules are enacted and enforced.
Represents management and the team to each other.
Makes decisions and removes impediments.
Sometimes making decisions without completeg p
information (better some decision rather than no
decision).
Keep the team working at the highest possible level
of productivity:
Always working on value-adding activities.
Removing obstacles.
Resolving conflict.

Scrum TeamScrum Team
Individuals with different strengths and abilities.
Seven people (plus or minus two), as small as three.
Cross-functional with all skills to meet the Sprint goal.p g
At least one very experienced engineer as part of theAt least one very experienced engineer as part of the
team.
No titles on the teams (to encourage self organization).

ComponentsComponents
Product Backlog
Sprints & Sprint BacklogsSprints & Sprint Backlogs
Daily Scrum MeetingsDaily Scrum Meetings
Chi k d PiChickens and Pigs
Release Planning

Product BacklogProduct Backlog
Evolving prioritized queue of business and technical
functionality to be done on the product.
Higher priority items should be clearer and have a
more detailed specification.p
Solely controlled by Product Owner (one person) whoSolely controlled by Product Owner (one person) who
works with others to estimate how long it will take to
develop.p

Sprint & BacklogSprint & Backlog
Every sprint has a defined goal.
The sprint team has final say in estimating and
determining what they can accomplish during the
sprintsprint.
Once the sprint is underway, new backlog cannot be
added to the sprintadded to the sprint.
except that if the scrum master and team determine
that a new backlog item will enhance the viability ofg y
the product, is in alignment with the sprint goal, builds
on the sprint’s value, and can be completed within the
sprint’s time frame the backlog item can be addedsprint s time frame, the backlog item can be added.
If external forces determine that the sprint is working
on the wrong thing, a sprint can be halted andon the wrong thing, a sprint can be halted and
restarted with new backlog and goal.

Daily 15-30 minute status meeting.
Team individuals explain:
What has been accomplished since last meeting,
What will be worked on before the next meeting, and
What obstacles are in the way.
F ll i f h d il bFollow-up meetings after the daily scrum can be
established based on answers to the above
questionsquestions.
Burn-Down is updated.
Benefits:Benefits:
Fosters team-based, rapid, intense, co-operative,
courteous development.p
Improves communication.

(contd)(contd)( )( )
Established meeting room.
same place and same time
Appropriate Facilities:pp p
Door, speakerphone, table, chairs for each team
member, whiteboards.
Scrum Master facilitates meeting.
Only SM and Team members speak.Only SM and Team members speak.
Avoid:
Turning it into a working or design sessionTurning it into a working or design session,
Customer, management, or product owner
interruptionsinterruptions

Chickens and PigsChickens and Pigs

Release PlanningRelease Planning
Sometimes referred-to as “iteration” planning.
Defines high level requirements and sets priorities.
Defines high level work break down structureDefines high level work break down structure.
May define high level release schedule.
Can be used to establish project work and process
environments.
Can be a sprint in and of itself.

Sprints in DetailSprints in Detail
Sprint Planning Meeting
Sprint GoalSprint Goal
Sprint BacklogSprint Backlog
S i t Ch t i tiSprint Characteristics
Sprint Review
Sprint Review Content

Sprint Planning MeetingSprint Planning Meeting
Customers, users, management, the Product Owner
and the Scrum Team determine the Sprint goal and
value-added effort.
The team creates tasks, estimates and determines,
who is going to do what, everyone commits to the
feasibility of the plan.
What can be done in the Sprint time-box with the
resources we have at our disposal?
More detailed WBS possible at this level.

Sprint GoalSprint Goal
Craft the Sprint Goal.
Goals are specific and measurable/“testable”.Goals are specific and measurable/ testable .
Goals must be drawn from prioritized ProductGoals must be drawn from prioritized Product
Backlog items.
Defining the goal gives the team some wiggle room
as the degree to which the goal is satisfied is flexibleas the degree to which the goal is satisfied is flexible,
depending on the difficulty of the task.

Sprint Backlog, 1Sprint Backlog, 1
After the Sprint goal has been defined, the Sprint
Backlog is defined by the team assembling a list of
tasks from the Product Backlog to meet the Sprint
lgoal.
All team members must be present.
Tasks should have enough detail so that each task
takes roughly 4 to 16 hours to finish. Larger tasksg y g
are broken-down.

Sprint Backlog, 2Sprint Backlog, 2
Only the team can change its Sprint Backlog during a
Sprint (except as noted earlier).
Sprint Backlog is a highly visible, real time picture of
the work that the team plans to accomplish duringp p g
the Sprint.
Sometimes the team discovers it has selected too
much Product Backlog to complete in a single Sprint.g p g p
Items may be removed functionality with scope orItems may be removed, functionality with scope or
depth may also be lessened to meet the Sprint Goal.

Sprint CharacteristicsSprint Characteristics
Accounts for all work (product, project, process) to
be performed.
The process can produce mistakes but the “cost” is
low and corrections are fast.
Each person’s knowledge base is broadly expandedp g y p
though their interaction.
Resource Allocation: Managed by the team, asg y ,
members commit to getting the work done.
At the very worst, the team has built nothing but hasy , g
learned much.

Sprint ReviewSprint Review
Management comes to the Sprint Review to see what
the team has been able to build with the resources it
has been given.
Coordinated and conducted by the Scrum Master.
Learning, retrospectives and introspectives.g, p p
Good place for some quality and other evaluations.
The Sprint review is a form of validity check-it isThe Sprint review is a form of validity check it is
determined that the right product is being built.
Covers whether the product was built right because aCovers whether the product was built right because a
working version of the product is giving a viewing to
the product owner.

Sprint Review ContentSprint Review Content
Scrum Master gives concise overview of the Sprint.
Sprint goal and Product Backlog are compared to the
actual results of the Sprint.actual results of the Sprint.
Reasons for any discrepancies are discussed.
P d t O d id if f ti ll d litProduct Owner decides if functionally and quality are
sufficient to be released.
N i i i d (i f l)No extensive preparations required (informal).
Purpose is informational, not critical or action-p
oriented (the Sprint is over).
Informational meeting should be time-limited (~4hr)Informational meeting should be time limited ( 4hr)

Management ToolsManagement Tools
Progress and Backlogs can be managed in
Excel,
ScrumWorks,
XPlanner,
etc.
Burn-down is a chart providing visible measures of
progress showing
Effort Remaining (hours of Sprint backlog committed)
vs.
Time Remaining (hours remaining in Sprint)
Sprint Backlog is typically adjusted by team and Sprintp g yp y j y p
goal is re-visited for interpretation & assumptions.

Development ActivitiesDevelopment Activities
Daily Inspection and Visibility into team progress.
Daily Issues Management and Resolution.
Daily Project Command and Control within the selfy j
managing team.
Peer Reviews & InspectionsPeer Reviews & Inspections
Peer reviews keeps the team members honest.
Peer reviews are about mentoring, not policing.g, p g
Complete checkpoints and tollgates along the project
road map that can be done iteratively and kept non-
i iinvasive.

Why Agile

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Why Agile

Ähnlich wie Why Agile (20)

Mehr von Hillel Glazer

Mehr von Hillel Glazer (6)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Why Agile