distributed agile scrum model
Post on 13-Jan-2015
244 Views
Preview:
DESCRIPTION
TRANSCRIPT
Chakra M. VenkataramanaDirector
SPAN Infotech
The De Agile Model(Tailored for Offshore)
Distributed Agile
• Context is Testing and Development teams being distributed geographically
• Multiple Test requirements including – Regression– System– Compatibility– Automation– Technical Testing – Perf, Security and Compliances
• Can be applied to distributed Dev teams too – with minor tweaks
2
Against De-Agile
Time zone differencesConflicting work hours, Personal Sacrifices in terms of time managementAvailability – F2F Meetings, Information sharing, planning, daily-standups, retrospectivesParallel work – Peer coding/testing, immediate requirementsWork allocation and Scheduling, Effort deviations
Staffing and Shared Understanding
Self motivating and Self Organizing resourcesMisunderstanding requirementsDelay or reluctance for clarifications / time consuming
Trust and Communication
Capabilities – Technical, Domain, Standards, PersonalCultural and Language barriersUnseen speakerTwo way communication
3
Need for Distributed Teams
Programming
Paired ResourcesStreamlined processes – Comm & Collaboration, Source Control, Automation, CIFollow the Sun Model for faster deployment
CapabilitiesAll rounder resources are rareDomain, Tech, Design, Dev, Test, Tech-TestVendor Org support to offshored resources – draw up on support structuresInnovation and Value Adds
Cost
Globally distributed teams reduce cost, Contract Employees as needed – required competency at a short noticeOffshore resources at lower costImplicit additional hours - reasonable
4
When would De-Agile Work?
Cost Advantages
Pros outweigh Cons
CapabilitySpecific Technology Requirements (expensive or not available)Available at short noticeStaff on demand / reduce when neededWilling to accept that there are challenges
Us vs ThemWorking FOR and not AGAINST ThemAcceptance
5
Tools and Techniques that enable De-Agile
• Dedicated Meetings rooms / Conf bridges• Collaboration Tools – TFS (requirements repositories,
SCM, management, Automatic build and deployment setup, Continuous
Testing, Automated defect tracking, and project management tools) • Communication - IM, Skype, IP Phones, Video
Conference and Web Cams• Daily Standups on Skype boards• Frequent (not too frequent) travel and work
from other locations• Classification of tasks Simple to complex - grow with time
• Overlap and Hand-shake
6
Diagrammatic Model
• Project Initiation / Initiation of resource into the project
7
Travel – Either Direction (4-6 weeks), every six months, Intro to stakeholders including POs, most affected people
Training – Domain, Standards, Technology, Architecture and Design Overview, SCM, Process inclusion
Task Allocation – Onsite execution under supervision, Graded tasks (complexity), Constant reviews initially, offsite tasks – graded tasks
Offsite Delivery – Testing Specific
8
SPRIN
T M
EETI
NG
Gro
omin
g Se
ssio
ns
SPO
C
Dis
cuss
ions
Test
ing
Wor
k in
Pr
ogre
ss
Test
ing
Act
ual
Test
ing
Aut
omat
ion
Script
ing
Test
ing
Inte
grat
ion
Reu
sabl
e Cod
eCon
tinu
ous
Test
ing
Vid
eo C
on
fere
nce
WE
BE
X/G
oto
Mtg
IM,
Sky
pe,
Ph
on
e
PO Scrum Master SPOC
SC Manager
Reviewer - Temporary
Stakeholder
Roles (Additional?)
Measure - Metrics
Statistical Trends
Productivity and Quality
Feedback Continuous Improvement
Documentation
Activities (Additional?)
TFS
Collaboratio
n tools
TFS Client
SME Review
Tool based Review
Planned Additional Activities• Sprint and Retrospective (Video or In
Person)• Sprint Grooming• SPOC Discussions• Work in Progress testing• Automate for CI & CT• Metrics – Online Dashboards, Burndown and
Burndown charts, Velocity, Defect Trend, Requirement Stability, Productivity, Quality
• Frequent planned Demos• Reviews 9
Will all this work?
• We have multiple projects which have inherited processes from this model to succeed
• There needs to be strong incentive for this to work
• It is time and effort consuming but will stabilize in time (3 months)
• May not be very cost effective as it will not be a pyramid model of delivery
10
Implications of De-Agile
• Willingness to make it work is important • Additional effort from the Agile team to
manage distributed deliveries – atleast initially
• Slow onboarding – takes time to deliver• Additional processes and metrics• Additional documentation – adequacy can
be set
• Dependence on Collaboration tools• Additional Travel costs
11
Q&A
12
top related