Menu

Release is coming! A team’s journey towards beautiful release

05 October 2017

As a media company the TV experience is important. So moving our Playplex app to Android TV and Fire TV was a necessary step.
Sounds like a simple enough task, but often things are not that easy. We were confronted with a fixed deadline, while we were in the middle of merging with another team. Most of us were not familiar with Android TV before and this release would also be for a new brand, VH1. This would also require UI changes to our existing phone app. And all of this with an ambitious deadline.

Descope

You can only do a limited amount of work with the limited resources and a limited of time. In situations like this, what you need to do is: descope. Everyone (yes everyone), needs to look at what really needs to be shipped. What are the must haves?

Sounds obvious? It’s often easier to drive the team towards disaster than break down your goals into achievable steps. Promises have been made and goals set before any development has begun, it can be hard to communicate changes to those. People often tend to play favorites with features and it’s hard to throw away your babies.

So what normally happens is cutting down on code quality or removing the need for unit tests. The developers would run towards the deadline although everyone knows that the likelihood is that they will not make it. They will probably stumble before the finish line and break their legs: a recipe for disaster.
Cutting on quality is wrong and always will be! It is our responsibility as engineers to make sure this does not happen. If the deadline is fixed, cut features, but never cut quality.
To quote Uncle Bob:

The only way to go fast is to go well!

Get everyone on board

If you commit to a release, do that with your full team! Bring them in and let them commit to whatever they agree!
That can’t be forced. If you do, you have a recipe for disaster.
In our project we cut features and design until the team felt: now it’s possible. Still we didn’t know for sure that we would make it, the plan was still ambitious. But it was not impossible to get there! The last thing you want is that the team knows it’s not possible but the stakeholders still think you will try. Get everyone on board! Make them care! Then you can make it possible!

Define “what” let the team decide the “how”

On the technical side: based on some previous tests we decided to use MVVM with Android data binding for this release. Still open was the question of Java or Kotlin. The team had used Kotlin in tests for quite some time. But as we merged with another team we weren’t sure of the overall confidence level.
A question like this should not be decided by someone from the outside. Ask the people who have to use it daily. Therefore we left it to the new team members to decide. And the response was to go with 100% Kotlin.
By allowing the team to decide, you give them trust and in return, you get commitment.

Make it beautiful

Kotlin made it possible to write much less code than we would have done with Java. It was also a great fit for writing the ViewModels for MVVM as you can expose properties which is exactly what you want. So less code and much more beautiful.
We still found areas where the code was a bit ugly:

Spending time on this might sound weird in the first place as we had that tight deadline. But reducing boilerplate made us write less code, which made us faster. The code became easier to read, faster to review and easier to change.

Fighting Leanback

We had some challenges using data binding on Android TV. The Leanback APIs required by Android TV are a bit outdated in terms of architecture. Like in the earlier days of Android development it’s all based on Fragments you extend. You have no access to the underlying RecyclerView (which probably was a ListView earlier on) or to the XML.

This was a problem as data binding is all about binding the XML to the view models. Our solution was to create a lot of WrapperViews and custom binding adapters to still make that possible:

Keep focused

One recipe for success is to make sure developers can do what they do best: developing! Again sounds obvious but often we are stuck in meetings most part of the days.
At some point when it was clear what we needed to build we cut all meetings that were not technical. We would do weekly demos to stakeholders as they were completely blind now, but other than that we focussed on making the release possible. The productivity increased a lot! Fight meetings, when needed, even the agile ritual ones.

How did it go?

After a slow start we needed to prepare all the basics, the architecture made us super fast. Week by week the application made massive progresses. Changes were very easy to do. Most of the time it was just a few properties in the view models to make a full feature become alive.

We made sure the team was focused: Focused on the actual work (no distractions) and focused on only the work needed (find the nice-to-haves).