Being agile while trying to do many things at once

Being Agile
While Trying to Do Many Things At Once
Robert Walsh
President
EnvisionWare, Inc.
rwalsh@envisionware.com

Lima, Perú – 4 al 7 de Octubre 2010

Copyright©2010 Robert Walsh - All Rights Reserved

Tuesday, October 12, 2010 1

Agenda
• Who is EnvisionWare?
• The Problem
• What We’ve Tried
• Next Steps
• Conclusion



Who is EnvisionWare?




• Library technology company
• Focus on products for patron self-service
• Develop most, OEM some
• Founded in 1998
• Have grown from 2 to ~60 employees in
just over 10 years




• Using Agile processes and principles since
around 2002
• XP for engineering practices
• Scrum for project management
• 2 week iterations
• A few near shore developers on contract



The Problem




The Problem
LPT:One LibraryPDA

Launch Command OneStop
Authentication and Accounting Module
Many products

BarcodePlus iLink PC Reservation
RFIDLink StaffLink
eCommerce Services PINPal




The Problem

Most products composed of
multiple modules




The Problem
Windows 95 Mac OS X 10.5

Mac OS X 10.6 Windows XP
Windows Millenium Edition
Many supported platforms

Windows 2000 Windows 7 Windows 98
Windows Server 2003 Windows Server 2008
Windows NT 32 / 64 bit




The Problem
C++ AJAX
Javascript PHP
Many supported languages and
technologies
Java
Perl
jRuby HTML
Ruby Distributed Ruby




The Problem
• Small staff
• 6 Developers
• Maximum of 9 over company history
• 3 QA
• 2 Technical writers



The Problem
• Few automated acceptance tests




The Problem
• Single, largely interdependent code base




The Problem
• How do we allocate our scarce technical
resources to support, maintain, and extend
all of our current products while preserving
our competitive edge by creating innovative
new products?




What We’ve Tried




What We’ve Tried
• Approach #1
• Maximum ﬂexibility for the Customer




What We’ve Tried
• Treated the entire code base and story
backlog as a “product”
• Customer allowed to focus on any
component in each iteration




What We’ve Tried
PCR AAM PCR LPT LPT

LPT OS ECS AAM PCR

ECS RLK RLK OS ECS




What We’ve Tried
• Treatment of defects
• Defects had to be prioritized like any
other story




What We’ve Tried
• Beneﬁt: Customer able to choose highest
priority stories each iteration
• Maintenance, new features, and defects
treated equally




What We’ve Tried
• Problem: Too little time to achieve
signiﬁcant business value in each
component




What We’ve Tried
• Problem: Too much productivity lost to
context switching




What We’ve Tried
• Problem: Too much overhead associated
with making the components deliverable




What We’ve Tried
• Approach #2
• Track system




What We’ve Tried
• Track system
• Customer agrees to limit scope to tracks

• Number of tracks determined by available
resources
• Development, QA, Documentation resources
assigned to each track

• Track focus switches quarterly

• One track dedicated to maintenance



What We’ve Tried
• Track system
PCR PCR PCR ECS ECS

LPT LPT LPT OS OS

Maint Maint Maint Maint Maint




What We’ve Tried
• Track system
• Treatment of defects
• Defects found in same iteration as
story were ﬁxed in that iteration
• Defects found in later iteration went
into product backlog for Customer to
prioritize for future iteration



What We’ve Tried
• Track system
• Beneﬁt: Technical resources able to focus
on same components for longer periods
of time




What We’ve Tried
• Track system
• Problem: Maintenance concerns
sometimes greater than one track could
handle
• Resources shifted, delivery delayed
• Delays affect future track focus
• Unable to meet business priorities



What We’ve Tried
• Track system
• Problem: QA and Documentation unable
to keep pace with development
• Also delayed delivery
• Defects found in later iterations
interfered with future release schedule




What We’ve Tried
• Track system
PCR PCR PCR ECS ECS
PCR PCR

LPT LPT LPT OS OS
LPT

Maint Maint Maint Maint Maint




Next Steps




Next Steps
• Track system has merits
• Development appreciates extended focus
• Customer able to lump together batches
of features to deliver signiﬁcant business
value in each release




Next Steps
• Key areas to address
• May need to shorten track interval from
3 months to 6 weeks
• Give Customer more ﬂexibility to
select mini-projects
• Small features in minor products
• Service packs for maintenance



Next Steps
• Must ﬁnd ways to release at the end of
each interval




Next Steps
• Business must adhere to “ﬁx the
schedule, adjust the scope”
• Quarterly releases tend to align with
major trade show opportunities




Next Steps
• QA and Documentation need to keep
pace with Development
• More automated tests
• Better TDD in Development to
improve quality of work going to QA




Next Steps
• Change how defects are treated
• All defects are triaged when found
• If defect must be ﬁxed as part of
current release, it is injected into
current iteration




Conclusion




Conclusion
• It can be difﬁcult to be Agile with many
products, all of which continue to evolve
over time
• Agile often does not address product
maintenance




Conclusion
• Successful solution should balance the
needs of the Customer and the Technical
Resources




Conclusion
• Releasing product with few defects is
crucial
• Release brings closure and allows all to
move forward
• Low defect rates prevent backsliding




Conclusion
• Automated testing is essential
• Fast pace of Agile development makes
manual regression testing impractical
• Must be done at both the Unit and the
Acceptance level




Questions?
¿Pregunatas?




Being agile while trying to do many things at once

Recommended

Recommended

More Related Content

Recently uploaded

Recently uploaded (20)

Featured

Featured (20)

Being agile while trying to do many things at once