This document discusses the path of Trish Rempel and Brent Hamm's team at Friesens Corporation towards adopting agile practices. It outlines their current strengths and issues, as well as barriers to adopting agile. Their first steps included establishing improvement goals and training. The document contrasts traditional "waterfall" approaches like delivering late and solo work with agile practices like iterative delivery, examples-based specifications, team development, and limiting work-in-progress. It advises that agile is more about attitudes than processes and emphasizes improvement, learning, collaboration and having someone keep agile momentum.

1. Our Path To Agile
Trish Rempel and Brent Hamm
Friesens Corporation

2. About Trish
• @trishrempel
• Developer in .Net, web, Flex
• Interested in Agile and continuous improvement
• Part of a great team at
Friesens Corporation
http://www.friesens.com
• Organizer of
Winnnipeg Girl Geek Dinners
http://girlgeekwinnipeg.wordpress.com

3. About Brent
• @BrentHamm105
• With Friesens as a Dev for 16+ years
• Powerbuilder, .Net, SQL, Flex, Clipper 
• Part of a strong team at
Friesens Corporation
http://www.friesens.com
• Organizer (and more)
of StrongManitoba.com

4. About Friesens
• One of the top printing companies in North America
• Books, yearbooks, packaging, and 3D forming/printing
• Often-upgraded equipment, workflows, and automation
• Two online customer portals
• Over 50 internal apps, some more than 16 years old
• Over 600 employees
• An IT Department of 7 people

5. Our Strong Points
• Highly responsive to bug fixes and small features
• Short testing/deployment cycle
• Deep knowledge of the industry & business needs
• Results-oriented with very little bureaucracy
• Involved in the project planning process
• Access to up-to-date dev and productivity tools

6. Our Top Issues
• Too many interruptions
• Specs communication issues
• Very little cross-training
• Hard-to-maintain code (for newcomers)
• Larger solo projects dragging out
• Inaccurate project estimates

7. Our Barriers to Agile Adoption
• Knowledge gap
• Unsure of the potential ROI
• Reluctant to change, attitude of complacency
• Hard to convince everyone
• Thought our team was too small
• Not sure how to start
• The perception of being too busy to try

8. First Step:
Focus on Improvement
• Yearly IT Business Plan
- Specific, measurable goals with a deadline
• Training
- Conferences, all-day consultant workshops, user group meetings
• Weekly IT meetings
- Review progress on ongoing projects
- Discuss issues and business plan goals
• Developer Improvement Meetings
- Watch a webinar or do a code review together
- Expose everyone to different ideas
- Proactive environment to discuss possible positive change

9. Delivering the Wrong Thing vs.
Delivering & Reviewing Often
• Delivering the Wrong Thing
- Only a few stakeholders involved in planning meetings
- Project reviewed when demo-able (75% done)
- That’s not what we meant - back to the drawing board!
- Testing at the end
• Delivering & Reviewing Often
- Involve all the right people in planning
- Develop a project vision statement
- Create a mock-up, wireframe, or prototype
- Break features down into user stories
- Develop and deploy iteratively
- Test and review throughout the project

10. Spec by 20 Questions vs.
Spec by Example
• Communication breakdown
• Use specification by example
- Use real world examples
- Easy for staff to relate to this method
- Specs will become tests

11. Spec by 20 Questions vs.
Spec by Example
• We will have a 5% discount for quantities over 10,000.
And we will discount by 5% if they have more than 100
pages in the book. Unless it’s a digital book. Then we
will do a 2.5 % discount, which will jump to 4% if they
have more than 10,000 quantity. Except in the case of
more than 10,000 books and more than 100 pages,
which is 5%.
• ?

12. Spec by 20 Questions vs.
Spec by Example
Book Quantity Pages Prep Type Discount
10,000 100 Offset 0.00%
10,001 100 Offset 5.00%
10,000 101 Offset 5.00%
10,000 100 Digital 2.50%
10,001 100 Digital 4.00%
10,000 101 Digital 5.00%

13. Mammoth God Classes vs.
SOLID Principles

14. Unprioritized Requests Anytime vs.
Kanban
• Requests on top of requests
• Will sprints work for us?
- Failing the sprint feels demoralizing
• Maybe Kanban is a better fit for how we work?
• Concentrating on getting things done
• Applying WIP limits
• Switching roles to keep flow going

16. Solo Specialization vs.
Team Development
• Solo Specialization
- One person responsible for a group of applications
- Tasks are automatically assigned to the “owner” of the app
- Unreviewed code can become sloppy
- Bugs and features wait when the owner’s on vacation
- Huge learning curve for newcomers to the code
- Larger projects drag out, can hit a rut for days or weeks

17. Designers Edge Online

18. Solo Specialization vs.
Team Development
• Team Development
- Everyone working toward the same goal
- Pair programming helps solve problems quickly
- Self-organization emerges
- More cross-training and better for new hires
- Increased and more consistent velocity
- Higher morale and more fun

19. Our Advice on Agile Adoption
• Agile is more about a team-oriented attitude than it is
about a set of processes and tools
• Self-organization and team accountability has a huge
gain in morale and productivity
• Focus on improvement, learning, collaboration, and fun
• At least one team member needs to keep the agile
momentum going (doesn’t have to be PM)
• Go to user group meetings and conferences
• Consider consultant training if possible

20. Questions?
• Trish Rempel
- trishrempel@gmail.com
- @trishrempel
• Brent Hamm
- brenth@friesens.com
- @BrentHamm105