About

I decided to write this blog because our Agile Transformation at TrueCar (www.truecar.com) has been (and continues to be) a unique project (at least we think so). We felt like we were in the eye of the storm, and now that we have successfully come out of it, I think it has exceeded all expectations. Because of this successful start of our Agile Journey, I wanted to describe what inspired the Agile Transformation, and the strategy and process that went into executing it.

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.

Goal:

To complete Project Capsela: the re-platforming of all core systems/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 & Agile.

• 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)
• Re-focus 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.

Some History

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.

Observations

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.

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 vs. new product initiatives was a major challenge.

Some recent history:

In 2015, TrueCar promoted Tommy McClung to Chief Technology Officer. Tommy quickly identified that the underlying technology systems needed an overhaul in order for TrueCar to continue to grow and innovate. The legacy systems were in a local data center in Downtown Los Angeles, primarily built on SQL server 2008 and simple upgrades wouldn’t be enough to set us up for the future.

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

Back to my observations:

• 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 – 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 Product 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/releases (change management) was handled by QA. (CI/CD had been in the making over the last year)

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 Scrum Master were foreign roles and everyone was carrying the traditional roles of Project Manager and Product Manager.

The Journey Begins

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 hand-offs to QA. QA was also now invited to the daily standup’s, 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 – 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 process would change anything – and sure enough, it did! The 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.

The Solution Was Agile

As we prepared to enter 2018, pressure was mounting for the Capsela project, now going into its third year, to be completed as fast as possible. We needed a new approach. On the back of success with the San Francisco Agile trial period, we decided to gather the technology team managers for a three day off-site to come up with a plan to dramatically accelerate Capsela completion. Our Engineering team had never done any planning using “sticky notes on walls” before, so this was all new to them. First, we identified major areas that needed to be addressed. Everyone added big sticky notes to these groups on the wall, and hence became our “Themes.” These Themes included things like platforms, product areas and features, data migrations and tasks that needed to be completed to ensure we had a recovery plan should the worst case scenario of total server failure happen. This overall effort to complete the Capsela migration in an iterative and Agile manner was named the “Minimal Viable Migration” (MVM) plan.

As a prioritization method, we decided to create five Recovery States or “Phases.” Each state would be a milestone in which we would have code that could be activated in case of complete data center failure. We then reorganized the Themes to belong to each Recovery State in a way that the completion of these Themes combined would deliver a milestone where we could switch on this new system if needed. Once the Recovery States were roughly laid out, the team documented what was needed to deliver these Themes. These Themes would later become “Epics” in JIRA: product features, sub-systems and data-specific work – ingestion, extraction and streaming.

This whole plan took several days to lay out. Before starting on the second phase of planning, we invited all the Tech managers into the room, explained what we had done and asked them to review what we had come up with. We then asked them to add any features we had not considered – which, of course, added a whole new set of sticky notes to the wall.

The next phase of planning focused on allocating people to this work. In order to achieve what we had laid out, we knew that we had to reorganize the product and technology teams starting from a blank slate. We wanted to create Scrum teams that could focus on different areas, so we agreed that each Scrum team should have a Product Owner, a Scrum Master and maximum of six engineers. Each team should have a mix of engineers that could fully deliver on the scope they were going to work on; QA, Backend, Frontend and Data engineers were going to be the main team members on the teams. We then made room for “Consultants” – people with skill sets like User Experience (UX,) DevOps, Data Science and more, who would be available to all the teams when needed.

All Tech employees each got their own sticky note pad and we began creating teams. Coordinating this planning session was a puzzle. We have engineers in four major cities along with some who work remotely full-time from their homes. Goals assigned to each team ensured the Themes made sense and fit the team’s goals, while being careful to ensure teams wouldn’t need to split focus between multiple priority areas. This process resulted in the formation of 16 scrum teams.

As a final step, we assigned Product Owners and Scrum Masters to each of these teams. We had one Agile Coach and five Scrum Masters that previously worked mainly as Project Managers, who obviously would have to take multiple teams each. We identified engineers that had already had some form of Scrum Master experience, which took some of the burden off of our single coach who would help get the teams up to speed and consult when needed. The good thing was that we had almost enough Product Owners to have one dedicated to each team with a few exceptions. This did mean that we would have to pair some Product Owners with product areas and teammates they had no prior experience with, so even the Product Owners would have to get up to speed very quickly.

With our wall of post-its documenting the plan, we invited the CEO to join. We presented the recommended approach (the CTO, of course, had kept him up to date on the planning progress along the way). The CEO listened, asked questions, and made the call – DO IT.

Agile Training

Once it was decided that TrueCar would go all-in on Agile and Scrum, I hired an Agile Coach for internal classes for all of our Engineers and Product people. Seven two-day workshops were scheduled, focusing on what Agile is and what is involved when using this new Scrum methodology. We wanted to make sure everyone had the same base knowledge and used the same vocabulary going forward.

For our Executive Team, we held a shorter two-hour information session where the trainer explained what this would mean to the overall business and how it would impact our roadmap and planning going forward. This session was very successful and generated an even stronger buy-in from the CEO.

Lastly, this offered a great opportunity to get all of our internal departments updated on how this could and would impact them in the situations where they had new business ideas, when a partner wanted changes, or when we signed new clients and needed on-boarding for them. The coach created a special round of one-day sessions with all the Business VPs/Directors. The goal here was to share how the new Agile processes that the Product Development department was going to use would impact them, and how they would now be closer to the engineers than they were before. This was something the departments were very happy to hear, as before they only interfaced with a few “decision makers.” Since they would now interact a lot more with the Product Owners of the teams that would support them going forward, the Product Owners were also invited to participate in some part of the sessions to make sure they got the same message and were aligned.

One of the benefits of the Agile process is transparency, and it was an eye-opener to some of our departments what was prioritized in the backlog of their new “aligned” teams. It gave them visibility into how the engineers were assigned to support their part of the business. It also gave visibility into what impact new ideas would have. We already have great wins from this new collaboration with the introduction of an OKR (Objectives and Key Results) based framework for strategic planning – Product Owners work with stakeholders to define OKRs and get input from the team before any new product features are introduced. This way the focus is on the ‘why’ and what the desired business outcome is, rather than simply building a new feature for the sake of output. This has given the team the time and focus to complete what they were working on, and they are now asked to find the quickest/lightest possible solution to validate that the assumptions made beforehand will stick and move the needle on the OKR, before continuing enhancing and investing in this feature.

The Project Managers on the PMO team were present in the first two Agile sessions, and they had their first taste of Agile & Scrum. Not everyone was convinced that this was something they would like to do as a long-term career. I continued to have many conversations with the team, and our Agile Coach began separate coaching sessions with each of them individually, as well as a team. Two weeks before the kickoff, I decided that we had to be more dedicated and focused on getting the project managers on board, so I pushed for a daily, one to three hour training session where we did different exercises like “Walk the Wall” and random Q&A. This meant that each of the Project Managers had to study beforehand and that they had to practice with each other on how to have Retrospectives and daily standup’s. A challenge here was that each of them had these meetings before, but they were much more in control because of their role. These PMs had to let go of past habits and master the art of driving the team without “telling” them what to do. They would not have multiple meetings set up with other teams to coordinate status with them – the teams were now supposed to handle their work from start to end. The PM’s new role was to guide and observe, and use those observations to help the teams improve during the Retrospective. They all took on the challenge and slowly started to master the Scrum Master role.

Preparations for the MVM Planning Days

Now that we’d gotten the OK, the next interesting thing became apparent: how do we prep all these teams and all the people involved?

Several sessions with managers and team leads were scheduled to go over what this MVM effort was all about. Meetings were also scheduled to explain how we planned on executing the two MVM planning days. We had a full day with all Product Owners and Scrum Masters where the MVM Recovery States were explained; we also went over how the JIRA workflow would change and how the new JIRA boards would work. We also provided more details about Story Pointing and Story Writing – two concepts which were very new to most of the Product Owners.

Some of the most common questions were about roles and responsibilities. What were the Engineering Managers going to do in the future? How would the Product Management team work now? This Scrum thing has a lot of meetings, do we need them all? What do we do with cross communication and dependencies? These were all excellent questions that we tried to answer as well as we could. But as anyone seasoned in agile will tell you, some of these questions can be answered differently case by case.

After the initial informational meetings had been conducted with the various groups, our CTO had a full departmental (Engineering & Product) 90-minute overview, in which he explained all the details.

The last week leading up to the planning days, we asked all the Product Owners to meet with their teams and go over the goals and plans for the team. If the teams had time, they also went through and did some pre-planning. Some met and agreed on their Working Agreement and Definition of Done and Definition of Ready. Some teams even got the chance to go over some of their Epics and prep some JIRA issues. Some teams did not have a chance to do this as they had deliveries that were in focus and the current teams they worked with were all heads down. But about 60% of the teams came to the planning days well-prepared.

On the eve of the kickoff, the Scrum Masters prepped the meeting rooms and areas, so they had whiteboards and walls ready with sticky notes and Walk the Wall highlights ready.

The MVM Liftoff

We wanted to make sure we had all the team members gathered in the same place, so the person-to-person experience was the best possible, so we gathered all Engineers and Product people in the main office in Santa Monica, with about 30-40 of them traveling from the other offices. It was truly “all hands on deck.”

The day started with breakfast, and at 10am the CTO and I kicked off the event. Everyone was in great spirits to make this work and the teams that had not prepared their “Working Agreement,” “Definition of Done” and “Definition of Ready” had great discussions around what these should be. We let the teams take their time and did not rush anyone, even though some teams seemed to take longer than expected.

As the day continued, we saw an amazing amount of collaboration and discussions about the goals each team had. Some teams decided that some of the features that they were supposed to “rewrite” in Capsela were unnecessary, as only 0.01% of our users used it, and as they continued to research, they found additional scope to cut. Other teams discovered that they did not need a “Front End Consultant” as some of the engineers wanted to take that on, even though they were not FE engineers. Some of the Test Engineers signed up to write some code that had nothing to do with Test Automation and so on. One of the things we had requested was to identify dependencies and, if possible, bring the people or groups responsible into their space to discuss how they could assist in the planning. By the end of the day, we saw Scrum Masters leading team members across hallways to other teams to have these discussions, and it was amazing to see teams that had never planned anything together before having intense discussions about how to solve problems.

Since we had a limited number of experienced Scrum Masters available, we also contracted our Agile Coach to help us out and consult any team that might have questions or challenges during the two days we had for the MVM planning days. That was a great idea since everyone knew him already from the training session, and it was easy for him to step in and help where it was needed.

Our Agile Coach and I were also trying to help where we could and were walking the hallways constantly to see if anyone needed help or advice. Some of the most common questions were around the usual challenges:

• How to break a story up into smaller stories
• How to deal with dependencies with other teams, people and systems
• How to deal with Story Points
• How to get a story to contain Dev, QA, Documentation (Definition of Done)
• Peacekeeping when personality conflicts between people arose

One of our biggest challenges, which we expected, was how to have Scrum Masters (SM) and Product Owner (PO) be on multiple teams at the same time and work with the teams on details. We had a couple of PO’s that were on two teams, but most of the SM’s were on three to four teams. Some had prepared well, and prepared activities for the teams to do while both PO & SM worked with one of the teams. Others had the PO focusing on one team, while the SM focused on another team. It went as well as could be expected, but it was the biggest complaint from the SMs afterwards – they felt they were not helping enough, as they were constantly running between the teams.

By the end of day one, almost all teams had completed the creation of their backlog. It was interesting to walk around all the team spaces to see how most of them had done it the same way, but some in more detail than others. Using different colored sticky notes for issues with dependencies, or Epics vs. Stories, etc. The Scrum Masters and our Agile Coach and I were pretty beat as we had to support multiple teams during the day and some of the Scrum Masters were running from room to room. Our Architects did an amazing job helping, especially the newer teams to align and explain the details of some of their goals.

Day two was different. This day was more “heads down’” as most of the teams were concentrating on splitting stories and planning the next three sprints. For some teams, that ended up being a big challenge as they discovered that almost all their first sprint stories were going to be research Spikes before they would be able to write the detailed stories that would be needed for planning. This came as no surprise to us. Because of the way some teams were structured, there was not enough tribal knowledge on these teams, and they would have to research, interview and get knowledge transfer from other engineers and product people.

The teams worked together on prioritizing each of story and arranging them in their initial three sprints before story pointing them. We knew story pointing was going to be a discussion point, so we wanted the teams to be more focused on what they thought they could do, rather than bring old habits from their previous teams. This worked well – the teams worked together on this and ended up with three “ready” sprints and a backlog of issues to work on in a later sprint. After that was done, the team (mostly the Product Owners) wrote all the issues into our JIRA project, so they were ready for the sprint to start the coming Monday.

Some teams were done early and began the sprint that day, other teams were not totally done, and they finished their planning during Friday.

Around 4 PM, happy hour kicked off with beer, wine, pizza, and a lot of discussion between teams continued. I heard several team members comparing notes and explaining to other teams how they approached certain situations. A lot of people were mentally drained after two days of planning and discussing product details; it was a totally new experience to most of the people as they never paid attention to product planning before, as well as trying to figure out how that fit technically into the system architecture we have.

All in all, these were two great planning days that exceeded expectation that this would carry over to become a long-term product development lifecycle solution that would bring the company ahead of the game in the long run.

JIRA and CI/CD

The company had, as mentioned above, worked on implementing CI/CD (continuous integration’s & continuous deployment) over the last year, but never quite got the last pieces into place. With the new JIRA structure and more focused teams, we also saw an opportunity to focus and complete the CI/CD effort. For Agile to work best, you should have a strong CI/CD process. This will help you deploy often and quickly, and give you good opportunities to learn and adapt constantly. Our CI/CD specialists put their heads together and came up with a plan that we could all agree on. At first, we thought we could get it all ready for the MVM planning days, but quickly realized that we needed at least another month to complete this. But with a good three phase plan, we are now very close to the full implementation.

JIRA continues to become cleaner. We are now down to five JIRA projects that are used for different Product Development groups (down from about 25), and all five projects have the same workflow, issue types, screens and fields, which is resulting in simpler processes and cleaner data to report on. And most of the teams are now happy that they do not have eight different states to move issues to and from.

Agile Organization

After we decided to go the Agile route and began plans for our Agile Transformation, our CTO handed the teams the reins and let us run with it. In parallel, he began to think about how the TrueCar organization could support this. Many companies today think that the organization can continue in the hierarchical matrix organization where managers make decisions, and it somehow trickles down to the Agile teams. But this is where a lot of companies fail; our CTO did not want to fall into that trap. He collected a tremendous amount of feedback and worked with his leadership team to architect a new organizational design.

Exactly one month after kicking off of our Agile Transformation, he announced a new departmental organizational structure to the team. The main changes here were around how Product Owners and Product Managers were organized. To avoid Product Managers controlling the Product Owners on the delivery side, they were separated from a management view, but not from a Product strategy driving perspective. The Product Managers would act as Tribe Leaders and own the overall direction of their Tribe. Each product line would be known as a Tribe, and within each Tribe, you would have one or more Scrum Teams—some of the larger Tribes could also have sub-Tribes in their structure. The Org structure would have its own Product Management (delivery) structure where all delivery instances (UX, Data Science, Scrum Teams) would live with their Product Owners. And Product Strategy (Vision and overall goals—OKRs) would be its own structure. This means the Tribal Leaders would work closely with the Product Owners regarding Vision and OKRs. They would explain the Objectives they would need to focus on and deliver quarter by quarter, then the Product Owners and their Scrum Teams would find the best solutions that would cover these goals (OKRs) (more about OKRs below).

The Engineering group also got re-shuffled to have a leaner management line that could focus on people and team growth. The main thing that the Development Managers would focus on would be growing their direct report’s skills and careers. They would make sure they worked well with the teams and supported their need to acquire additional skills as the teams would work more and more towards full-stack engineers.

To support this, “Chapters” were created—this would be each manager/director’s groups, and each Chapter would now be led by a Director.

To support skill growth and sharing experience between fellow front-end, data, QA People Guilds were set up, sample: a Front End Guild would be a group where anyone that had interest for Front End work, etc. would be connected (Slack channel, weekly meetings, etc.). By joining these Guilds and having Slack discussions and weekly meetings, the health of the architecture, alignment, focus and design would stay healthy. This structure is probably most known from the famous Spotify model which introduced it in 2006. We took this model and modified it slightly to fit our company structure and culture.

Beside the Development and Product teams, we are also considering bringing in some of the Business teams to work within a more Agile structure, more about that later.

Next Steps

This completes our main story around how we kicked off our Agile Transformation at TrueCar in early 2018.

Please look out for follow-up blog posts that will describe how our Agile Transformation continues to progress and our continued learning’s in start of 2019. Some things that we are currently working on is:

• How the individual roles experienced working with Scrum & being Agile
• Getting CI/CD fully implemented
• Completion of the Capsela project
• How A/B testing new features/enhancements is helping us build the right things
• Moving into using OKRs across scrum teams & company wide
• Finding the correct tool to report on Initiatives and OKRs (executive facing)
• Learning’s

Credits

To make an Agile Transformation like this successful there is a great deal of dedicated people involved, working as a team and I want to mention some of them here.

• Tommy McClung our EVP & Chief Technology Officer for supporting this and believing in us.
• Chris Denend, SVP, Product Management, this was a big change to his org and he backed every move.
• Marco Santini, VP, Software Engineering, this transformation probably affected him the most of all, and he helped in so many ways every step of the way.
• Elena Vassilieva, Agile coach, she helped coaching and mentoring day and night, and kept me in line when I wanted to take shortcuts.
• Tom Haines Senior Director, Technical Product Management for all the help in getting all the Product Owners onboarded and asking the critical questions.
• Nick Sarnoff, VP, Product and Technology Operations for stepping in and helping getting the Product management on board and helping with some great Tableau reporting and driving the new OKR approach, as well as helping with the editing of this writeup..
• The entire Engineering management team for their support in planning and keeping making the right choices.
• The PMO team for stepping up and transforming into Scrum Masters in super speed.
• All in Engineering & Product for playing along and being flexible.
• John Miller, AgileForAll for being an excellent agile trainer and his strong support during the first 2 months.