1 / 20

i nthinc’s Agile History

i nthinc’s Agile History. Levi Sorenson Director of Project Management. [2013]. 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.

nitara
Download Presentation

i nthinc’s Agile History

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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 • GAIN • My.inthinc.com • waySmart 820 • 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 • 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. 15-20 people in R&D. Page 5

  6. inthinc 2008 - 2009 • 2008 • 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 DevOpsteam. • 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 • 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  • 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  • 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 1 1 10 ENGINEER 2 5 0 TEST 0 5 OWNER NAME Page 20

More Related