In 2010 the Intuit Tax Development organization - the programmers & accountants that build the internal logic of TurboTax - needed to revamp their build system. In my role as an Innovation Catalyst, I facilitated the problem definition and goal setting for the project.
The software build system for the tax code of TurboTax was stretched to the breaking point. It had grown complex, unwieldy, and fragile, due to the types of bugs, inefficiencies and workarounds that collect over time in any toolset that continues to 'work'.
Developers waiting too long for builds, and due to the opaque nature of the process, people were frequently 'breaking' the build which slowed everyone down ever more. Our goal was to make the system fast, transparent, and robust again, while teaching innovation practices to the team.
Complexity. The code base of TurboTax is one the biggest in software. It contains logic for 70,000+ pages of Federal tax law (PLUS 45 states), wrapped in a step-by-step interface, and published on web, iOS, Android, Mac, and Windows platforms.
Availability. That code is worked on simultaneously by hundreds of tax programmers and engineers across dozens of teams at multiple locations, each needing to build fully-testable software at any time – multiple times a day.
Due diligence. A system like that is unavoidably complex and deceptively interdependent, and the kind of changes we needed to make demanded rigor and caution. Measure twice, measure twice again, then cut.
Teamwork. The initiate happened over 5-6 weeks, involving a cross-functional team with everyone from design, research, quality assurance, tax domain experts, engineering, and senior management. Everyone contributed, everyone took ownership.
Kick-off. The session framed the problem in human terms, reaffirmed our efforts were ultimately towards our customers, then modeled the best practices, tasks and behaviors the teams were to expect over the course of the project.
Process adoption. Innovation Catalysts explicitly show what tools we are using, facilitate the exercise, then help teams to adopt the tools themselves. The goal is to teach teams to embrace these practices to tackle their other problems.
Exercises. The Innovation Catalyst program methodology is similar to the work of IDEO and Clayton Christensen, in that it uses iterative work to understand, break down, and validate the jobs people are actually trying to accomplish.
Outcomes. The project ended with the teams ultimately figuring out their own metrics for success, identifying the problem scope, cataloging all the possible fixes, prioritizing which ones to do, and then kicking off the development work.
Someone asked us Catalysts, 'What are our success metrics'? We looked at each other, shrugged, and said: 'You tell us?' The looks exchanged between team members indicated this was new, and very welcome.
Productivity. Tax developers gained roughly an hour of productivity back per day. The team ultimately changed the build system in a variety of places. The work varied, from light user interface changes in a web-based scripting tool, to deeply refactoring the internals of a critical system.
Satisfaction. The team members were inspired by the process. A few told me they were thrilled to have finally rid themselves of obstacles that had troubled them for years. Best of all, people started adopting Innovation Catalyst techniques to their own work.