My Most Important Learnings as a Mobile Application Project Manager
What I’ve learned as a project manager after 5 years of mobile development projects
When I first started managing mobile projects, I felt lost. Of course, I knew nothing about it, and I was intimidated by the technology and the developers.
Do you have a list of questions you’d like to ask developers?
If the answer is yes, it’s because like me, when you’re starting out in your role as a mobile project manager, you need to feel supported, to have a complete vision of the steps to follow, to feel more comfortable and confident.
I’ve been a project manager for several years, and I’ve managed a dozen mobile development projects.
I’ve been around the block a few times. I feel seasoned and the positive feedback from my colleagues reinforces this feeling of accomplishment.
If you’re just starting out in the business or in the Mobile field, and you’d like to be supported in your day-to-day work, by understanding the major Mobile issues, then read on.
I hope you’ll have as cool and rewarding an experience as I did.
The specifics of mobile applications
Do you know that your project can succeed or fail if you don’t take into account the particularities of Mobile?
There are similarities between mobile and web development projects. But there are certain characteristics that you need to take into account, as they affect your organization and your team’s actions.
So, here are the main features of mobile applications that you need to take into account:
Two platforms
First of all, when the application is native, it is developed on 2 platforms: iOS and Android. This means working with 2 developers for the same functionality.
Developers challenge each other — while iOS works on one feature, Android advances on another. They exchange information on the difficulties they encounter to avoid reproducing them.
At that point, you can ask how development is going, what the obstacles are, and what you can do to overcome them.
It’s a good way of showing your interest in the work of developers and your curiosity.
UX / UI
Mobile projects emphasize UX/UI — User Experience and User Interface — more than any other IT project.
To be an application is to be under constant pressure from the competition.
That’s why it’s particularly useful to focus on the user, gather feedback and measure progress.
If you don’t have access to users, you can ask people in your company to test a user path, to choose between 2 functionalities, to ask for their feedback.
This will enable you to carry out User Research with the means at hand.
Innovative smartphones
Smartphone functionalities are becoming increasingly innovative. These include geolocation, motion sensors, cameras, gyroscopes and more.
This calls for the development of applications that make use of these advances.
It’s a good idea to keep up to date with the latest developments.
This will give you ideas on how to adapt the user experience.
Processes for each OS
Finally, applications must be approved by the Store before being published.
Apple and Google publish their guidelines, which you should read to understand the principle and apply their advice.
In the event of invalidation, your schedule may have to be revised. But don’t worry, it happens, especially on the Apple side, which is very attentive to security.
Here are the resources for Apple Store and Google Play Store.
With this initial information, you should feel more at ease about the technical issues and constraints involved in the project.
In this experience I work in a small team. But before going any further, to talk about communication with developers, I’ll explain how my project team is made up.
What’s a small team?
As you can probably imagine, not all companies have the resources to build Agile teams.
Let me introduce you to my team:
- Ben (iOS LeadDev — 10 years experience)
- Marvin (Android LeadDev — 8 years exp)
- Corentin (iOS developer — 1 year exp and 3 years in hybrid)
- Aurélien (Android developer — 1 year Android experience, 2 years work-study)
- No Scrum Master, No Testers
We’ve built our team very carefully:
Leads are experienced, but developers are junior. It was a choice.
The project gave developers who wanted to learn a native technology the opportunity to do so with support.
No Scrum, no tester:
As Product Owner, I’m in charge of leading the ceremonies (and preparing them).
I also test the application before publication.
Sometimes the LeadDevs take charge of the Scrum Ceremonies.
And to make testing easier for me, it’s agreed that each developer checks his work.
It’s a question of mutual help and support.
A small, dynamic team
What’s really important to me in our day-to-day work is communication.
For me, communicating means quickly understanding what we expect from each other, without getting bogged down in tedious processes.
No headaches, no unnecessary constraints.
We aim for efficiency and a good working relationship.
I’ve even set up my office next to the developers, to make my life easier.
I can ask them questions if I get stuck, and I can see what they’re working on without interrupting them.
This promiscuity means I don’t have to waste time on chat questions, and I save them unnecessary reading.
Another point that seems important to me in communication is not to set filters. With developers, we talk directly, always respectfully, but always with a view to efficiency.
Believe me, this makes it much easier for us to trust each other. It’s clear that we’re passionate about our work, but above all we’re committed to the challenge of the project.
After months of work, it’s a real pleasure to celebrate the success of a project with the whole team!
We’re interested in everything: the technology, the evolutions to be developed, the relationship with the customer, the methodology.
I’m particularly curious about new approaches to project management. In particular, I’ve discovered and experimented with the BDD, DDD and TDD approaches.
It’s really rewarding to see your skills grow as you practice.
To implement these successes, I don’t have a ready-made strategy for you. In fact, I just let things happen and take an interest.
The important thing is to start with motivated people who love what they do.
It’s a state of mind.
Managing (limited) resources
We’re a small team, so we don’t have a lot of resources.
But then, you may be wondering, how did we become ultra-efficient in our day-to-day work?
I’ll tell you how.
Priority to value: What creates a wow effect becomes a must-have
When you don’t have a lot of money, you have to go for the essentials.
To what pays off the most, in terms of user benefits and customer feedback.
To be effective, I prioritize. Here are the methods I use — you’ll come across some acronyms, but I’ll tell you more about them in a later article:
- Value vs. Complexity Matrix
- MoSCoW
- Eisenhower Matrix
- Buy a Feature
- RICE
- User Story Mapping
- BRICE
Breaking down tasks: A developer-sized user story
To be efficient, I break down my functionalities. This allows each developer to focus on the priorities of the moment.
This could be redesigning a screen, creating a new entry, adapting an existing one…
It doesn’t matter. I take this functionality and reduce it in steps, until it can be transformed into a User Story.
A developer can work independently on this US.
When the breakdown is complicated. I ask a developer to help me.
Here are the 4 cutting levels:
Epic → Feature → User Story → Tasks → Sub-tasks
Epic is too big to be implemented in a single iteration or sprint.
Feature is implemented independently.
User Story focuses on one feature.
Tasks break down a user story into steps.
Sub-tasks follow the steps involved in completing a task.
Example
Epic: Modernization of Bank Transfers
Feature: Redesign of the bank transfer process
User Story: As a user, I want to be able to initiate a transfer quickly from the home screen(Gherkin)
Given as a regular user of the banking application
When I want to initiate a transfer
Then I want to see a “Transfer” icon on the home screenTask: Add a “Transfer” icon to the home screen
Sub-task: Design a transfer icon
Sub-task: Integrate the icon into the home screen user interface
Sub-task: Check icon visibility and usability on different devicesTask: Redirect the user to the transfer screen when he selects the icon
Sub-task: Implement redirection logic to transfer screen
Sub-task: Ensure correct management of authorizations and authentication
Sub-task: Perform interface tests to ensure smooth transition
Specifying tasks in Gherkin: I take my inspiration from BDD
Once the task has been created, I specify the ticket using Gherkin syntax.
This BDD-inspired working method gives me a model to follow in my specifications.
I’m more efficient this way, because I’m applying a method that has been tried and tested with technicians.
Here’s an example to show you the syntax and what it looks like in a User Story:
Frequent delivery: the right pace for us
The efficiency of a project also depends on delivery.
Our sprint has a 3-week rhythm, which seems favorable.
But that doesn’t mean we deliver every 3 weeks. It’s a question of delivering only when necessary (anomalies in particular).
Choose your tools: Don’t formalize best practices
To be efficient, even with limited resources, we use practical tools and extensions.
I’m thinking of Slack, which lets us exchange information via chat channels.
With Slack, I can integrate extensions such as Poker Planner.
All you have to do is run the /pp command and type in the name of what you want to encrypt.
Add your team members and you’re off to the Fibonacci suite!
I’ve also chosen to follow the project on Gitlab instead of Jira.
This may sound crazy coming from a Product Owner, but the tool was just what I needed.
The advantage is that we’re all working on the same tool. No need to switch from one tool to another.
Multiple skills
To be effective, I rely on the skills of my team.
I recognize that I’m very lucky: the developers on the team train each other (iOS and Android). This makes my life easier, because if I’m absent, I can ask an Android developer to check iOS work — and vice versa.
The LeadDevs each have a specialization:
- I can rely on one of them to take over project management. He creates issues, specifies them and manages communication with the customer.
- I can count on the second to challenge the application’s UX and UI. His vision enables us to propose new functionalities and work on developments we like.
Balancing priorities and deadlines
A project moves forward thanks to the developments, but also to the order of priorities we give them and the deadlines we set for them.
To balance priorities and meet these deadlines, I find that User Story Mapping is the method that gives me the best visibility of future iterations.
Even though I work in Agile, I’m also able to provide my customer with a delivery date. If the date doesn’t suit, I discuss it with him and we rediscuss the scope.
Putting it into practice:
Our banking client needs to comply with KYC — Know Your Customer.
He wants to integrate a new partner who will check customer identities — facial image and photo of both sides of the ID document.
The integration is eagerly awaited, and a start-up date has been set which cannot be postponed in the event of difficulties.
At present, the team’s backlog is already quite full. I know from experience that this KYC integration will come on top of our planned developments.
So, in order not to put the customer at a disadvantage, to ensure the KYC addition within the application and to preserve the team, I ask to stop all work in progress.
With the customer, I take stock of what’s important, and how it could be planned.
On a Story Mapping, I then schedule the features over several sprints.
During this period :
- I reinforce exchanges with the customer
- and I bring in someone to assist with testing.
When anomalies arise, I keep a close eye on what remains to be done, and inform the customer, who in turn communicates with the KYC provider.
On the day of the partner’s integration, we still have anomalies.
It’s the LeadDev’s turn to rack their brains to find solutions quickly.
For my part, I inform the customer every day, or even several times a day, of the progress of corrections.
This transparency allows us to be more responsive. The customer understands our needs and is totally open to discussion. He gives us all the information we need.
In the end, the switchover went smoothly.
Why do I think it’s important to communicate and be transparent?
I think customers need to know what they’re getting. Even if they don’t like the news.
This integrity enables my customer to :
- get organized by strengthening its User Support,
- put more resources into conflict resolution.
Without this, we would have struggled to find solutions… We would have provided an incomplete service, delivering a service that could have disappointed users.
Even when you start out with a few misgivings about a new project, you see that with good organization, constant communication and people you can rely on, you’re capable of bringing a mobile project to a successful conclusion.
We’re always proud to roll out a new version of an application, satisfied to have solved a bug, and, above all, enthusiastic about acquiring new skills.
We’re doing exciting things, and we need to help each other.
In a second article, I’ll look at :
- the difference between iOS and Android, as seen by a project manager,
- what I’ve learned from this experience
- and my views on the future of the profession.
To learn more about project management, subscribe to my newsletter.
