Development in the age of Mobile

I want to work in an agile way, my team wants to work in an agile way, but we’re just a small part of a much larger organisation that doesn’t work that way at all. What can we do?

Note to everyone before we start: The term Done in digital is a hidden concept. Because you are never done improving and adjusting to the current user demands.

As most developers know, even when you “know how to code”, it can be really overwhelming to embark on the creation of your first app. In sports organization specially, you have only One Chance. One Opportunity. To capture the user. Or let him slip . — Drop the Lose Yourself, Eminem soundtrack. 

If it doesn’t appeal to the user from the first go, you’ve lost them. So the challenge was, how do you make 4 apps, for 4 different targets, 4 different competitions that will capture the attention of the user?

Do the simple thing. But do it well.

Step 1: Ideate

The first step was to figure out what exactly we wanted to build. In my past life at BAM Strategy, I led ideation workshops with corporate leaders, developers, account managers and with people that were never involved in the ‘’process’’ (aka our receptionist). The motivation was, you never know where a cool idea can come from. Pulling from that, I suggested to my group the classic post-it brainstorming strategy, but on Skype, or better, Invision (If you haven’t tried it yet, invision is pretty awesome) in which we all scribble out as many ideas as we can — even ‘stupid ones’ — put them in a confluence pages (Thank you Atlassian) so that people’s brains keep moving and no one avoids voicing ideas out of fear.

On the side, we had to give a bit of framework to our ideation process. Getting ideas is cool. But getting ideas based on data is even cooler. This was our personal motto. From experience, the death of a product starts off with the assumption of the top level management thinking what we people or sports fans actually want. Let me illustrate that for you:

Here is an actual dialogue that may or may have not happened with me or my fellow digifellows:

• We need to get on snapchat.
• Why?
• Saw my daughter using it and she told me it is the best thing ever.

As a base, we started off by looking at our analytics from the website. It was fairly easy to identify some sort of trend. Issue was, with no sign in technology, you will have to assume certain things. So this is where the valuable experienced people from the office will come in handy. Where they will tell you: ‘’We tried that but didn’t work” or “We tried it, it worked, but no more budget”. 

Result: Seeing that most of our users are mobile, and most of the mobile users are interested in live and on demand statistics. And there comes our vision.

Unique Live Basketball Experience: On the go and on demand.

Next, on a white board, we drew out the basic views we envisioned in our app. We incorporated our set of user stories to understand how these views would work in a skeletal app framework.

Step 2: Wireframe UX/UI

TIP: Split the features in different batches. Pick a series of screens that are interconnected and work on those (i.e: Batch 1: News, Social Feed & Videos; Batch 2: Team Profiles & Player Profiles). Once done, move to the next batch. This will help you with feedback, testing and getting user tests a lot quicker.

Then comes the painful part, build the actual designs and get the feedback. If you are in university in a team project, or an employee, you should know by now that everyone has different schedules & different priorities. So you want to make this process as painless and quick as possible. 

Solution: One meeting, put everyone in the room and dissect the entire design from head to toe.

Once THAT is done… your job is not done. Send the notes to everyone, because there are the ones that didn’t speak at the meeting, and there are ones that will go: at second thought… I change my mind, so scratch what I said.

Step 3: Choose a data structure and type of database

The mobile ecosystems is incredibly vast: with package managers, modules, build tools, transpilers, databases, libraries, CDNs (everyone should love CDNs) and decisions to be made about all of them, it’s no wonder that so many coders never build anything beyond Codecademy tutorials.

It was now time to design our data structure. Based on our wireframes and user stories, we created a list in a Google doc of the models we would need and what attributes each should include. We knew we needed a ‘goal’ model for the data layers to be structured. Something that can sustain 4 different mobile apps, a high live coverage, a LOT of Content: photos, videos & articles. And to sum it all up it needed to deliver the content fast. Let me repeat that. FAST.

Step 4: Build a “Proof Of Concept” aka Live test.

Our next step was to create a “proof of concept” for our app, or a prototype of the most difficult fundamental features to implement, demonstrating that our app could eventually exist. 

TIP: get it out as fast as possible, because static design on invision can give you an idea of the best case scenario, but ain’t no party like a real data party.

But here comes the messy part. The previous steps, were only tested on offline and static data. So in sports terms: Competitions that were already over. And as you may know: Even if you have done 300 events, each one of them will have something that will make everything completely different.

First event test. Failure. Complete disaster. Not to mention that we shared the build with over 30 people to see it live. The idea was: hey we are making progress. But it looked like we didn’t. At all.

Another Tip: Tighten your stomach and get ready for an avalanche of email and comments. 

Let me describe what just happened: stats were updating every minute. Sometimes every 2 minutes. How can you possibly build something that follows a sport that has an action every 5 seconds, but it updates every minute. Users would go nuts if they see that. Actually they won’t they would just just delete the app. There has to be something to do to improve. So what do you do?

Find and squash bugs

While we should have been using test-driven development from the beginning, time constraints left us with precious little time for anything but features. This meant that we spent the final month simulating every user flow we could think of and hunting our app for bugs.

Step 4: Deploy the live app

 If we had a longer runway, Step 4 would have been to run A/B testing on users, so we could better understand how actual users interact with our app and what they’d like to see in a V2.

TIP: Don’t forget your promotional plan. You might want spend a lot of money and time on building something awesome. But if no one knows about it, then it will be just awesome for you.

This is all nice but what did we learn?

Emphasize Progress in Iterations

Some people get spooked when you show them early iterations designed to be improved or set as ‘’work in progress’’. Keep calm and explain that it is a working prototype. For many non-agile folks, their instinctual reaction may be something along the lines of, “where’s the rest of it?” or “yes, but we still need x, y and z…” and so on. Let them finish, then explain when you will be getting to that.

Suggest User Stories Before Solutions

Another issue you might face is that for many non-agile people is the tendency to jump to a lengthy, prescribed solution without clearly and thoroughly explaining either the actual user need or the problem that needs to be solved. Get them to explain what they want the user to do, not design the feature.

Respect existing roles and processes. 

This follows on from the point above. Just because you’re agile, it doesn’t mean that you can expect the rest of the organisation to bend around you. That will never happen. So make a point of learning how they do things already, and how they’ve done things for the last 10 years. It’s fine to ask “Why is it done that way?” but don’t say “That’s a daft way of doing it, you should do it like this instead.”

Continuous Improvement is better than delayed perfection. — Mark Twain

To be continued in the new series: How things work? Be fast, but not perfect.