1. inthinc’s Agile History
Levi Sorenson
Director of Project Management
[2013] 1

2. Who Is inthinc? Based in Utah Started in 1999 Safety Focus
Hardware, Software, Firmware
Global Install base of 50,000 devices in:
US & Canada
South America
Africa
Europe
Australia & New Zealand
Page  2

3. Products Portals waySmart 820 tiwiPro waySmart 850 GAIN My.inthinc.com
MCM (UClinux)
2.4 and 2.6 Kernel
TouchScreen (Windows CE)
HandHeld (.Net Micro)
tiwiPro
(Open AT)
waySmart 850
IVMM (Android)
HMI (Android)
Page  3

4. Reasons for becoming agile
Wanted to do more with less
Desire to move fast and increase quality
Release predictability
Discussion points
Brief Overview of inthinc’s Agile History
What has helped us be successful?
Implementing Physical Kanban
Contractors and Outsourcing *
Killing Sprints
Killing Release Planning
Why Agile works for Hardware
What would we have done different?
Page  4

5. inthinc 2006 - 2007 2006 2007 Waterfall & project plans.
Firmware and software releases are frequent and small.
Every release requires heroics from the whole team.
10 people in Development including test.
2007
Growing pains, lots of heroics, very little process.
Merged with our hardware manufacturing partner.
Standups held frequently but not consistently (Always cross functional).
Small teams, including a dedicated test team people in R&D.
Page  5

6. inthinc 2008 - 2009 2008 2009 Quick growth in R&D
Moved to a bigger building
50 people in R&D 3 Project Managers 1 Product Owner
Trying to build predictability with extra process
PRD's, MRD, Gate Sign offs. Very PEMBOK
2009
Agile adoption on 1 team for 1 large project very successful.
New customer portal (we now support two portals).
Major reduction in work force, every team in R&D heavily effected.
1 Project Manager; no Product Owners.
Un-merged with manufacturing sister company.
Page  6

7. inthinc 2010 2010 Adopting Agile
Daily standups ups
Lots of half baked process
All teams started Agile at the same time
Release planning and sprint planning is cumbersome and time-consuming
Engineers have a hard time with time commitments 
Business has a hard time not breaking sprints with "emergencies"
Commitments didn’t mean much after sprint planning
Release planning is an unrealistic wish list 
2 week sprints then 3 week sprints
An extra week added to the sprints to make time for testing.
Unlikely to complete/accept work during the sprint. 
No Process around story acceptance.
Page  7

8. inthinc 2011
2011
Dedicated test team disbanded and members are integrated into individual teams.
3 week sprints 
Burn down was demoralizing, commitments are rarely meant.
Moved to 1 week sprints at the end of the year.
Began move of Production to AWS and EC2.
Started a DevOps team.
Continue to struggle with release planning.
Cross functional planning breaking down.
Backlog is out of control and unmanaged.
Page  8

9. inthinc 2012 - 2013 2012 2013 All teams moved to physical Kanban.
More frequent releases.
Lighter process with a more controlled feel.
Process flow accounts for our holes in product management and story acceptance.
Backlog is out of control and unmanaged.
2013
Kanban Portfolio Management.
Continuous Integration.
Source code moved to GITHUB.
Better cross-functional communication.
Page  9

10. Continuous Integration
Production Release Time (Last Month)
2 Calendar days to deploy and test.
20-65 man-hours of testing.
Lots of problems.
Production Release Time (This Month)
5 minutes to deploy.
30 minutes to verify.
Production Release (Very Soon)
Less than 2 minutes to deploy.
Deploys happen frequently throughout the day.
Prod
Page  10

11. More DevOp Advantages Cost Flexibility CF engine configuration Testing
30% savings since we moved to AWS.
50% predicted as we optimize for the service.
Flexibility
Production copies for anyone in less than 20 minutes with production data.
CF engine configuration
New resources are automatically configured and audited every five minutes.
Testing
DB alters ran against a current copy of production.
Releases are timed and verified
A/B testing
Weighted DNS send a percentage users to new servers.
Page  11

12. Kanban Portfolio Management
Value-Driven Prioritization
What’s the most valuable now?
Keeping balance between long and short term.
Weekly portfolio-steering.
Hierarchal view of Features and User Stories
Budget owners.
Accountability for time.
Visible Priorities
MVPs
Establishing MVPs and Acceptance criteria.
Keeping WIP limits intact
Page  12

13. Secret to Our Success Development Process: Code reviews TDD
Pull requests
Branching
TDD
Unit Tests
Business tests
Acceptance Criteria
Established before the story is worked on
Acceptance Tests written
Feature Demos
Show the product early and often!
Page  13

14. The Secret to Our Success
Scrumban
Physical Kanban.
Daily Stand-Ups.
Continuous Process Evaluation and Improvement.
New Features are Driven by Sales
Communication
Weekly cross-functional planning (Scrum of Scrums).
Logged Team and Project Chats.
Contractors and Outsourcing
In-house, China, India.
Support Escalation
Dedicated Escalation Engineer Triaging Support
Commodity-based Hardware and Software
Page  14

15. Sprint and Release Planning
Why Release Planning Failed?
Over-committed
Why Sprints Did Not Work?
Lack Training 
Lack of coaching
Lack of Product Ownership
Page  15

16. Why Agile and Lean Work for Hardware
Hardware development is naturally iterative. 
Hardware engineers seem to have a harder time communicating, stand-ups and stories provide a feedback loop.
Feature demos remind the business that value is being delivered.
Assists the hardware team in communicating with the firmware team.
Page  16

17. What Would I do Differently
Slower Implementation Roll Out for Each Team
Better Defined Scrum Master Role
Product Owner/ Business Analyst
A Different Type of Executive Support
Page  17

18. Q&A
Page  18

19. HARDWARE KANBAN
Page  19

20. KANBAN CARD
USER STORY ##### POINTS EST # AS A USER I WANT TO …... TIME SPENT LEFT ENGINEER ENGINEER TEST 0 5 OWNER NAME
Page  20