Being agile while trying to do many things at once

L i m a , P e r ú – 4 a l 7 d e O c t u b r e 2 0 1 0

Copyright©2010 Robert Walsh - All Rights Reserved

Being AgileWhile Trying to Do Many Things At Once

Robert WalshPresident

EnvisionWare, [email protected]

1Tuesday, October 12, 2010

mailto:[email protected]

mailto:[email protected]



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 ProblemLPT:One

PC Reservation

Authentication and Accounting Module

eCommerce Services

BarcodePlus

OneStop

RFIDLink

iLink

StaffLinkPINPal

LibraryPDA

Launch Command

Many products




The Problem

Most products composed of multiple modules




The ProblemWindows 95

Windows 98

Windows Millenium Edition

Windows NT

Windows 2000

Windows XP

Windows Server 2003

Windows 7

Windows Server 200832 / 64 bit

Mac OS X 10.5

Mac OS X 10.6

Many supported platforms




The ProblemC++

Java

Ruby

Perl

PHP

jRuby

Javascript

HTMLDistributed Ruby

AJAX

Many supported languages and technologies




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 flexibility 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

LPT

ECS

AAM

OS

RLK

PCR

ECS

RLK

LPT

AAM

OS

LPT

PCR

ECS




What We’ve Tried


• Treatment of defects

• Defects had to be prioritized like any other story




What We’ve Tried


• Benefit: 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 significant 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

LPT

Maint

OS

Maint

ECSPCR

Maint

ECS

LPT OS

Maint

LPT

PCR

Maint




What We’ve Tried

• Track system

• Treatment of defects

• Defects found in same iteration as story were fixed 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

• Benefit: 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

LPT

Maint

OS

Maint

ECSPCR

Maint

ECS

LPT OS

Maint

LPT

PCR

Maint

PCR

LPT

PCR




Next Steps




Next Steps

• Track system has merits

• Development appreciates extended focus

• Customer able to lump together batches of features to deliver significant 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 flexibility to select mini-projects

• Small features in minor products

• Service packs for maintenance




Next Steps


• Must find ways to release at the end of each interval




Next Steps


• Business must adhere to “fix 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 fixed as part of current release, it is injected into current iteration




Conclusion




Conclusion

• It can be difficult 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?


Date post:	21-Jan-2018
Category:	Technology
Upload:	robertwalsh
View:	617 times
Download:	0 times

Being agile while trying to do many things at once

Technology