Our Path To AgileTrish Rempel and Brent HammFriesens Corporation
About Trish• @trishrempel• Developer in .Net, web, Flex• Interested in Agile and continuous improvement• Part of a great t...
About Brent• @BrentHamm105• With Friesens as a Dev for 16+ years• Powerbuilder, .Net, SQL, Flex, Clipper • Part of a stro...
About Friesens•   One of the top printing companies in North America•   Books, yearbooks, packaging, and 3D forming/printi...
Our Strong Points•   Highly responsive to bug fixes and small features•   Short testing/deployment cycle•   Deep knowledge...
Our Top Issues•   Too many interruptions•   Specs communication issues•   Very little cross-training•   Hard-to-maintain c...
Our Barriers to Agile Adoption•   Knowledge gap•   Unsure of the potential ROI•   Reluctant to change, attitude of complac...
First Step:Focus on Improvement• Yearly IT Business Plan   - Specific, measurable goals with a deadline• Training   - Conf...
Delivering the Wrong Thing vs.Delivering & Reviewing Often• Delivering the Wrong Thing   -   Only a few stakeholders invol...
Spec by 20 Questions vs.Spec by Example• Communication breakdown• Use specification by example   - Use real world examples...
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...
Spec by 20 Questions vs.Spec by ExampleBook Quantity         Pages      Prep Type     Discount10,000          100         ...
Mammoth God Classes vs.SOLID Principles
Unprioritized Requests Anytime vs.Kanban• Requests on top of requests• Will sprints work for us?    - Failing the sprint f...
Solo Specialization vs.Team Development• Solo Specialization   -   One person responsible for a group of applications   - ...
Designers Edge Online
Solo Specialization vs.Team Development• Team Development  -   Everyone working toward the same goal  -   Pair programming...
Our Advice on Agile Adoption• Agile is more about a team-oriented attitude than it is  about a set of processes and tools•...
Questions?• Trish Rempel  - trishrempel@gmail.com  - @trishrempel• Brent Hamm  - brenth@friesens.com  - @BrentHamm105
Friesens agile adoption
Upcoming SlideShare
Loading in …5
×

Friesens agile adoption

544 views

Published on

Our Path to Agile

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
544
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Friesens agile adoption

  1. 1. Our Path To AgileTrish Rempel and Brent HammFriesens Corporation
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Spec by 20 Questions vs.Spec by ExampleBook Quantity Pages Prep Type Discount10,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. 13. Mammoth God Classes vs.SOLID Principles
  14. 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
  15. 15. 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
  16. 16. Designers Edge Online
  17. 17. 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
  18. 18. 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
  19. 19. Questions?• Trish Rempel - trishrempel@gmail.com - @trishrempel• Brent Hamm - brenth@friesens.com - @BrentHamm105

×