The document outlines best practices for a workshop on nearshore agile development, emphasizing alignment on agile practices, tools, and expectations among clients and teams. Key topics include defining roles, agile process alignment, effective communication tools, and risk management strategies for distributed teams. The workshop also covers the importance of establishing a shared definition of 'done,' tracking methods, and mechanisms for continuous improvement.

2. Nearshore Agile
Development Best
Practices Workshop
2

3. Workshop Objectives
Align with our clients on agile practices.
Set reasonable expectations
Mitigate difficulties of Distributed Agile Software
development
Agree on tools to be used, meetings to be held,
agile ceremonies to be practiced, etc.
Recommend Solutions based on our experience
Listen to the client’s concerns regarding agile
and come up with possible solutions.
3

4. Workshop Agenda
Distributed Meeting Management
Roles
Agile Process
Alignment
o Scrum / Kanban
o Tracking
o Artifacts
o Quality, Velocity, and Definition of Done
Risks and their Management
4

5. Meetings
As agile practitioners, we put individuals and interactions
over processes and tools. The use of video when
communicating improves the quality of interactions,
facilitates feedback and is the warmest kind of
communication we can have being distributed.
o Some tips to keep in mind: make sure lighting is adequate; orient
people to face the camera; individual cameras (versus room
cameras) are preferred.
5
Video Usage
Tools we propose:
GoToMeeting
(recommended)
Skype
Google+
Screen sharing only:
Join.me

6. Roles & Responsibilities
6
It’s important to clearly define roles and responsibilities when
starting any kind of project. When being distributed, even more!
Take the time to establish team and cross team roles and how
interactions are expected to happen.
Focus on have clear understanding of the following roles (at least):
o Product Owner
o ScrumMaster
o VP Team Lead
o Solutions Manager
o Client Stakeholders: who and what responsibilities?
o Other Roles: QA lead, build management, others?

7. Agile Process Alignment
Take time to discuss the following items in order to
be aligned
How agile is the group of people that the VP team will be interacting
with?
How agile do we want to be ?
Scrum Process and Meetings
o Sprint cadence: ? weeks
o Required meetings, timing, agenda, prep, and attendees.
7

8. Agile Process Alignment
Choose appropriate tools to support agile practices in a
distributed model.
o E.g. TFS, JIRA, Rally, VersionOne, Assembla, TargetProcess, etc.
o Document repository? (e.g. wiki, Google Drive, Confluence, etc.)
Go through the following discussions:
o Tracking Methods
o Deliverables and Artifacts
o Quality Practices
o Expected Velocity
o Definition of Done
8
Tools

9. Scrum or
Kanban?
9

10. Scrum Process
10

11. Scrum Meetings
Scrum proposes the following ceremonies
1. Product Planning
2. Release Planning
3. Sprint Pre-Planning (“grooming”)
4. Sprint Planning
5. Stand-up
6. Sprint Demonstration
7. Sprint Retrospective
11
This doesn’t mean that they all will be useful in
our specific project.

12. Scrum Meetings
The key is choose the ones that we
consider will add value to our processes.
Inspect and adapt: remove unnecessary
meetings and add as necessary.
12

13. Kanban Process
Overview of Process
Work States. Define them and make sure everyone
has a deep understanding of them.
Establish adequate WIP Limits.
Card Ownership.
13

14. Tracking Methods / Development
Artifacts
Take time to sync up about the expected tracking
methods
Also sync up on understanding and importance of
concepts like velocity, story points, etc.
We find the following charts quite useful to
document the selected tracking methods.
14

15. Tracking Methods
15
Stories / PBIs Tasks
How is work estimated?
How is progress measured?
How is velocity measured? (not applicable)
What are the statuses?
Working at
task level?
Are bugs/defects treated differently than a story / task?

16. Development Artifacts
16
Content and Format Who Does?
Tracking Board
User Story / PBI
Specification
(see next slide for example)
UI Design
Task / Card
Test Case
Ticket (for bug or
issue)
Documentation
(classic)

17. Software Quality Assurance
Development Process Improvement – KPIs, e.g.:
o Velocity
o Estimation accuracy
o Code quality
o Functional quality
o Others?
Quality Planning
o Role, if any, of stories and tasks in testing
Quality Practices
o Internal code quality
o Testing roles and practices
o Approaches and environments
17

18. Testing
18
Responsible Party Practices and Tools
Unit
Functional
System
Integration
Regression
Performance
Acceptance
Role of TDD / BDD
Environments to be used (dev, QA, staging, etc.)
Automation?

19. Expected Velocity
Establish velocity expectations from both sides.
The Velocity of the team will depend on a number of
variables, as the ones on the next slide. Make sure
both parties are aligned on the understanding and
importance of those variables.
19

20. Expected Velocity
Ramp-up expectation (three iterations?)
Use of spikes in stories ?
Goal of first iterations: learning, delivery?
Approach to technical debt
Approach to changes during sprint
o Re-cap: changes in requirements
o Re-cap: changes in estimates and commitment
Absence planning (holidays and vacations)
20

21. Definition of Done
This is an area of truly focus on when working
on distributed teams.
Make sure we are aligned on the Definition of
done criteria on the Task, Story, Sprint and
Release level.
21

22. Definition of Done examples
22
Task:
•Implemented
•Unit Tested
•Code commented
•In source trunk
•In CI build
•Coverage
•Standards met
•Tracked
•Other metrics?
Story:
•AC met
•All agreed tasks
done
•Functionally tested
•All known bugs
fixed
•Documented for
user view
•Story test updated
•Integration tested
•Installation works
•Smoke-tested
Sprint:
•Sprint end date
reached
•Completed stories
demo’d
•Retrospective held
and documented
•Product backlog
updated
•Performance tested
•Regression suite
updated
•All bugs closed or
postponed
•Documented for tech.
view
Release:
•All agreed sprints
done
•Integration tested /
hardened
•Documentation
“tested”
•Install packages
complete
•Release notes
•Marketing collateral
•Regression test
complete
•External testing
•PO sign-off

23. Risk Management
23
Be aware of risks involved in agile development, and
take into account that being distributed sometimes
add more risks.
This is our introduction to Risk Management in 2 steps.
o 1 Awareness of possible risks.
o 2 Assessment and mitigation plan.

24. Possible Risks
24
Needs
•Product Owner participation and clarity / distance from business customer
•Incomplete acceptance criteria
•Developers unclear / unquestioning during story elucidation
Plan
•Expectations for ramp-up
•Unrealistic, business-driven deadlines
•Planning at too high a level / inaccurate estimations
Commit-
ment
•Commitments when there should not be commitments
•No measures of productivity
Delivery
•Velocity / blockers early warnings and visibility
•Not enough time / attention to functional testing
•Poor definition of / adherence to agile processes, e.g. mid-sprint changes

25. Risk Assessment
25
Risk Area Specific Risk Priority
(H/M/L)
Mitigation Strategy
Communication
(access, infrastructure, response, 3rd parties, etc.)
Requirements
(client or team participation, too many layers,
incomplete acceptance criteria)
Planning
(ramp-up / deadline expectations, planning too
high, poor estimating)
Commitment
(team being “sure”, lack of metrics)
Delivery
(attention to blockers, lack of QA, adherence to
agile processes)
Personnel
(roles, skills, motivation, conflict)
Other

26. Workshop Action Plan
Specific Action Items
o Action Item #1: (establish ad hoc meetings for example)
Future Use of Workshop Output
o Use #1:
26
Workshop Retrospective
What went well?
What didn’t go well?
How can we improve the workshop for the next time?

27. Thank you !!
For further information contact us:
www.velocitypartners.net
info@velocitypartners.net
27