Project Liftoff - Pt. 2

Phase One: Minimal Viable Migration
 
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.
 
Phase Two: Divvying up the work
 
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 ScrumMaster, and a 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.
 
Phase Three: Assigning POs and SMs
 
As a final step, we assigned product owners and ScrumMasters to each of these teams. We had one agile coach and five ScrumMasters 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 ScrumMaster 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 boot camp begins
 
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.
 
Transparency and visibility
 
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 whyand 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 and 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 and 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 stand-ups. 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 ScrumMaster role.
 
Preparations for the MVM planning days
 
Now that we’d gotten the go-ahead, 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 ScrumMasters 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 90-minute overview with the Engineering and Product teams, 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, 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 percent of the teams came to the planning days well-prepared.
 
On the eve of the kickoff, the ScrumMasters prepped the meeting rooms and areas, so they had whiteboards and walls ready with sticky notes and Walk the Wall highlights ready...

Will the teams be ready for the change? Keep up with the next stage in TrueCar's story with Part 3, coming soon.