Align with our clients on agile practices.
Set reasonable expectations
Mitigate difficulties of Distributed Agile Software
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.
Distributed Meeting Management
o Scrum / Kanban
o Quality, Velocity, and Definition of Done
Risks and their Management
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.
Tools we propose:
Screen sharing only:
Roles & Responsibilities
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 VP Team Lead
o Solutions Manager
o Client Stakeholders: who and what responsibilities?
o Other Roles: QA lead, build management, others?
Agile Process Alignment
Take time to discuss the following items in order to
How agile is the group of people that the VP team will be interacting
How agile do we want to be ?
Scrum Process and Meetings
o Sprint cadence: ? weeks
o Required meetings, timing, agenda, prep, and attendees.
Agile Process Alignment
Choose appropriate tools to support agile practices in a
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
Scrum proposes the following ceremonies
1. Product Planning
2. Release Planning
3. Sprint Pre-Planning (“grooming”)
4. Sprint Planning
6. Sprint Demonstration
7. Sprint Retrospective
This doesn’t mean that they all will be useful in
our specific project.
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.
Overview of Process
Work States. Define them and make sure everyone
has a deep understanding of them.
Establish adequate WIP Limits.
Tracking Methods / Development
Take time to sync up about the expected tracking
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.
Stories / PBIs Tasks
How is work estimated?
How is progress measured?
How is velocity measured? (not applicable)
What are the statuses?
Are bugs/defects treated differently than a story / task?
Content and Format Who Does?
User Story / PBI
(see next slide for example)
Task / Card
Ticket (for bug or
Software Quality Assurance
Development Process Improvement – KPIs, e.g.:
o Estimation accuracy
o Code quality
o Functional quality
o Role, if any, of stories and tasks in testing
o Internal code quality
o Testing roles and practices
o Approaches and environments
Responsible Party Practices and Tools
Role of TDD / BDD
Environments to be used (dev, QA, staging, etc.)
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.
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)
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
Definition of Done examples
•In source trunk
•In CI build
•All agreed tasks
•All known bugs
•Story test updated
•Sprint end date
•All bugs closed or
•Documented for tech.
•All agreed sprints
•Integration tested /
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.
•Product Owner participation and clarity / distance from business customer
•Incomplete acceptance criteria
•Developers unclear / unquestioning during story elucidation
•Expectations for ramp-up
•Unrealistic, business-driven deadlines
•Planning at too high a level / inaccurate estimations
•Commitments when there should not be commitments
•No measures of productivity
•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
Risk Area Specific Risk Priority
(access, infrastructure, response, 3rd parties, etc.)
(client or team participation, too many layers,
incomplete acceptance criteria)
(ramp-up / deadline expectations, planning too
high, poor estimating)
(team being “sure”, lack of metrics)
(attention to blockers, lack of QA, adherence to
(roles, skills, motivation, conflict)
Workshop Action Plan
Specific Action Items
o Action Item #1: (establish ad hoc meetings for example)
Future Use of Workshop Output
o Use #1:
What went well?
What didn’t go well?
How can we improve the workshop for the next time?
Thank you !!
For further information contact us: