Adopting Scrum and Agile
-
Upload
guydavis -
Category
Technology
-
view
2.138 -
download
3
description
Transcript of Adopting Scrum and Agile
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