My App Should Be Dead - How a Retrospective Saved My Software

Beep Beep Beep Beep…………..Beeeeeeeeeeeeeeppppppppp

We were screwed. Plain and simple, we didn’t know what to do.

I thought working at Applico for 5 years had prepared me for everything. Ideas, apps, businesses have all come and gone; some good and some bad. One thing that never concerned me however, was the team’s ability to execute. We have launched countless apps and with each project we improve. Whether it’s risk mitigation, engineering prowess, team building, etc…something always improves. So in a world in which technology changes and trends come and go, one thing has been consistent?—?the team.

But to my amazement, 60 days ago, I sat in my office with my jaw on the floor.

“Matt, we aren’t going to make the deadline…”

I had been here before, rarely does software ship on time. How bad could it be? 2 or 3 weeks late I thought to myself. Max.

“We are delayed….by two months.”

I was floored...how could this be? We did proper risk mitigation. We knew the technology challenges. We understood the core competencies of our team. We were two months into a project with two months to go and I was just now hearing that we were expecting a two month delay. What did we miss?

The App

Let me take a step back and describe to you what we are building. I’ll save you the suspense, this story ends with us closing in on a launch…but I got a real chuckle last week when Meerkat went viral. That’s the app. That’s what we are building, only better.

Meerkat starts as novelty and ends as a Twitter nuisance.

Our app has legs. Yes it’s an app that allows real time streaming to anyone, anywhere, all from your mobile device. On the surface it sounds straightforward…another twist on a social network with video as the bait. But it is much much more than that.

We aren’t building an app, we are building an ecosystem and a business: social marketing, back-office software, landing pages, apps for iOS AND Android platforms...Applico is doing it all.

And when I sat back and thought about it…the scale of what we were doing was overwhelming. To be clear, that’s not the issue and that’s not what this article is about but it’s incredible to think about the amount of “app” sweat, blood and tears that have gone into this.

“Lets have a meeting”

Don’t get me wrong, with 60 days to go I was happy that we weren’t racing to the finish without poking our head up for air. We knew something was wrong and the whistle was blown. But what the hell happened? All of us got together; the engineering team, product and design teams, QA and leadership. We sat there and went around the room and spent an hour discussing the project’s issues. There was no finger pointing, no one was screaming from the mountain top. We were a team and that mattered now more than ever.

It didn’t take long to figure out there were major issues. They boiled down to this:

1. The backend had no ownership…who was responsible? The iOS and Android teams were “sharing” the responsibility and not communicating with each other at all. Whomever got to implementing a functionality first had to support the backend.
2. This project was meant to be cross-platform. However, our Android and iOS teams were having separate standups as if each project was independent of each other. Nuts.
3. While the QA team had test cases, the iOS team wasn’t aware of them. This wasn’t necessarily the fault of the iOS team, but was still very surprising.
4. Requirements were inconsistently defined.

Once we laid everything out on the table it was clear to us who and what the culprit was. English. Talking. Collaborating. Problem Solving. We were all so focused on each one of our individual responsibilities that we lost perspective on the bigger picture - moving the product forward as a team. It was complete tunnel vision. It was our coming-to-Jesus moment and most importantly, unbeknownst to us, it was our first retrospective.

Our Action Plan

I won’t bore you with the details of what makes a good retrospective, but if you don’t know what one is or want to read about what makes up a good one The Scrum Alliance has a good description here.

We changed our approach dramatically and did the following:

1. One of the Android developers took ownership of the architecture in totality - all the endpoints, syncing data caching all cross platform, etc.
2. Architecture meetings with the development teams got put on the calendar for once a week.
3. We combined iOS and Android standups to increase collaboration across the teams.
4. Our designers worked more closely out of Android Studio and Xcode, checking tweaks right into Git themselves.
5. We committed to working closely with our QA teams to understand what they were testing and likewise our QA teams committed to understanding the product better than the product team itself.

But most importantly, the single biggest improvement we made was to commit to an ideology. From that day forward we committed to bi-weekly retrospectives. We committed to measuring and learning and most importantly we committed to moving forward not as individuals with individual responsibilities but as a TEAM.

The Aftermath

From that day forward things changed. We had bi-weekly retrospectives where we talked about the good, the bad and ways to improve. We measured our improvements from that day forward. We saw bug counts decrease, collaboration increase and an improved dedication to the product.

We had done retrospectives before, it wasn’t new to us. In fact it’s silly that I am even writing about this. But for whatever reason the scale of the project created a weird sense of focus. Laser focus on the details and we lost sight on what was important.

I can now safely say we are going to launch an app for both iOS and Android platforms in 30 days...Meerkat look out.

Beep. Beep. Beep