Adopting Agile

Lessons Learned

Guy DavisTechnical Team LeadPetris - Calgary OfficeOctober 6, 2009

Why did we adopt Scrum?

Where were we a few years ago? • Long time between releases (many months).• Frequent priority changes (sometimes daily).• Testing was an after-thought (often cut).• No time-boxing allowed complex designs to arise.• Little feedback from users and rest of company.

Summary of DataVera Development Team:• One product owner• One dedicated tester (QA)• One handling client support and documentation• Three programmers

Problem: Infrequent Releases

Symptoms:• Feature-driven releases, but kept adding features.

o Developers frustrated as goal post kept moving.• Frequent interruptions and priority changes.

o Users couldn't wait a year so everything was a rush.  

Problem: Infrequent Releases

Our Solution:• Time-box to release every 2

weeks.o Initially held one month iterations

to ease transition. Result:• More feedback on our work, more often.• Developers felt sense of accomplishment.• Interruptions eased as users could wait two

weeks.  

Challenge: Story/Task Breakdown

Symptom:• Estimate on an epic

feature is bigger than iteration.

 

Our Solution:• Break down requirement to get simplest design.• Don't gold-plate new feature.  Can improve later.• Hold design meetings prior to planning meeting.

o Discussion reveals if story is ready for planning. • Practice over many iterations.  It becomes easier.

Challenge: Story/Task Breakdown

Results:• Better able to respond

to inevitable change.• We stopped building

shiny framework code.o Focused on shipping

features the user wanted.

• We now involve the entire team in design and planning.

•  

Challenge: Gathering Feedback

Symptom:• Stakeholders felt out

of loop on direction of product.

• Poor knowledge transfer to client support of changes.

 

Our Solution:• Demo meeting at end of every iteration.

o Everyone in our office invited to attend and comment.•  Added automatic error reporting to our application.

Challenge: Gathering Feedback

Results:• Our reputation is on the line. Failed demos are

lame.• Regularly got feedback on new features.• Gathered many good ideas from participants.• Knowledge shared between dev and support teams.• More detailed error reports meant faster fixes.

Problem: Low Quality of ProductSymptom:• Users complained of

errors and broken features.

Our Solution:• Better requirements analysis to find true needs. • We strove for simplicity in our designs.• Hire good QA for acceptance and regression testing• Improve unit test suite and monitor code coverage.• Implement daily code review among developers. • Adopt automated functional testing tool (IBM FT).• Be patient.  More use led to more maturity in our

app.

Problem: Low Quality of Product

Results:• Fewer serious issues

reported by users.• They have more

confidence in product. • Failed to implement

automated testing as test scripts didn't keep pace with product changes.

 

Problem: No Shared Goal for Team

Symptom:• Individuals care about

finishing their own tasks only.

• Complaints fester, solutions not offered or enacted.

• People abdicate responsibility and blame others.

Problem: No Shared Goal for Team

Our Solution:• Team estimates, then accepts iteration workload.• Entire team is responsible for shipping quality

product.• Retrospective team meeting at end of iteration:

o Raise concerns: How can we improve for next time?o Kudos for good work: Praise extra effort and success.o Think about work practices, don't just do them blindly.

Results:• Team is constantly

improving and adapting.• Better team cohesion and a

feeling of progress. 

Always room for improvement...

We still sometimes:• Take too long between major releases.• Fail to adequately breakdown/understand stories.• Find serious errors in deployed versions.

We wish we had: • Had a flexible automated GUI test suite.• Not tracked hours worked; it's an irrelevant metric.

o Was built-into XPlanner and understandable at start of Agile adoption, but only shippable features matter.

• Users who would upgrade more often.  Less legacy support.

Critical Factors for Success• Empower the entire team:

o Let them determine their own processes.o Set their own estimates; accept own workload.

 • Hold the team responsible:

o Measure by potentially shippable features. • Improve communication:

o Both within the team and with external stakeholders. • Have the courage to fail:

o Learn from the experience, do better next time.o Always inspect and adapt -> constant improvement.

Further Resources

Continue the discussion:• Agile @ Petris thread on Yammer

 Articles: • Making Scrum Stick: Overcoming Fear and Anxiety• Ten Keys to Successful Scrum Adoption

 Videos: • Succeeding with Agile: A Guide to Transitioning• Agile by the Numbers: What People are Really Doing• Scaling Agile into the Enterprise