2 a introduction to agile

Introduction to Agile
Scrum Master Certified (SMC™)

Agile Antecedents
Adaptive Project Management

Why Agile ?
• Agile proponents believe
– Current software development processes are too
heavyweight or cumbersome
• Too many things are done that are not directly related to software
product being produced
– Current software development is too rigid
• Difficulty with incomplete or changing requirements
• Short development cycles (Internet applications)
– More active customer involvement needed
• CMM focuses on process

Difference between the SDLC’s

Waterfall Vs. Agile
Scope
Cost Schedule
Value
Quality Constraints
Difference between the SDLC’s

12
Product Vision
Defined By
Customer/Product
Owner
Agile Product Development Lifecycle
Agile Lifecycle

13
Product Vision
Defined By
Customer/Product
Owner
The Product Backlog
represents all stories
identified for the release
Customer and Team
define and size
product stories
A story may represent a body of
work, component or requirement
that can be “verified” as having
been completed.
Agile Lifecycle

14
Product Vision
Defined By
Customer/Product
Owner
The Product Backlog
Customer and Team
define and size
product stories
The Release
Backlog represents
all stories planned
for the next release
Stories are added to the
Iteration Backlog at the
start of each iteration based
on business value.
A Release Backlog represents
functionality that is planned to be
completed. A Product Backlog
represents functionality that may
or may not be implemented based
on priority and progress
Agile Lifecycle

15
Product Vision
Defined By
Customer/Product
Owner
The Product Backlog
Team identifies and
estimates the
activities for each
story in the iteration
Customer and Team
define and size
product stories
The Release
Backlog represents
all stories planned
on business value.
Story Activities
Stories are decomposed into
activities each iteration. These
are the activities that expected to
be completed within the single
iteration.
Agile Lifecycle

16
Product Vision
Defined By
Customer/Product
Owner
The Product Backlog
Team identifies and
estimates the
activities for each
Customer and Team
define and size
product stories
The Release
Backlog represents
all stories planned
on business value.
Story Activities
Team tackles activities
and reports progress
daily
The team works only on planned
activities. Any newly discovered
tasks are added to the plan.
Team delivers developed,
tested and customer-
accepted stories at the
end of each iteration
Agile Lifecycle

17
Product Vision
Defined By
Customer/Product
Owner
The Product Backlog
Team identifies and
estimates the
activities for each
Customer and Team
define and size
product stories
The Release
Backlog represents
all stories planned
on business value.
Story Activities
daily
Team performs retrospective at the end of
each iteration to identify ways to improve
Agile Lifecycle

18
Product Vision
Defined By
Customer/Product
Owner
The Product Backlog
Team identifies and
estimates the
activities for each
Customer and Team
define and size
product stories
The Release
Backlog represents
all stories planned
on business value.
Story Activities
daily
Team performs retrospective at the end of
each iteration to identify ways to improve
New Iteration begins with
new planning game
Agile Lifecycle

The Agile 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
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• 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. “

Agile Principles
1. Our highest priority is to satisfy the costumer through early and
continuous delivery of valuable software
2. Welcome changing requirements, even late in development. Agile
process harness change for the customer´s competitive advantage
3. Deliver working software frequently, from a couple of weeks to a
couple of months, with a preference to the shorter timescale
4. Business people and developers must work together daily throughout
the project
5. Build projects around motivated individuals. Give them the
environment and support they need, and trust them to get the job
done
6. The most efficient and effective method of conveying information to
and within a development team is face-to-face conversation

Agile Principles
7. Working software is the primary measure of progress
8. Agile processes promote sustainable development. The sponsors,
developers, and users should be able to maintain a constant pace
indefinitely
9. Continuous attention to technical excellence and good design
enhances agility
10. Simplicity – the art of maximizing the amount of work not done – is
essential
11. The best architectures, requirements, and designs emerge from
self-organizing teams
12. At regular intervals, the team reflects on how to become more
effective, then tunes and adjusts its behavior accordingly

Declaration of Interdependence
Agile and adaptive approaches for linking people, projects, and
value
To achieve these results:
• We increase Return on Investment by making continuous flow
of value our focus.
• We deliver reliable results by engaging customers in frequent
interactions and shared ownership.
• We expect uncertainty and manage for it through iterations,
anticipation, and adaptation.

Declaration of Interdependence
To achieve these results:
• We unleash creativity and innovation by recognizing that
individuals are the ultimate source of value and creating an
environment in which they can make a difference.
• We boost performance through group accountability for results
and shared responsibility for team effectiveness.
• We improve effectiveness and reliability through situationally
specific strategies, processes, and practice.
[©2005 David Anderson, Sanjiv Augustine, Christopher Avery,
Alistair Cockburn, Mike Cohn, Doug DeCarlo, Donna Fitzgerald,
Jim Highsmith, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent
McDonald, Pollyanna Pixton, Preston Smith, and Robert Wysocki.]

Agile vs. Cowboy Coding
• Eliminate waste does not mean throw away all
documentation.
• Amplify learning does not mean keep on changing your mind.
• Decide as late as possible does not mean procrastinate.
• Deliver as fast as possible does not mean rush and do sloppy
work.
• Empower the team does not mean abandon leadership.
• Build integrity in does not mean big, upfront design.
• See the whole does not mean ignore the details.

Session Purpose Timing/Duration Attendees
Iteration 0 Orient Team to project’s business
value and analytical background, the
process, and one another.
Start of project
Approximately 1-3
weeks of 2-4 hr
workshops
Team, PO, SM, Key
Stakeholders &
users
Release
Planning
Determine what a Release should
include and when it should be
delivered.
Start of Release
2-4 hours
PO, SM, Key
Stakeholders,
optionally Team
Daily Standup Facilitate rapid coordination between
Team members, and with PO.
Daily
10-15 minutes
Team, SM, PO
Iteration
Planning
Elaborate, estimate and prioritize
highest-value Product Backlog items
for an Iteration.
Start of each
Iteration
2-4 hours
Team, SM, PO
Iteration
Retrospective
Reflect on project & process issues
and take action as appropriate.
End of each
Iteration
30-45 minutes
Team, SM, PO
Iteration
Review
Demonstrate completed functionality
to interested stakeholders & users to
show progress and gain feedback.
End of each
Iteration
1-1½ hours
Team, PO, SM, Key
Stakeholders &
users
Meetings Summarized

Some Basic Terminology
Scrum Agile Definition
Sprint Iteration Fixed-length period of time (timebox)
Release Small Release Release to production
Sprint/Release
Planning
Planning Game Agile planning meetings
Product Owner Customer Business representative to project
Retrospective Reflection “Lessons learned”-style meeting
ScrumMaster Coach Agile project manager
Development
Team
Team Empowered Cross-Functional team
Daily Scrum Daily Standup Brief daily status meeting

Some More Agile Terminology
Term Definition
Spike
Something cannot be estimated until a development team runs a timeboxed
investigation. The spike itself is a throw-away.
Can include risk, architectural, or any unknown.
Tracer Bullet
An experimental solution that cuts through all the "layers" of
the architecture. It is not necessarily time-boxed. It is not intended to be thrown
away.
Kaizen Continual improvement of all areas of a company not just quality.
Value Stream An end-to-end business process which delivers a product or service
More terms… Go to the Community Guide of the PMI-ACP at http://agile.vc.pmi.org/

CRYSTAL Methods
The Crystal family of methodologies focuses on efficiency,
osmotic communication between team members, and feedback-
based learning for future operations.

Relation of Crystal’s four vital factors in determining the
“weight” of Crystal methodology

People & communication
Lightweight methodology
• minimizing documentation, management overhead, and reporting.
• whiteboards are widely used for storing, displaying, and sharing information.
Easy to adapt approach:
• Factors such as comfort, discretionary money, essential money, and life determine the
“weight” of the methodology in various colors of spectrum.
Incremental development of features:
• have a life span of 4 months or between one and three months.
• decided on the basis of the “weight” of the methodology being used.
Flexibility and fluidity:
• adoption of other software methodologies such as XP and Scrum.
Active user involvement:
• at least 2 user viewings per week.
Osmotic communication:
• casual listening to and over-hearing conversations) can take place
Frequent tracking of progress
• tracking milestones based on product deliveries and landmark decisions instead of
documentation and reporting.
CRYSTAL - Core Values

Crystal : Roles
Mandatory roles
• Executive sponsor:
• Lead designer: level-3 designer
• Designer/programmer:
• Experienced user
Non Mandatory roles (dedicated only above Orange)
Architect, coordinator, requirements gatherer, business expert, business
analyst/designer, project manager, design mentor, usage expert, lead design
programmer, UI designer, technical facilitator, and technical writer.
• Coordinator
• Business expert
• Tester/writer

CRYSTAL : Practices
• Exploratory 360°
• Early victory: early success - small piece of working software is developed.
• Walking skeleton: End-to-End-piece (E2E) that links main architectural
components
• Incremental re-architecture: The architecture is evolved in stages aligned to
the walking skeleton
• Information radiators
• Methodology shaping: a) Performing interviews b) A methodology workshop
• Reflection workshop
• Blitz planning: quick collaborative planning involving representative from each
stakeholder category - plans for the walking skeleton, the first delivery
• Delphi estimation: is a group-based estimation technique
• Daily Stand-up Meetings
• Essential interaction design: a fast usage-centered design approach focused
on delivering features that satisfy end users of the product.
• Process miniature: short mini-project with all the elements of the new process.
• Side-by-side programming
• Burn charts: Burn charts (burndown or burnup) are efficient ways to plan, track,
and report progress.

Chartering:
• Build the core of the team.
• Perform an exploratory 360°.
• Shape and fine tune the methodology.
• Create an initial project plan.
Delivery cycle: Each delivery cycle consists of: Update/re-calibrate release plan &
One or more iterations
Each iteration consists of:
• Iteration planning
• Daily activities
• Completion (reflection workshop and celebration)
• A delivery or release to real users (user viewings)
• A delivery cycle completion: lessons learned, relax, refresh “batteries,” and get
mentally ready for the next delivery cycle.
Wrap up: The wrap up is similar to the delivery cycle completion.
CRYSTAL : Process

Dynamic Systems Development
Method
DSDM is an Agile framework that embraces dynamic customer
involvement in project delivery. DSDM focuses on projects with tight
schedules and budgets. DSDM subscribes to the Atern philosophy and
uses these principles to direct the team in the delivery process.

• closely follows iterative and incremental approach
• DSDM sets cost, quality, and time at the outset
• adjusts the project deliverables to meet the set criteria by prioritizing the
deliverables into musts, shoulds, coulds, and won’t haves (MoSCoW).
• later version of DSDM known as DSDM –Atern, introduced in 2007,
focuses on both prioritization of deliverables and consistent
user/customer collaboration.
• inspired by an Arctic Tern, because it epitomizes freedom, robustness,
and collaborative aptitude
• developer-centric software development framework for on-time and in-
budget delivery of user-valued and quality-controlled project features.
Dynamic Systems Development
Method

Core Values
1. Focus on business need:
. Understand the true business priorities
• Establish a sound business case
• Seek continuous business sponsorship and commitment
• Guarantee the Minimum Usable Subset (which is explained in detail in the
section on MoSCoW prioritization)
2. Deliver on time:
ensure frequent and timely delivery of business-oriented products.
• Time-box the work
• Focus on business priorities
• Always meet deadlines
3. Collaborate:. ambassador user, advisory user, and visionary - Involve the right
stakeholders, at the right time
• Ensure that the members of the team are empowered to take decisions
• Actively involve the business representatives.
• Build a one-team culture.
4. Never compromise quality: Set the level of quality at the outset.
• Ensure that quality does not become a variable.
• Design, document, and test appropriately.
• Build in quality by contrast review.
• Test early and continuously.

Core Values
Build incrementally from firm foundations: early delivery of business benefit
• Continually confirm the correct solution is being built.
• Formally re-assess priorities, ongoing project viability with each delivery
Develop iteratively: Do enough design up front to create a strong foundation.
• Build customer feedback into each iteration.
• Accept that most detail emerges later rather than sooner.
• Embrace change—the right solution will not emerge without it.
• Be creative, experiment, learn, and evolve.
Communicate continuously and clearly
• Use facilitated workshops.
• Use rich communication techniques such as modeling and prototyping.
• Present instances of the evolving solution early and often.
• Keep documentation lean and timely.
• Manage stakeholder expectation throughout the project.
• Encourage informal and face-to-face communication at all levels
Demonstrate control:
Use an appropriate level of formality for tracking and reporting.
• Make plans and progress visible to all.
• Measure progress through focus on delivery
• Manage proactively.
• Evaluate continuing project viability based on the business objectives.

15 roles and responsibilities
Executive sponsor:
• represents the user organization or the stakeholder - “project champion”.
• responsible for keeping the project running smoothly - budget and financial
resources ultimate power to make decisions.
Visionary:
• from the user organization;
• is the business expert of the project system
• ensures that the necessary requirements are identified at the beginning
Ambassador user:
• from the user organization - the bridge between team and user community;
• brings in knowledge and feedback from the user community and vice-versa.
• informs the user organization about the progress of the project and gets
feedback
Advisor user:
• similar to that of the ambassador user’s.
• addresses important viewpoints and brings in reviews /knowledge of the project
system
Roles

Project manager:
• ensures that the development proceeds smoothly
• clears impediments for the development team.
Technical coordinator:
• responsible for the technical aspects of the project.
• supervises and coordinates the design and development of the technical
architecture of the project as well as controls technical quality.
Team leader:
• administrative and technical leader of the team.
• bridge the gap between the teams and the previously mentioned roles.
Developer:
• responsible for design, development, and testing of the deliverable code and
prototypes. further classified as designers, programmers, testers, and analysts.
Apart from the above mentioned roles, DSDM provides for other specialist roles
such as scribe, facilitator, business architect, quality manager, and system
integrator.
Roles

Practices
Six phases for product development
1. The pre-project phase terms of reference (feasibility & scope)
2. The feasibility phase
• feasibility from a business and a technical perspective.
• identifies and suggests a mitigation strategy for high priority risks.
3. The foundations phase consists of the six activities:
• business vision.
• The prioritized requirement list
• Solution foundation comprised of definitions of business area, system
architecture, development approach, and solution prototype.
• Management and organizational - application of Atern practices/techniques.
• The delivery plan - the schedule
• The delivery control pack - documented progress of the project.

Practices
Exploration and engineering - five activities:
• introductory blueprint - business models, design models, support documentation,
business user documentation, and prototype solutions.
• The solution assurance pack - solution review record, business testing and
technical testing pack.
• The deployment plan is the comprehensive sketch of the deployment phase
• The time-box plan delves into the objectives for each development time-box in
the delivery plan.
• The time-box review record is a summary of the targets achieved and feedback
5. Deployment - two activities:
• deployable solution is transferred from engineering to live environment.
• The project review report updated at the end of each increment. It consists of
increment review, benefits enablement summary, and end of project
assessment.
6. Post-project activities
• benefits assessment measures benefits of using the deployed solution analyzes
discrepancies between targets achieved and projected

Two core principles
• software development as a human activity
• client-valued functionality
breaking it down into small, client-valued functions that can be delivered in less than
two weeks’ time.
• A system for building systems is necessary in order to scale to larger projects.
• A simple, well-defined process works best.
• Short, iterative, feature-driven life cycles are best.
• Process steps should be logical and their worth immediately obvious to each
team member.
• “Process pride” can keep the real work from happening.
• Good processes move to background so team members can focus on results.
FDD – Core Values

Roles
Major Roles
• Project manager:
• Chief architect:
• Development manager
• Chief programmers
• Class owners: actual developers and designers
• Domain experts
Supporting Roles
• Domain manager:
• Release manager: similar to the “tracker” role in XP.
• Language guru: used when programming language is new to the team.
• Build engineer: responsible for the regular builds
• Toolsmith: provides tools for the team and could be part of the IT department.
• System administrator:
Three more roles which can be played by project team/external
• Testers: responsible for the verification of the overall system functionality
• Deployers: responsible for the deployment and could be part of the operations
department
• Technical writers: responsible for providing documentation

There are 8 best practices that make up FDD
Domain object modeling:
• provides an overall framework to gives guidance and provides a better initial
design.
• allows the overall problem or system to be divided into smaller pieces
Developing by feature:
• Features are functional requirements of value to clients - understand and
prioritize them.
• Underlying functionality (NFD) not tracked as a feature.
• Features in FDD are granular functions expressed in client value terms using :
• <action><__result__><object>.
Individual class (code) ownership:
• developer assigned ownership of classes from domain object model.
Feature teams: develop single, client-valued features.
• leader (a chief programmer) and class owners needed to implement the feature.
• Feature teams are normally small (typically 3-6 people).
• Each team member contributes to the design and implementation of a feature.
• Class owners can be members of multiple feature teams
• Team leaders (chief programmers) can be class owners
Practices

Practices
Inspections:
• organized by the chief programmer and involve the whole feature team.
• everybody’s code is inspected.
• chief programmer decides whether to involve people from in the review
Regular builds:
• Builds of the complete system are done at regular intervals.
• help to detect integration errors early, ensures that demo system availability
• Intervals depend on the size and complexity of the system and time take to build.
Shorter intervals are preferred
Configuration management:
• only code for completed features & related class changes under CM
• include requirements documentation, test cases, other artifacts under CM
Reporting/visibility of results:
• on a per feature basis - 6 milestones with certain percentage of progress
• Progress is counted when the milestone is reached at 100% and before that,
counted as 0 (no credit for work in progress).
• Getting things completed rather than having them almost done.

1. Developing an overall model
 Creating the base object model and establishing the system
 Under guidance of the chief architect
 chief architect, chief programmers, and domain experts perform a high-
level walkthrough of the system’s scope and context.
 model is defined and selected by consensus.
 initial model is updated iteratively by process 4 (design by feature).
Entry criteria: Needed members selected and assigned.
Tasks:
• Form the modeling team (required): responsibility of PM. Permanent members
• Conduct a domain walkthrough (required):done by the modeling team.
Study documents (only when needed): Done by the modeling team.
• Develop small group models (required): broken down into smaller sub-teams
(=or less than 3 members). develops proposed model for respective domain
• Develop a team model (required): representative from sub-teams presents
proposed model developed. By consensus, one model selected.
• Refine the overall object model (required): After iterations by the modeling team
• Write model notes (required): significant alternatives,complex /detailed models
Verification of the results: assessed internally by domain experts / externally users
Exit criteria: modeling team provides object model accepted by chief architect.

Building a features list
 Chief programmers identify features necessary to fulfill the requirements.
 Team provides hierarchical feature list based on the domain partitioning
 Hierarchy consists of major feature sets (a breakdown of the domain into
multiple areas), feature sets (activities; further breakdown of the areas),
and features (identifying steps within each activity).
Entry criteria: completed the preceding process
Tasks
• Form the features list team (required): responsibility of PM and development
managers with the team normally consists of the chief programmers
• Build the features list (required):Based on reference and requirements
documents and the results/knowledge, the team identifies features.
• If feature larger than to 2 weeks, then the team breaks it down into smaller
features.
Verification of the results: assessed internally by the feature list team members
and externally by business users and/or domain experts from modeling team.
Exit criteria: The features list team must provide a features list that is accepted by
the project manager and the development manager.
• A list of major feature sets (areas).
• A list of features sets (activities) per area.
• A list of features per activity.

Planning by feature
 The project manager, the developmental manager, and the chief
programmers form a planning team that creates a development plan.
Entry criteria: successfully completed the preceding process
Tasks: The planning by feature process can be divided into the following tasks:
• Form the planning team (required): responsibility of PM. Team - PM,
development manager, and chief programmers. Others can be added if needed.
• Determine the development sequence (required): Based on the feature list,
the planning team sets a date for the completion of each feature set.
• Development criteria evaluated during the planning complexity, risk, feature
dependencies, load per expert, and external milestones such as beta releases,
demos
• Assign the feature set to chief programmers (required): assigns features.
chief programmers own respective feature sets. normal development practices
• Assign classes to developers (required): assigns classes. developers own
their respective classes. normal development practices
Verification of the results: assessed internally by feature planning team
Exit criteria: The features list team provide a development plan that is accepted by
the project manager and the development manager.
• Feature sets with completion dates including for major feature sets
• Assignments of chief programmers
• Assignments of class owners

Designing by feature
 done per feature to produce a design package.
 chief programmer selects features owned and forms feature team
 Classes are detailed, the sequence diagrams are created, and the object
model that was created in the first process is updated and refined by chief
programmer
Entry criteria: The planning team has successfully completed preceding process
Tasks: per feature
• Form a feature team (required): identifies classes impacted and developers
• Perform a domain walkthrough (optional): done by domain expert per the
chief programmer’s request. If necessary due to complexity or interactions
• Study documents (optional): if necessary due to complexity of the feature
• Develop sequence diagrams (required): detailed sequence diagrams and
recording of alternative designs, decisions, and so on.
• Refine the object model (required): done by the chief programmer.
• Write class and method prologue (required): done by the feature team.
• Design inspection (required): done by feature team, decided by chief
programmer. A to-do list is created for each class owner for further steps.
Verification of the results: verified with a successful design inspection.
Exit criteria: The feature team provide a design package accepted in the design
inspection.

Building by feature
 building the feature.
 Chief programmers and class owners implement, inspect, and test the
code designed Based on the outcome, changes are incorporated into the
next iteration.
Entry criteria: feature team has provided a design package accepted in design
inspection
Tasks:
• Implement classes and methods (required)
• Conduct a code inspection (required)
• Unit test (required): Each class owner tests their code. The requirements for
the testing are defined by the chief programmer.
• Promote the build (required): This is done by the feature team and the chief
programmer. It is only possible to promote the build when there has been a
successful code inspection and unit test.
Verification of the results: verified with a successful code inspection and unit test.
Exit criteria: The feature team complete the development of one of more whole
features (client-valued functions).

XP is a lightweight, low risk, flexible, and predictable way to develop
software Frequent releases in short development cycles to improve
productivity and provide check points for feedback and changes.
strict attention to minimizing technical debt allows the project team to focus
more on the task at hand: delivering the business objective to the
customer.
• incremental planning approach, quickly comes up with an overall plan
• flexibly schedules the implementation of functionality, responding to changing
business needs.
• automated tests written by programmers
• oral communication, tests, and source code to communicate system structure
and intent.
• evolutionary design process that lasts as long as the system lasts.
• close collaboration between programmers.
• practices that work with both the short-term instincts of programmers and the
long-term interests of the project.
Extreme Programming

• Communication: developers know what needs to be done and for
customers know when it will be done.
• Simplicity: building only what is essential today and not predicting
tomorrow’s needs maximizing the value of the investment.
• Feedback: XP concentrates on frequent planning, designing,
testing, and communicating as means to provide fast and regular
feedback
• Courage: The only way to recover from mistakes is to admit them
and then take corrective actions; this requires courage.
XP – Core Values

Customer-Developer Relationships
A well-known experience in Software Development:
The customer and the developer sit in a small boat in the ocean and
are afraid of each other.
Customer fears Developer fears
They won't get what they asked for They won't be given clear definitions
of what needs to be done
They must surrender the control of
their careers to techies who don't care
They will be given responsibility
without authority
They'll pay too much for too little They will be told to do things that don't
make sense
They won't know what is going on (the
plans they see will be fairy tales)
They'll have to sacrifice quality for
deadlines
Result: A lot of energy goes into protective measures and politics
instead of success

The Customer Bill of Rights
You have the right to an overall plan
To steer a project, you need to
know what can be accomplished
within time and budget
You have the right to get the most
possible value out of every programming
week
The most valuable things are
worked on first.
You have the right to see progress in a
running system.
Only a running system can give
exact information about project
state
You have the right to change your mind,
to substitute functionality and to change
priorities without exorbitant costs.
Market and business requirements
change. We have to allow change.
You have the right to be informed about
schedule changes, in time to choose how
to reduce the scope to restore the original
date.
XP works to be sure everyone
knows just what is really
happening.

The Developer Bill of Rights
You have the right to know what is
needed, with clear declarations of
priority.
Tight communication with the
customer. Customer directs by
value.
You have the right to produce quality
work all the time.
Unit Tests and Refactoring help
to keep the code clean
You have the right to ask for and
receive help from peers, managers, and
customers
No one can ever refuse help to a
team member
You have the right to make and update
your own estimates.
Programmers know best how
long it is going to take them
You have the right to accept your
responsibilities instead having them
assigned to you
We work most effectively when
we have accepted our
responsibilities instead of having
them thrust upon us

Separation of Roles
Customer makes business decisions
Developers make technical decisions
Business Decisions Technical Decisions
Scope Estimates
Dates of the releases Dates within an iteration
Priority Team velocity
Warnings about technical risks
The Customer owns “what you get” while the
Developers own “what it costs”.

Roles in XP
The customer
• Creator of the project idea and explains the project to others involved in it.
• Drives the project from its business point of view
• has the authority to set project goals and milestones and schedule the features
accordingly
• Works closely with developer to run tests and ensures that the features in the
story cards are complete.
• Looks at the business viability of a feature from the point of an end user and
makes business changes accordingly.
• Should have the technical knowledge to understand risks associated with story
implementation

Roles in XP
The developer
• Responsible for the execution of a project.
• Role is to transform stories into working code.
• The work is primarily based on their technical expertise.
• Gain insight into the customer’s story and then work toward its implementation.
• Evaluate the work required to implement each story helping the customer to
prioritize work for the upcoming iteration.
• Identify the technical risks associated with a story and share them with the
customer so the customer can evaluate the schedule and make appropriate
business decisions.

May not always be formally present
The tracker
• responsible for keeping track of the project schedule, detect changes in team
behavior, Irregularities are analyzed and dealt during stand-up team meetings
• Metrics - Team velocity - “the ratio of ideal time estimated for tasks to the actual
time spent implementing them.” (progress of project and speed of progress)
The Coach:
• When team is new to XP, coach mentors the team and leads members in the
right direction.
• Provides knowledge of an experienced mentor to overcome unseen hurdles.
• Imparts knowledge by using regular teaching methods or `walk the talk’ when
necessary.
Supplementary Roles in XP

Practices
12 practices and interactions
Broadly be classified as XP coding, developer, and XP business practices.
Coding Practices
Developing coding standards:
• conventions used to enable developers to communicate ideas clearly
• guidelines for effective code writing and avoid unfamiliar coding styles
Pair programming:
• To ensure that all code follows the defined guidelines
Developer teamwork:
• Adopt a new coding style to encourage communication of shared values
Reviews:
• To ensure the existing code reflects the agreed standards
Coding and designing:
• values of flexibility and simplicity.

Developer practices :
Test-driven development
Repetition of short development cycles for the process of software development.
TDD process
• Developer writes a test that the existing code fails
• Writes the code that passes the test
• Refactors the code
• Automates the complete test and keeps testing the code
• Feature is done when all tests are passed
• Clean up the code and repeat
Unit Testing:
• check behavior of code both of individual units of code and the program
modules together to determine whether they are fit for use.
Acceptance Testing:
• run from a business and customer point of view.
• Check requested and implemented
• determine whether features match business and customer requirements
Practices

Practices
Coding Practices
Developing a common vocabulary
• Everyone on the team understand concepts and terms to describe the project
and use a common vocabulary.
• word pictures designed with simplicity.
• help customers in common vocabulary without external input.
• supports collective code ownership and constant customer interactions.
Refactoring:
improve the maintainability of the existing code, and make it simpler, more concise,
and more flexible.
improving present code design without changing how the code behaves.
• Eliminating repetitive and redundant code
• Breaking methods and functions into smaller routines
• Clearly defining variable and method names
• Simplifying the code design
• Making the code easier to understand and modify

Pair programming
• increases productivity of the developers by improving the quality of code.
• The driver writes the code ( micro perspective) while the navigator directs the
driver (macro perspective)
• A pair is formed to work on a single task, and pair is dissolved to form a new
pair.
 Done to encourage collective code ownership.
 Infrastructure to support pair programming
 Developer and management acceptance to adopt pair programming
Collective code ownership
• all the developers treat the entire code as if it were their own
• Responsibility of the code across the team
• Any developer has authority to make changes to any part of the code
• Adopting coding standards - writing clean code.
Developer practices
Practices

Continuous integration
• Reduce impact on overall software development when adding and modifying
features.
• creation of a code repository or a code base for source code
• maintain up-to-date code base; all developers update at regular intervals
• Builds are done as frequently as possible to ensure additions to code base do
not break the build process
Maintaining a sustainable pace
• make sure that the team is fresh, so that they can continue to work at an
aggressive but a sustainable pace.
• Trying to increase team velocity artificially can be counterproductive if the
team becomes over worked and makes mistakes;
• find the correct team velocity and to keep the working hours and lengths of
iterations constant.
Developer practices
Practices

Adding a customer:
• The customer addresses business concerns - available to review the work,
• communicate changing business requirements,
• make decisions regarding software features when necessary.
Regular release:
• leads to rapid and precise feedback
• used for scheduling/implementing required changes in next iteration.
• customer gets to view the concrete product
The Planning Game:
• customer defines date and scope of release, order of delivery of User Stories
• developers estimate the time that each story will take,
• communicate technical impacts of implementing requirements
• breaks down the stories into tasks, and allocates work among themselves.
80-20 Rule:
• Pareto principle - 80% of the effects result from 20% of the causes.
• 80% of the useful results come from 20% of the work they put in.
• XP practice, “put the most essential and valuable 20% of functionality into
production, work on the most important 20% of the design, and rely on the 80-20
rule to defer optimization.”
Business practices
Practices

XP Artifacts
Story Card:
tool that answers the question, “what should be done?”
• The card lists a feature that the customer wants in the form of a brief story.
• story cards help the developers visualize the functionality needed
• Customers use story cards to explain desired features - read by developers.
• Card translate the features into workloads and tasks that written on task cards.
• Cards are labeled according to their status: scheduled for iteration, unscheduled,
or complete.
• Customers create the stories, developers do not change the stories.
Task Card:
• lists the steps that need to be taken by developers in order to implement a story.
• Task cards are completely technical and encourage communication between
developers.
• story broken into tasks based on technical details related to its implementation.
• calculates costs according to working hours required to complete the task.

XP Artifacts
The Bullpen:
XP work environment
Soundproof
brightly lit
house powerful systems to run tests frequently.
• a large room with ample space for free movement, high-function furniture, and
many whiteboards and bulletin boards.
• stocked with sticky notes and index cards.
• the “war room” and is designed for developers to work, communicate, and
move around without bumping into one another.
• makes pair programming easier, because programmers can sit next to each
other and switch roles easily.

XP Events
Iteration planning:
• accommodate changes within the project schedule instead of waiting until the
end.
• first iteration - gather genuine data, find actual team capability, determine team
velocity as well as individual velocity, and guage customer reaction to real
working software. (“yesterday’s weather.” XP - analyzing “a similar past.” )
• iteration planning meeting - the project is re-evaluated, and the next iteration is
scheduled. customer centric meeting - authorized to choose the desired
features
• Velocity serves as an indicator of project growth.
Stories and tasks:
• use of story cards for the customer to describe a feature and its specifications in
story form A single story card represents a single feature.
• story cards are picked up by developers to understand length of implementation
Estimating time is done with task cards.
• Task cards are made by developers - signifies a step for the implementation of a
story.
• Tasks may undergo changes when the stories associated with the tasks change
according to customer’s requirements and values.

XP Events
Estimates and schedules:
• developers estimate time required for implementation of the desired feature of
story
• The estimates are based on ideal time and not actual time.
• focus on getting maximum value.
• The customer prioritizes desired features for an upcoming iteration
• deal with the high risk features first, when there is no time crunch
Daily Stand-up Meeting.
Short, no seating arrangement
Person who acts as the tracker for the team writes down work progress.
Three questions are asked during the meeting:
• “What have you done since yesterday?”,
• “What are you going to do today?”,
• “Are there any impediments in your way?”

Roadmap
• XP — coping with change and uncertainty
• The Planning Game
– Exploration — User stories
– Estimation
– Commitment
– Steering
• Iteration

The Planning Game
A game with a set of rules that ensures that Customer
and Developers don’t become mortal enemies
Goal:
– Maximize the value of the software produced by
Developers.
Overview:
1. Release Planning: Customer selects the scope of the next
release
2. Iteration Planning: Developers decide on what to do and
in which order

The Release Planning Game
Customer Developers
Exploration Phase
Write Story
Estimate Story
Split Story
Commitment Phase
Sort Stories by Value
Sort Stories by Risk
Set Velocity
Choose Scope
Steering Phase
Iteration
Recovery
New Story Reestimate

Planning Game: Exploration Phase
Purpose:
Get an appreciation for what the system should
eventually do.
The Moves:
– Customer: Write a story. Discuss it until everybody
understands it.
– Developers: Estimate a story in terms of effort.
– Customer: Split a story, if Developers don’t
understand or can’t estimate it.
– Developers: Do a spike solution to enable estimation.
– Customer: Toss stories that are no longer wanted or
are covered by a split story.

User Stories
Principles of good stories:
• Customers write stories.
– Developers do not write stories.
• Stories must be understandable to the customer
• The shorter the better. No detailed specification!
– Write stories on index cards
• Each story must provide something of value to the customer
• A story must be testable
– then we can know when it is done
Writing stories is an iterative
process, requiring interaction
between Customer and
Developers.

Stories
A story contains:
• a name
• the story itself
• an estimate
Example:
– When the GPS has contact with two or fewer satellites
for more than 60 seconds, it should display the
message “Poor satellite contact”, and wait for
confirmation from the user. If contact improves before
confirmation, clear the message automatically.

Splitting Stories
Developers ask the Customer to split a story if
• They cannot estimate a story because of its
complexity
• Their estimate is longer than two or three weeks
of effort
Why?
• Estimates get fuzzy for bigger stories
• The smaller the story, the better the control (tight
feedback loop)

Initial Estimation of Stories
With no history, the first plan is the hardest and
least accurate (fortunately, you only have to do it
once)
How to start estimating:
– Begin with the stories that you feel the most comfortable estimating.
– Intuitively imagine how long it will take you.
– Base other estimates on the comparison with those first stories.
Spike Solutions:
– Do a quick implementation of the whole story.
– Do not look for the perfect solution!
– Just try to find out how long something takes

Estimating Stories
Keys to effective story estimation:
• Keep it simple
• Use what happened in the past (“Yesterday’s weather”)
• Learn from experience
Comparative story estimation:
• One story is often an elaboration of a closely related one
• Look for stories that have already been implemented
• Compare difficulties, not implementation time
– “twice as difficult”, “half as difficult”
• Discuss estimates in the team. Try to find an agreement.
• “Optimism wins”: Choose the more optimistic of two disagreeing
estimates.

Planning Game: Commitment Phase
Purpose:
• Customer: to choose scope and date of next delivery
• Developers: to confidently commit to deliver the next release
The Moves:
• Customer: Sort by stories by value
1. Stories without which the system will not function
2. Less essential stories, but still providing significant business value
3. Nice-to-have stories
– Customer wants the release to be as valuable as possible

Commitment Phase …
• Developers: Sort stories by risk
1. Stories that can be estimated precisely (low risk)
2. Stories that can be estimated reasonably well
3. Stories that cannot be estimated (high risk)
– Developers want to tackle high-risk first, or at least make risk visible
• Developers: Set team velocity
How much ideal engineering time per calendar month/week can the
team offer?
– this is the budget that is available to Customer
• Customer: Choose scope of the release, by either
– fixing the date and choosing stories based on estimates and velocity
– fixing the stories and calculating the delivery date

Planning Game: Steering Phase
Purpose: Update the plan based on what is learned.
The Moves:
• Iteration: Customer picks one iteration worth of the most valuable stories.
– see Iteration Planning
• Get stories done: Customer should only accept stories that are 100% done.
• Recovery: Developers realize velocity is wrong
– Developers re-estimate velocity.
– Customer can defer (or split) stories to maintain release date.

Planning Game: Steering Phase...
• New Story: Customer identifies new, more
valuable stories
– Developers estimate story
– Customer removes estimated points from incomplete
part of existing plan, and inserts the new story.
• Reestimate: Developers feel that plan is no longer
accurate
– Developers re-estimate velocity and all stories.
– Customer sets new scope plan.

Iteration Planning
• Customer selects stories to be implemented in this iteration.
• Customer explains the stories in detail to the Developers
– Resolve ambiguities and unclear parts in discussion
• Developers brainstorm engineering tasks
– A task is small enough that everybody fully understands it and can estimate it.
– Use short CRC or UML sessions to determine how a story is accomplished.
– Observing the design process builds common knowledge and confidence
throughout the team
• Developers /pairs sign up for work and estimates
– Assignments are not forced upon anybody (Principle of Accepted
Responsibility)
– The person responsible for a task gets to do the estimate

Test-Driven Development (TDD)
(influenced by XP “test-first programming” )
1. broken down into small, client-valued features to be developed in shortest
possible development cycle.
2. feature studied for client requirements and specifications and tests are written.
3. These tests are failing tests written prior to the feature development.
4. Production code written is just enough to fail the test.
5. Another code is written, which is then made to pass all the earlier tests.
6. Based on the results after testing the code, programmer follows one or all
:Test → Code → Refactoring

TDD
• All the tests are collected in a suite called the “test-suite,”
• each suite is run frequently - each time a code is written and passed,
the entire suite re-runs
TFD coupled with refactoring is TDD.

Acceptance Test Driven
Development Cycle
Discuss the
requirements
Distill the
tests in a
friendly
format
Develop the
code (and
hook the
code to the
tests)
Demo the
code

• Rapid and reliable results:
• Constant feedback:
• Flexibility:
• Iterative development of features:
• Reduced debugging time:
• Easy documentation:
Write the test
Write the code
to pass the test
Improve the
code while
keeping the
test passing

Types of Tests
• Unit Tests
• Integration Tests
• End-to-End Tests
• Exploratory Testing

Unit Tests
• Focus on a class or a method
• Tests the smallest unit possible
• Typically tests simple objects;
does not test things such as:
– Database communication
– Network communication
– File system manipulation

Integration Tests
• Tests functions, “does things”
• Tests interactions with the outside
world, include:
– Database communication
– Network communication
– File system manipulation
• Focused integration tests isolate the
testing to one interaction at a time
• Integration tests should run on their
own, with a little help from 2
fundamental units:
– Setup – run at the beginning of the
test to set up the test environment
– Tear-down – run at the end of the
test or upon error to clean up the
test environment

End-to-End Tests
• The most brittle of tests –
dependent on the big picture
• Verifies that the unit tests and
integration tests are working
like they should
• Start at the beginning and go
through the whole process
• Includes:
– Acceptance testing
– Functional testing

• Kanban emphasizes just-in-time delivery for developing products
and processes.
• Work is queued according to the desired priority to ensure
relevant incremental delivery.
• Entire process of work completion is made transparent to help
stakeholders track project progress.
Kanban
• Lean Product Development uses the lean manufacturing and lean
IT principles deployed in the Toyota Production System in
the software development domain.
• Lean Product Development practices are different from the other
Agile methods, making use of value stream mapping, queuing
theory, and other techniques for product development.
Lean Product
Development

看板 – Kanban cards limit
excess work in progress
• 看板 – Kanban literally means
“visual card,” “signboard,” or
“billboard.”
• Toyota originally used Kanban
cards to limit the amount of
inventory tied up in “work in
progress” on a manufacturing
floor
• Not only is excess inventory
waste, time spent producing it is
time that could be expended
elsewhere
• Kanban cards act as a form of
“currency” representing how
WIP is allowed in a system.

Using a Kanban approach in
software drops time-boxed
iterations in favor of focusing on
continuous flow.

1. Define a work process flow
Look at the typical flow for features, stories, or work packages and describe
typical process steps
This simple process flow has the steps:
1.elaboration & acceptance criteria
2.development
3.test
4.deployment

2. Lay out a visual Kanban board
Place a goals column on the left, then a waiting queue, the process steps,
and a final “done” column to the right
Place an expedite track above the main
left to right queue
Place “done and waiting” queues between
each work queue
(in this example they’re placed below)

3. Decide on limits for items in
queue and work in progress
A good limit is a factor of the number of people in a role that can work on an item
in a given process step. Start with number of people * 1.5
This board uses painters tape to indicate
available “slots” for work in progress

4. Place prioritized goals on the
left column of the board
A good goal describes the outcome we hope to achieve after software
ships. Goals help keep focus on the larger outcome.
Having goals visible:
•promotes focus
•helps us prioritize
•helps us manage feature scope &
requirements

5. Start the board by placing
stories or features in queue
Mark on the story or feature card the date it entered the queue. This begins our
measurement of cycle time.
Product owners manage the waiting
queue

6. Move features through the
process flow as work is completed
As the story enters the first process step, mark that date on the card. This is the start
date. As it’s finished, mark that date on the card. This is the finish date.

7. Use the dates on the cards to
calculate cycle time
Use average cycle time to set wait times from different points on the board. Pay
attention to flow and bottlenecks: relieving bottlenecks as quickly as possible.
Cycle time = finish date – start date
The average cycle time from the date the
item enters the board is the wait time
from this point in the queue

Explode large process steps into
tasks to improve visibility
• When a feature, user story, or work item is large:
 Takes longer than a couple days to complete
 Requires that multiple people collaborate on its completion
• Decompose that step into cards to track independently
Feature to
develop Tasks in queue
Tasks in
progress
Tasks
complete
Feature
complete

Kanban Board with Task
Decomposition

Work-in-Process
113
 High work-in-process leads to longest lead times
 Low work-in-process greatly reduces lead times
 Results in better customer trust and satisfaction
Bad Project
0
35
70
105
140
175
10/9 10/23 11/6 11/20 12/4 12/18 1/1 1/15 1/29 2/12 2/26
Time
Features
Inventory Started Designed Coded Complete
Good Project
0
48
96
144
192
240
2/10 2/17 2/24 3/2 3/9 3/16
Time
Features
Inventory Started Designed Coded Complete

Use cumulative flow diagrams
to visualize work in progress

Cumulative Flow Diagram2/21/2008
2/28/2008
3/6/2008
3/13/2008
3/20/2008
3/27/2008
4/3/2008
4/10/2008
4/17/2008
4/24/2008
5/1/2008
5/8/2008
5/15/2008
5/22/2008
5/29/2008
0
20
40
60
80
100
120
140
Deployed
Testing
Construction
Architecture / Design
Requirements
Total Scope (Features)
Date
TotalFeatures

Limiting Work in Progress
• Reduce multi-tasking
– Prevent context switching
– Performing tasks sequentially yields results sooner
• Maximize throughput
• Enhance teamwork
– Working together to make things done
– Increase cross-functionality

Scrum and Kanban
 Scrum defines rules that need to be followed and is prescriptive in nature.
Kanban is adaptive. The only constraints in Kanban are visualization of work
and limiting WIP.
 The Scrum board is reset after each iteration; the Kanban board is normally
persistent.
 Both Scrum and Kanban are empirical.
 Scrum prescribes cross-functional teams; In Kanban , cross-functional teams
are optional as the Kanban board is not owned by any particular team.
 Scrum backlog items must fit into a Sprint. Kanban teams try to minimize lead
time and level the flow, and indirectly create an incentive to break items into
relatively small pieces.
 Scrum prescribes estimations of team velocity, Kanban does not
 Scrum and Kanban allow teams to work on multiple products simultaneously.
 Scrum requires backlog prioritization of the backlog, Kanban has a backlog
 Scrum prescribes daily meetings, but Kanban does not.
 Scrum uses burndown charts, Kanban uses Cumulative Flow Diagrams.
 Scrum uses velocity as the default metric. Kanban uses lead time.

Value Stream Mapping
Value stream mapping is a lean manufacturing technique used to
analyze the flow of materials and information currently required to
bring a product or service to a consumer. At Toyota, where the
technique originated, it is known as “material and information flow
mapping”. It can be used in any process that needs an improvement.”
• The Value Stream is the series of work steps performed to deliver the end
product from concept to deployment
• Purpose: Visualize the workflow from concept to cash
• Value-Added Work
– The discovery, creation and transformation of knowledge into working
code, features and systems that customers use to achieve their goals
• Non Value-Added Work (waste)
– Bottlenecks that create delays or add to calendar time
– Activities that consume resources yet don’t add value to the customer

The process of value stream mapping involve the following steps:
 identifying and categorizing various families of value streams
 mapping the various identified value streams into various process areas and
inventories
 measuring things such as cycle time, value generation time, and waste for the various
value streams
 performing root cause analysis on the areas with the worst ratio of value to non-value-
added activities
Value Stream Mapping Process

Mapping the Value Stream at
the Agile Process Level
Concept
Deployment
Business need
identified
Portfolio team -
Meet with the
business to
define needs
Meet with AD to
initiate project
Staff project with
product owner
and define team
size, and duration
PO Determines
goals, vision and
backlog
Portfolio team
prioritizes multiple
customer needs
Sprint n planning:
task breakdowns
etc.
Initial scope
identified for the
release
Identify story
points required in
all the backlog
Start working on
next sprint’s
stories (1-2
sprints ahead)
Scope for sprint n
defined
Development &
Testing
Release Planning Sprinting
Plan for
production
release
Release to
Production
Total Time: 140 Days
Value-Added Time: 20 Days
% Value-Added: 15%

Principles of Lean - Agile
• Lean means elimination of waste
• Lean creates process speed by eliminating waste
• Lean improves efficiency quality by eliminating waste
(minimizing time, capital invested, and cost)
• Lean = continuous improvement
Lean eliminates waste through such practices as:
• Selecting only the truly valuable features for a system,
• Prioritizing those selected, and
• Delivering them in small batches”

Seven Simple Rules/Principles
• Eliminate Waste: spend time only on what adds real customer
value
• Amplify Learning: When you have tough problems, increase
feedback
• Decide as late as possible: Deliver value to customers as soon as
they ask for it
• Deliver as fast as possible: Deliver value to customers as soon as
they ask for it
• Empower the team: Let the people who add value use their full
potential
• Build integrity in: Don’t try to tack on integrity after the fact – build
it in
• See the whole: Beware of the temptation to optimize parts at the
expense of the whole

Waste – What is it?
• Any process, machine, product that does not create value for
the customer
• MUDA – Japanese term for waste
• Why bother – it is estimated that 90% of all activity is waste

Reasons Why Services are Full
of Waste
• Service processes are usually slow process
– Slow processes are prone to poor quality
– Cost of Slow processes = 50% waste
• Processes are slow because there is too much work in
progress (WIP)
– Items in progress can spend 90% of their time waiting for the
next step
– Drives cost up
• Slow processes tend to have 80% of the delays caused by
20% of the processes

Eight Wastes of Software
Development
• Partially Done Work
• Extra Processes
• Extra Features
• Task Switching
• Waiting
• Motion
• Defects
• Underutilization of Employees
Note: As defined by Mary Poppendieck

Kaizen
• Kaizen is a Japanese term that means ‘continuous improvement’.
Japanese word that means to make small changes for the better
– Kai means change
– Zen means good
• It is generally accepted that the first step towards creating a truly lean
organization is to identify and manage waste.
• Changes are best when they are created by the person doing the work
• The person doing the work uses their own common sense and intuition

Principles of the Agile
Manifesto
Kanban/Lean Scrum XP DSDM Crystal FDD
Our highest priority is to
satisfy the customer through
early and continuous delivery
of valuable software.
Visualization of
top priority
items
Pull system of
work
assignment
Value-based
prioritization
Shippable
software after
each Sprint
Sprint Review
Meeting
Customers and
developers work
together to plan
releases
Build customer
feedback into
each iteration to
converge on an
effective
business solution
Early victory
Walking skeleton
Frequent
customer
feedback
Client-value based
features
Short ramp-up for
modeling
Welcome changing
requirements, even late
in development. Agile
processes harness change
for the customer's competitive
advantage.
Business
people can
change and re-
prioritize work
not yet started
at any time
Product Backlog
grooming
Re-prioritization
after each Sprint
Iteration planning -MoSCoW Re-calibration of
the release plan
Frequent user
feedback
Domain-based
model fosters
change
Short cycles with
complete features
allow for frequent
change
Deliver working software
frequently, from a couple of
weeks to a couple of months,
with preference for the shorter
timescale.
Work released
on demand
Sprints
(iterations)
Iterations Develop
iteratively in time-
boxes
Iterations Increments (per
feature) <= 2 weeks
Iterations (1 or more
complete features
Business people and
developers must work
together daily throughout the
project.
Highly
collaborative
PO as VOC
PO readily
available to team
on a daily basis
Customer is part of
the team
Involve the right
stakeholders, at
the right time,
throughout the
project
Easy access to
expert users
Frequent
feedback from
end users
Client interaction
during processes #1
and #2
Frequent demos
with customer
feedback
Comparison of Agile Methods

Manifesto
Build projects around
motivated individuals.
Give them the
environment and support
they need and trust them
to get the job done.
SM is only facilitator
Self-organizing teams
Demo /acceptance
after each sprint
Open work space
Pairs evolve as
needed
Process
miniature makes
sure team
members
understand the
process well
Team decides
improvement/
changes
Domain experts
Class ownership
However, there is
Team leadership
Assignment of team
membership based
on expertise
The most efficient and
effective method of
conveying information to
and within a development
team is face-to-face
conversation.
Co-located teams
Daily Stand-up
Meetings
Co-located teams
Daily Stand-up
Meetings
Co-located teams
Daily Stand-up
Meetings
Co-located teams
for Crystal Clear
Osmotic
communication
Daily Stand-up
Meetings
Multiple, small
teams
Joint design,
inspections, and so
on
However, a lot of
information sharing
via CMS
Working software is the
primary measure of
progress.
WIP limit Working software at
the end of each Sprint
No technical debt
TDD
-Egoless
software
Deliver “good
enough” early
instead of
“perfect too late”
Walking skeleton
Automated tests
Frequent
integration
Inspections
(Unit) tests
Agile processes promote
sustainable
development. The
sponsors, developers, and
users should be able to
maintain a constant pace
indefinitely.
No fix release or
delivery dates
Limit of WIP
forces completion
or work packages
Velocity
Done criteria (only
complete/done work
counts)
Iteration planning
Sustainable,
predictable pace
Blitz planning Clearly defined
entry/criteria per
process
Only completed
work counts

Manifesto
Continuous attention to
technical excellence
and good design
enhances agility.
Refactoring Continuous
integration,
refactoring, and
building often
Incremental re-
architecture
Domain object
model as base
Frequent updates
Simplicity—the art of
maximizing the amount of
work not done—is
essential.
Small user stories
Continuous re-
evaluation and
reprioritization
Small user
stories
Continuous re-
evaluation and
reprioritization
Small features
Focus on client
value
Good upfront
design/model
The best architectures,
requirements, and
designs emerge from self-
organizing teams.
No team leader
Team commits
Team member select
tasks
Pair
programming
Team coding
standards
Members of the
team empowered
to make
decisions on
behalf of those
they represent
without waiting
for higher-level
approval.
Side-by-side
programming
Team consensus for
domain object model
Small teams foster
cooperation across
expertise
boundaries
At regular intervals, the
team reflects on how to
become more effective,
and then tunes and
adjusts its behavior
accordingly.
Sprint Retrospective
Meetings at the end of
each Sprint
Sprint
Retrospective
Meetings after
each iteration.
Improving the
process is part of
the development.
Facilitated
workshops
Reflection
workshop
The 6 milestones
per feature allow for
frequent checks for
improvements
However, no
reflections are
prescribed

Key Terms for Exam
• Agile Manifesto
• Agile principles
• Agile terms – Release (common), Iteration
(Sprint)
• All Agile methods
• Difference between waterfall & agile
methodologies (simple case studies)
• Value Streams
• Kanban

2 a introduction to agile

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 2 a introduction to agile

Semelhante a 2 a introduction to agile (20)

Último

Último (20)

2 a introduction to agile