Adopting Agile Lessons Learned Guy Davis Technical Team Lead Petris - Calgary Office October 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

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. Developers frustrated as goal post kept moving. Frequent interruptions and priority changes. Users couldn't wait a year so everything was a rush.

Symptoms:

Feature-driven releases, but kept adding features.

Developers frustrated as goal post kept moving.

Frequent interruptions and priority changes.

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

Problem: Infrequent Releases Our Solution: Time-box to release every 2 weeks. 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.

Our Solution:

Time-box to release every 2 weeks.

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. Discussion reveals if story is ready for planning. Practice over many iterations. It becomes easier.

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.

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. Focused on shipping features the user wanted. We now involve the entire team in design and planning.

Results:

Better able to respond to inevitable change.

We stopped building shiny framework code.

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. Everyone in our office invited to attend and comment. Added automatic error reporting to our application.

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.

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.

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 Product Symptom: 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.

Symptom:

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.

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.

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: Raise concerns: How can we improve for next time? Kudos for good work: Praise extra effort and success. 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.

Our Solution:

Team estimates, then accepts iteration workload.

Entire team is responsible for shipping quality product.

Retrospective team meeting at end of iteration:

Raise concerns: How can we improve for next time?

Kudos for good work: Praise extra effort and success.

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

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.

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: Let them determine their own processes. Set their own estimates; accept own workload. Hold the team responsible: Measure by potentially shippable features. Improve communication: Both within the team and with external stakeholders. Have the courage to fail: Learn from the experience, do better next time. Always inspect and adapt -> constant improvement.

Empower the entire team:

Let them determine their own processes.

Set their own estimates; accept own workload.

Hold the team responsible:

Measure by potentially shippable features.

Improve communication:

Both within the team and with external stakeholders.

Have the courage to fail:

Learn from the experience, do better next time.

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

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