Our Path To Agile

Trish Rempel and Brent Hamm

Friesens Corporation

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

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

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

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

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

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

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

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

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

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

• ?

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%

Mammoth God Classes vs.

SOLID Principles

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

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

Designers Edge Online

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

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

Questions?

• Trish Rempel

- trishrempel@gmail.com

- @trishrempel

• Brent Hamm

- brenth@friesens.com

- @BrentHamm105