Project Liftoff - Pt. 1

NOTE: Soren Nielsen is the former Senior Director of Agile at TrueCar. This multi-part series will take you through an agile transformation from both the executive and coaching perspectives.

TrueCar has an amazing story. Since its founding as Zag.com, Inc. in 2005 (later renamed TrueCar, Inc.) it has experienced incredible growth. Before going public in 2014, TrueCar expanded its network to include nearly 1/4th of all auto franchises in the U.S., built a national brand, and partnered with some of the largest affinity membership organizations, such as USAA, Consumer Reports, US News, AAA and many more. Today, TrueCar Inc. has over 700 employees and is continuing to grow.
 
Throughout its growth, TrueCar, like many other fast-growing companies, has gone through a handful of technology consolidation and re-platforming attempts, which have resulted in a patchwork of technologies and processes.
 
When a company scales up from 100 to 700 people, having small, nimble groups sitting together and solving siloed problems does not work anymore. TrueCar experienced the same growing pains as any other startup that reaches a certain size. Over the last two to three years, TrueCar has made a couple of attempts to become more agile.
 
They tried to adopt a monolith architecture and align the teams around this, which also meant aligning JIRA to the monolith code bases and creating JIRA projects for code bases like Frontend, Backend, UX and Data. New Scrum Teams (called “Quest teams”) were created, but they ended up being large teams focused on multiple deliveries, which created a competition for resources. Having a more “command and control” product management style was not helpful either. Many product decisions were top down in nature with projects being redirected and potentially cancelled without much bottom up involvement from the working teams.
 
My journey at TrueCar
 
I was hired in October 2017. As I came up to speed, I made my own notes and observations about the present state, while learning about the history which I will describe in detail throughout this article series.
 
After joining the team, I was thrown into the fire of an intense 2018 planning period. Product and Engineering teams had several offsite meetings to work through 2018 priorities. As a new member of the management team listening to the debates, it was clear that balancing the Capsela replatform versus new product initiatives was a major challenge.
 
Maintaining our hardware infrastructure was a constant challenge and the company decided to invest in a re-platforming project dubbed project “Capsela” named after a modular 1980’s construction toy that represented some of the fundamental principles of the envisioned new tech stack. Modular architecture, easy to add on to and remove from, and significant scaling capabilities.
 
There was tremendous pressure to get Capsela completed as soon as possible, which meant that most — if not all — of the engineers should be focused on this project. As with most companies, balancing a re-platforming effort with feature development and optimization quickly became a challenge. As business opportunities arose, engineers were taken off the re-platforming effort and moved over to add new features on the legacy system — this caused an already daunting project to grow in scope. As this compounded, we began to realize that the Capsela re-platforming would take a lot longer than originally conceived, unless we took a new approach.
 
The goal and the inspiration
 
The goal? To complete Project Capsela: the re-platforming of all core systems and experiences in modern technologies while completely moving to AWS and removing all dependencies on our legacy data center — all while transforming TrueCar's product development process to be more Lean and agile.
 
Even though I had been involved in something similar before, the sheer number of pieces that had to fall into place this time around was at a different scale and, at least in the beginning, it had a lot of uncertainty and was a great challenge.
 
Once we identified the needs of the project and all key stakeholders, we needed to determine how to:
 

• Create new self-organizing and autonomous teams
• Fully empower each team to deliver on what is most important – the goals of the migration are not Feature Parity, but rather Business Performance Parity. Each team was encouraged to have a “Lean” mindset in achieving that goal
• Restructure JIRA
• Implement CI/CD (Continuous Integration/Continuous Deployment)
• Refocus Product and Development management to be more people-centric
• Define new strategy around progress reporting, strategic planning and road-mapping

 
When I originally described what we were trying to do to some of my peers, they looked at me and said that we were brave – and possibly crazy – to try to do all of this at once instead of in phases. Very few full agile Transformations are successful, and most of the success cases were triumphant because they kept it simple. However, I think if my peers knew the management team here at TrueCar, and how dedicated they were to doing this, they would make the same decision.
 
But there were impediments:
 

• Teams were big, with around 10 to 15 people on each team
• Some teams were working on multiple different feature areas, so priorities changed often
• Project managers were heavily involved to keep cross-team collaboration going
• The company goal encompassed too many goals and sub-goals
• It was not always clear to the working teams why certain product decisions were made by management
• Planning meetings were set up on a quarterly basis at a high level; the teams were rarely involved in planning
• Engineers were being “told” what to do (i.e., they had no empowerment)
• Collaboration with DevOps and the operations were missing or always came as an afterthought
• Quality Assurance (QA) were seen as “outsiders,” not part of meetings or planning sessions
• Engineering siloes like Data, Frontend, Backend, Data Science, DevOps, and UX were clearly separated causing frustration and inefficiency.
• Product managers on the development teams did not have authority to make product decisions
• Top-down management style
• JIRA was set up with projects that covered code bases (UX, Frontend, Backend, etc.), so there was no way to get supporting data to be able to tell how a project was progressing
• JIRA had about 25 development-related projects, but none of them were product-based. There were about 35 different issue types (that being said, many non-technical departments were also using JIRA.)
• Builds and deployments and releases (change management) was handled by QA. (CI/CD had been in the making over the prior year)

 
Giving agile another go
 
In a couple of previous efforts, TrueCar had tried to move toward agile, but they never fully adopted it — and it is very difficult to just be “a little” agile. The teams had daily stand-up meetings but they were, in fact, more status meetings than anything else. Some teams ran two-week sprints, but usually the sprint burndowns revealed that the sprint planning was not detailed enough; full delivery of what was planned was rare and work was often moved into next sprints.
 
The roles of product owner and ScrumMaster were foreign roles and everyone was carrying the traditional roles of project manager and Product Manager. After a discussion around introducing smaller teams with more focus on delivery of full solutions and features to help us become more agile, we decided to give it a shot in TrueCar’s San Francisco office. In early November, I began to travel to San Francisco to help the team run more rigorous Scrum ceremonies in a truly agile manner. San Francisco was set up as one team of ten engineers and six consultants in Canada, working on about eight different features in two different areas of the product. We decided to break this group up into three teams: each team would have their own separate backlog and goals, and each team would begin to focus on their own area and their own tickets in their backlog.
 
We changed the format of the tickets to be full delivery of a demo-able unit of work and used Story Points to estimate for planning. We also made sure that the engineers were part of the testing that was needed, so there would be a lot less handoffs to QA. The Quality Assurance team is also now invited to the daily standups, as well as to the planning meetings, which they had previously never attended. For one of the teams we created a single JIRA project with all issues in the same place, which meant no more front-end versus back-end tickets.
 
We did this experiment on a trial basis for about three sprints. In mid-December we set up the first official agile training session in San Francisco with the engineers and product people involved. We waited for the three sprints to end to see if this new Scrum framework would change anything.
 
Soon enough, it did. Teams felt more involved, were more focused and delivered better quality products — probably as a result of writing their own automation tests and being accountable for deliveries. See more about the training further down.
 
With the success of our test with the teams in San Francisco, it was decided to set up training for some of the other teams in Santa Monica. This way, we could begin implementing the new process slowly and where opportunity allowed for it in 2018.


Stay tuned for Part 2, as Soren retraces the phases of TrueCar's most ambitious project to date, now utilizing the agile framework.