Dumpster Fire to Dream Team
Overview
Turning around a team in crisis, becoming the team everyone wanted to be on within seven months.
The Challenge
Team X began from the acquisition of a small startup by a large corporation. The team needed to integrate the product into the enterprise platform and bring it to scale with an entirely new infrastructure. The first product owner came from the enterprise side and was spread too thin across multiple products. The team grew quickly, and committed to a series of over-designed features on an unreasonable timeline. The team missed a critical release, failing at the 11th hour, and then PO left the company.
I came in as the Senior Product Owner to rebuild trust, recover the product roadmap, and regain lost momentum. I was a full-time remote employee for the duration of my time on the team. 10% of the team was in New York, 70% were in San Francisco, and the rest were remote across the US. Coming into this type of situation can be challenging enough with a full onsite team, and it added to the complexity of getting everyone on the same page.
Team
We went from a small startup team of 8, ballooning to 20 members within a large enterprise organization. I began as the UX lead on Team X, transferred to another new team as the Senior Product Owner, but came back to Team X when the PO departed.
1 Scrum Master
1 UX/UI Designer
1 Engineering Manager
3 Testers
1 Testing Manager
12 Engineers
1 Product Manager
Constraints
The team had a two-month reprieve to make the missed release and four months to get on a bi-monthly release cycle. These were very aggressive timelines in the world of federally regulated and validated software, newly implemented at the corporation.
Process
My first step was to put out the fire. I came up to speed on the designs for the failed release and worked with the Engineering manager to reduce scope as gracefully as we could. We then had a marathon grooming session to get the team on the same page and able to resume work on the revised feature set.
The next step was to evaluate issues in the team’s workflow, identifying the pain points, and finding solutions to improve the team process.
Pain Points & Solutions
Siloed Work | Create Shared Understanding
Despite full-team grooming sessions, the front and back end did not understand what we were trying to build, and there was a divide between the configuration service and the app it supported. Individual team members were looking at the product through a straw, instead of seeing the features holistically. I set up a Product Review lunch. In that 2 hour meeting, we revisited why our product exists, how it accelerates clinical trials, demoed the configuration service and product end-to-end, and then gave an update on planned features. The new meeting gave important context and connected engineers and testers to the “why” of our work. I recorded it for onboarding material for new team members, and it was successful enough we committed to doing it every few months.
Lack of Process | Scrum Fundamentals
The team was moving at an inconsistent pace: slow, fast, slow, fast. It was frustrating and blocked engineers/testers from reaching their optimal output. There were a lot of high-level issues that would take more time to solve, but I knew I could quickly alleviate the pace problem by revisiting Scrum methods for in-flight features. I partnered with the Scrum master to identify where we could improve. Previously, acceptance criteria were written by the PO in the grooming meeting as dictated by the team. I committed to sharing upcoming stories with draft criteria 48 hours before grooming to give the team time to review at their own pace and arrive at grooming ready to discuss. We had quicker and more focused sessions, resulting in better acceptance criteria and a happier team.
Vague Roadmap | Revive the Backlog
As a startup, it is a priority to stay nimble and responsive to the market. As a large team within an enterprise platform working in a regulated environment, we needed more time to design out and plan features. The team had been waiting for the roadmap to be approved before starting the design phase, missing out on the benefits of a long tail in an Agile process. I started defining possible features earlier, managing a curated Agile backlog. Starting conceptual design earlier allowed for the time to iterate, validate solutions with users, include engineer feedback, and resulted in better designs.
Prescribed Solutions | Start Problem Solving
Stakeholders from Product, Sales, and Design spent time in meetings talking through solutions, but not a lot of discovery or time spent solving creatively. The designer was frustrated and forced to waste time iterating on high def designs that ended up canned.
I introduced problem definition into the process to:
Understand how a client problem presented, as well as if the problem challenged all our clients
Gain insight into if the problem could be worked around in the current feature set
Avoid wasted time on an issue limited to one client for a feature it is not advantageous to pursue
Starting with robust requirements, UX and Product shifted to discussions focused on how to solve the defined problem elegantly.
Vague Direction | Product Requirements Document
Features were given cursory descriptions in Aha!, the chosen product management tool, but lacked the detail needed to create thoughtful solutions. The team had used requirements meetings to debate button placement with stakeholders instead of problem definition and approving requirements. Creating a Product Requirements Document for each feature gave us a stronger set of requirements for stakeholders to review and respond to at set intervals. Then I used the content of the resulting document to define the feature epic, giving the Engineering and Testing teams a deeper understanding of why we were creating a feature.
Unbuildable Designs | Involve the Right People at the Right Time
Product was keeping up with Sales, Professional Services, and Clients, but Engineering did not see designs early enough. Requirements had moved away from gathering and validating requirements towards design approval. We looped in engineers sooner and more frequently, leading us to design buildable solutions right out of the gate.
Conceptual Epic Sizing | Story-mapping & T-Shirt Sizes
Product had been planning the roadmap off back-of-napkin math estimates. That pattern made Engineering uncomfortable and had contributed to the missed release by grossly underestimating the level of effort. I introduced story mapping to improve feature breakdowns. The team got comfortable with t-shirt sizes when pointing and became increasingly accurate in their estimates. These changes made release planning better scoped, efficiently conducted by using proven Agile methodologies.
Tech Debt | Budget From the Start
The Engineering team had been saying that tech debt was becoming an increasing concern with each release. I knew the pile of unresolved issues was mounting and would come back to haunt us. The scrum master suggested we commit to 10% of every release for tech debt, formally tracking and revising design “shortcuts” meant to solve immediate issues that end up causing more problems in the product long term. I enforced this and collaborated with Engineering to prioritize and track ongoing tech debt in an epic.
Retrospective
When I took over as Senior Product Owner of Team X at the end of September 2018, the team was in crisis: blocked from producing usable software, dispirited, and scared. I was lucky to have trust already as a former member of the team. The engineering manager and leadership were stellar partners in their support of these changes. I started by putting out the fires, then used Agile process to improve work conditions and enable the team to work efficiently.
In the spring of 2019, we were releasing on schedule, hitting a seamless rhythm, and thriving. For the April release, there was a concern about quality on another product raised at the SVP level. Every product in the company went through a fire drill to examine validation and release quality. Team X owned the ONLY product in the entire company to pass inspection and release. After that internal publicity, we were suddenly the team everyone was trying to transfer to join.
My team and management publicly recognized me for my contribution to turning the team around, and Engineering leadership awarded me a $500 experience in the employee recognition platform. It was a team effort to turn around so quickly, and I thank the members of Team X for making our success possible. I am very proud of how I enabled the team to do their best work and how we all exceeded expectations with our results.