Agile Manifesto

Individuals & Interactions Over Process & Tools

Working Software Over Comprehensive Documentation
Customer Collaboration Over Contract Negotiation
Responding to Change Over Following a plan

Key Drivers for Agile Adoption

More User Involvement More synergy with busienss and IT
Cost advantage right sourcing & rapid development - global

Competitive Advantage Shorter Feature Release

Reduced Time to market Ability to adpapt evolving business needs

Scrum

Iterative & Incremental framework

Iterative cycles known as sprint

EOS - tested integrated Working software and potentially shippable

Sprints are time boxed & occur sequentially

End date of sprint does not get extended- irrespective of completion/no

Scrum Roles
Product Owner Team
Team size should ideally be around
Providing the vision of the project to the team (+/- 2)

•Maximizing the value of the project and the work of the Scrum Team Recommended to be crossfuncti

Self-organized and decides what to

•Managing the Product Backlog how best to accomplish that comm

Accountability of the work produc

•Clearly expressing Product Backlog items team as a whole
•Prioritizing the items in the Product Backlog

•Ensuring that the Product Backlog is visible, transparent and clear

•Change to a Product Backlog item’s priority has to discuss with the Product Owner

Scrum Events

Establish a plan and goals, which the Scrum Team and the rest of the organization ca
• Turn the vision into a successful project in best possible way
• Meet or exceed the desired customer satisfaction and return on investment
• Establishes the goal of the release, high-priority Product Backlog items, major risks
Release Planning Meeting • A probable delivery date is agreed upon; the stakeholders can inspect the progress
• Work to be performed in a Sprint is planned
• Plan is created by collaborative work of the entire Scrum Team
• Consists of two parts, each one being a time-box of half of the Sprint Planning Mee
In the first part, team plans what will be delivered as part of the Sprint
Sprint Planning In the second part, team plans how to build this functionality

• 15-minute time-boxed event for the team

• Improve communication
• Identify and remove impediments to development
• Highlight and promote quick decision-making
Daily Scrum • Improve the Scrum Team’s level of project knowledge

• Held at the end of the Sprint

• Scrum Team demo’s what was developed in the sprint to the stakeholders
• Receive feedback on the progress made so far and decide the next course of action
• Provides valuable input to subsequent Sprint Planning Meetings
The Sprint Review includes the following:
 Product Owner identifies what has been ‘Done’ and what has not been ‘Done’
 Team demonstrates the work that has been ‘Done’ and answers questions about th
 Product Owner discusses the Product Backlog as it stands
Sprint Review  The entire group discusses on what to do next

• Inspect the last Sprint with regards to people, relationships, process and tools
• Discuss what went well during the Sprint, what problems were faced and how they
• Identify and prioritize the major items that went well and those which could have b
• These include Scrum Team composition, meeting arrangements, tools, ‘Definition o
• Create a plan for implementing improvements to the way the Scrum Team works
Sprint Retrospective • Scrum master & team attend this meeting

Clear idea on what is required and what should be the outcome

• main purpose of conducting workshops is for gathering, understanding and prioriti
Workshops • workshops are worthwhile to do once in every 6 months, just to review the directio

• Brings a lot of client confidence as they are able to see progress of development of
• Share the status with the Product Owner and business users about the progress of
Mid Sprint Demo • Helps in bridging the gap between the understanding of the project team and expe
 Extreme Programming

The term XP is conceptualized from the execution of traditional software en

Features >> Fine Scale Feedback >> Continuous Process >> Programm
Fine Scale Feedback

1. Planning Game: To ensure Work is planned incrementally - Divided into two parts
Release Planning : Meeting to shortlist requiements to be included in the releases planned and timeline of each release
Exploration (create user story) >> Commitment (Team commits to date and functionality) >> Steering (Adjust plan and require
Iternation Planning: Meeting by the team to decide upon the tasks and activities, to accomplish requirements planned for the
Exploration (Create task cards)>> Commitment (Task estimation & allocation) >> Steering (Perform the tasks)

2. Pair Programming :
• Coding is generally followed with code review, and in the extreme case, coding and review can happen in parallel.
• Two persons work on the same code. While one programmer is doing the coding, focusing on the code and program level de
• The pairs are not fixed and keep on changing thereby helping everybody to be aware of the entire system

3. Test Driven Development

• Developer writes the automated test cases before the actual code is written
• Automated unit test cases should inevitably fail at the first attempt of run. If it does not fail, it indicates the feature already e
• The code is written and the automated test suite is run. Based upon the result, the code is modified
• The units are usually kept small and code is refactored as and when required

4. Whole Team
• Team members are encouraged to be more generalized than specialized
• Customers are included as part of the Team who are always available to respond to the queries and provide clarifications.
Continuous Process

1. Continuous Integration
• Code base is integrated on a frequent basis from the start of the feature development
• An automated process in which builds are created from the common source code repository
• Helps in identifying integration issues much ahead in the lifecycle which reduces much of the rework cost

2. Refactoring
• Regular improvement of existing design and code without affecting the functionality
• Helps to improve the overall code quality

3. Small Release
• Smaller releases are planned which provide customer the confidence of the overall progress
• Helps customer to provide suggestions for any changes and helps to meet the overall goal
Shared Understanding
Coding Standards:
Rules need to be as per the standards defined by language vendors and/or customized by the Team

Collective Code Ownership

Since the Team is cross-functional and entire team works in pairs which keep changing, all parts of the code are known to ever

Simple Design
XP recommends the simple and best way to implement code Refactoring also facilitates this process of achieving simple desig

Metaphor A naming convention, which makes all the stakeholders understand what the functionality is all about in detail

Programmer welfare:
• Team members need not work for more than 40 hours per week (ideally) to meet project deadlines as it hampers repeatable

Extreme Programming (XP) : Roles

Customer >> •Creates user stories and prioritizes user stories •Addition/Modification/Deletion of user storiesCustomer
Programmers >> •Estimates for user stories along with the Team •Builds the users stories as per the standardsProgrammers
Coach >> •Monitors XP process implementation •Issue resolution on XP practices •Mentors team members
Tracker >> •Monitors the progress •Alerts the TeamTracker

KANBAN - Visual Board

Visualize Work Stages >> Limit Work in Progress >> Measure & Manage Flow >>

Defining WIP limits: “Stop starting and Start Finishing”

WIP limits could be set based on history data and capacity planning
Tickets gets piled up in one stage other team members help their team members so that tickets movement is smooth, thereby
WIP limits defined could be observed for 3 to 4 weeks and updated based on team’s experienc

Kanban Metrics
Cycle Time/ Production Lead Time Time that elapses from the moment a team starts actively working on a task till the m
Customer Lead Time Time that elapses from the moment a customer or a user submits the work item to a
Throughput A measure of productivity or efficiency which is typically a number of features delive
Work in Progress Number of work items that are currently in progress in the whole process
Customer Takt Available work time / customer demand during available work time
Cumulative Flow Diagram - CFD helps the team to visualize overall effort spent and the project progress

SCRUMBAN
Hybrid of Scrum and Kanban and was originally designed as a way to tr
Can be applied to >> Maintenance Projects
Projects with Frequent and Unexpected User Stories or Programming Errors Sprint Teams focused on ne
Work Following Sprint Development If Scrum is challenged due to workflow issues, resources or processe

ScrumBan Advantages Improved Quality

 Minimizing Waste (all that is not adding value to the customer

Scaled Agile : Application in Projects

Based on Proven success pattherns for implementing Lean-Agile IT, software & systems development at enterprise scale
Allows Organizations to adapt to its business needs, by supporting smaller scale solutions to complex systems requiring thousa
Four Core Values of Alignment, Built-In Quality, Transparency, Program Execution
Define Roles & Responsibilites providing complete guidance for scaled agile execution

Lowest Level Team Kanban/ Scrum/ XP

Program Level Agile Release Train (ART), Typically 50-125 persons including agile teams & Stakeohld
Large Solutions/ Portfolio Multiple ARTs, Common Enterprise Level Objectives

Disciplined Agile Delivery (DAD) Agile Development

Stakeholder Value Driven Life Cycle
Team Lead Self Organizing teams
Product Owner Focus on construction of work

Team Owner Project team aware

Architecture Owner Prescriptive

Large Scale Scrum (LeSS)

Applies principles, purpose, elements and elegance of scrum in a large-scale context
Teams have a common goal to deliver one common shippable product at the end of a common sprint
Each team is 1. self managing 2. cross-functional 3. co-located & 4. long-lived
Scrum Mastes are responsible for a well-working LeSS adoption
Managers (optional) role is to improve Product development system (Go see, Stop & Fix, experiments over conformance)
One product Owner and One Product Backlog for the complete shippable product
PO is supported by multiple teams working directly with customers/users and other stakeholders

Spotify
Squad - similar to scrum team has one PO
Tribe - collection of squads < 100
Chapter - Group of ppl having similar skills in a tribe
Guild - Group of ppl ppl having similar skill across the tribes (organizational level)
 Agile Principles
Customer Satisfaction By rapid delivery of useful software
Welcoming Changing Requirements Even late in development
Delivered Frequently Weeks rather than months
Working Software is Principlal measure of progress
Sustainable Development Constant pace
Daily Co-operation business people and developers
F2F Conversation Best communication
Project built around motivated and trustworthy individuals

Continuos attention technical excellence & good design

Simplicity self organizing teams
Regular Adaptation Changing circumstances

SCRUM ARTIFACTS

* Product Vision at start of the project

*Refined & Prioritized list of features or req
Product Backlog - PO *Continuous update by PO

*Chart Reflects remaining Product Backlog items across the releases

Release Burndown * Available to all stakeholders of the project

* Highly visible, real time pic of the work that team plans to
accomplish during the sprint
* Subset of Product Backlog Items
* Comprises of all the tasks that team identifies as necessary to
Sprint Backlog meet the sprint goal

* Grpah shows remaining effort for all the tasks that are committed
Sprint Burndown during sprint, versus time (days remaining in sprint)

Scrum Roles
Team Scrum Master
Team size should ideally be around seven persons
(+/- 2) Helps the Scrum team to adopt Scrum
Helps the team to learn and apply Scrum to achieve the desired
Recommended to be crossfunctional with skills objective of the project

Self-organized and decides what to commit and Does not tell people what to do or assign tasks, but facilitates the
how best to accomplish that commitment process

Accountability of the work product belongs to the Serves the Team, protects them from outside interference, educates
team as a whole and guides the Product Owner and the Team in use of Scrum
 Facilitates Scrum events • Coaches the Team to be crossfunctional
• Removes impediments for the Team’s progress

Scrum Master cannot be the Product Owner, manager of the Team

or the Project Manager

Scrum Events

m and the rest of the organization can understand and communicate

possible way
on and return on investment
y Product Backlog items, major risks and overall features and functionalities
akeholders can inspect the progress and make changes to this release plan on a Sprint-by-Sprint basis

tire Scrum Team

x of half of the Sprint Planning Meeting duration
d as part of the Sprint
unctionality

ent

wledge

e sprint to the stakeholders

and decide the next course of action
anning Meetings

and what has not been ‘Done’

one’ and answers questions about the increment
s it stands

elationships, process and tools

problems were faced and how they were solved
t well and those which could have been done differently
ng arrangements, tools, ‘Definition of Done’ and methods of communication
to the way the Scrum Team works

be the outcome
athering, understanding and prioritizing requirements, mainly during the Initiation phase
6 months, just to review the direction of the project

e to see progress of development of actual software

usiness users about the progress of the Sprint
anding of the project team and expectations of the customer
 Extreme Programming

execution of traditional software engineering practices at extreme levels

> Continuous Process >> Programmer Welfare >> Shared Feedback

and timeline of each release

>> Steering (Adjust plan and requirement change)
plish requirements planned for the iteration
Perform the tasks)

w can happen in parallel.

ng on the code and program level details, the other programmer has the big picture and continuously reviews the code
he entire system

ail, it indicates the feature already exists or there are some problems with the automated test case
is modified

queries and provide clarifications.

tory
f the rework cost

ress
al
the Team

parts of the code are known to everybody In case of error, any programmer is allowed to change the code

is process of achieving simple design

nctionality is all about in detail

t deadlines as it hampers repeatable, predictable and consistent delivery

etion of user storiesCustomer

s as per the standardsProgrammers
rs team members

KANBAN - Visual Board

Setup Explicit Process & Policies >> Implement Feedback Loop

ckets movement is smooth, thereby increasing collaboration

Kanban Metrics
s actively working on a task till the moment they are done
or a user submits the work item to a backlog to the moment they can use it
ypically a number of features delivered over time
ress in the whole process
available work time
nd the project progress

SCRUMBAN
as originally designed as a way to transition from Scrum to Kanban
Event Driven Work Help Desk Support | Hardening/ Packaging Phases
Sprint Teams focused on new product development | Work Preceding Sprint Development (Backlog, R&D)
rkflow issues, resources or processes | To manage improvement communities during/ after scrum roll-out

Short Lead Time Kaizen (Continuous improvement )

 JIT - Just-In-Time approach to decisions whenever needed

aled Agile : Application in Projects

velopment at enterprise scale
o complex systems requiring thousands of people

Scrum of Scrum (SoS) meetings:

What the Team accomplished since last meeting
What the team will accomplish from now to next meeting
ns including agile teams & Stakeohlders Any roadblocks

Disciplined Agile Delivery Agility at Scale

Risk + Value Driven Life cycle Team size
Self Organizing within appropriate gove Geographic Distribution
Focus of delivery of consumable services Organization Distribution

Enterprise Aware Compliance

Context Sesitive and goal driven Domain Complexity
Technical Complexity

xperiments over conformance)

 Methodologies in Nutshell
Daily Scrum
Release and Sprint Planning
Sprint Reviews & Retrospectives
Scrum
Burndown Charts
Product Backlog & Sprint Backlog
Story Point Estimation
Pair Programming
Test Driven Development

Continuous Integration & Testing

Refactoring
Extreme Programming Simple Design
Release and Iteration Planning
Small Releases

Shared Understanding through collective code

ownership & methaphor

Domain Object modeling

Feature Driven Development

Inspections

Regular Build
Feature Teams

Development by Feature
Prototyping
Functional Modeling

Continuous Testing

Dynamic System Development Time Boxed Development

Method

Requirement Workshops

MoSCoW Proritization
 Methodologies Compared
Waste Elimination
Value Stream Mapping
Lean
Pull System
Measurements
Limit Work in Progress
Kanban Visualize & manage workflow
Implement Feedback Loops
Just-in-time cards
Scrumban Daily Scrum (Planning, review,
retrospective as needed
Continuous Improvement

Scrum XP
Board/ Artifacts Product Backlog, Sprint Backlog Release Plan, Metaphor, Iteration P

Ceremonies Daily Scrum, Sprint Planning, Sprint Re Daily Meeting, Planning Game on

Prioritization Part of Backlog Grooming done by PO Done by customer

Who feeds the work in

progress
(bring new work) PO Customer Representative or proxy

Iterations Yes (sprints) Incremental Improvements

Estimations Yes Yes

Teams Must be cross-functional Cross-functional preferred

Roles Product Owner/ Scrum Master/ Team Customer/ Programmer/ Coach
Teamwork Collaborative as needed by task XP Engineering Practices

WIP Planned for duration of sprint Planned for duration of iteration

Changes to Work Scope Should wait for the next sprint Swap with items of similar size

Product Backlog Prioritized list of User Stories Prioritized

Impediments Dealt with immediately Dealt Immediately

 InfyAgile Methodology Scrum Extreme Programming
Requirement Workshops
Burndown Charts $$ $$
Daily Stand Up $$ $$

Mid-Sprint Demo

Standardized Estimation
Technique

Quantitative Project
Management

Risk Management

Measurement Focus

$$ $$
EPICS & User Stories

$$ $$
Product Backlog & Sprint
Backlog
 Simple Design $$
Build Automation $$
Automated Continuous $$
Integration
Test Automation & $$
Continuous Testing
Test Driven Development $$
 Kanban Scrumban
Board mapped on process Board mapped on process

Daily scrum, Other Scrum

None required Related events if needed

Out of process, there should be a

Out of process, there should be a pprioritized backlog

Depends on defined roles &

Depends on defined roles & respons
responsibilities

Not mandatory (Continuous

No (Continuous Flow) flow), could have sprints
No (Similar Size) No (Similar Size)

Cross-functional or specialized Cross-functional or specialized

As needed Team + Needed roles
Swarming to achieve goals Swarming to achieve goals

Controlled by workflow state Controlled by workflow state

Added/ removed as needed (JIT) Added/ removed as needed (JIT)

no (JIT) no (JIT)

Avoided Avoided
 Infosys Recommended Best
DSDM Practices
$$

$$

$$

$$

$$

$$

$$
$$

$$
$$
$$

$$