This is part four in our series on the process of how we work to develop the best mobile apps in New England. Check out Part One – Discovery, Part Two – Design, and Part Three – Pre-Development, because you’ll want to catch up before this season finale.
Actually, instead of a television metaphor, we should really be using music as our analogy, because the Development phase is all about getting your team in the right rhythm all the way through to your app’s launch.
How we define the “Development” phase
The Development phase is not just about finishing the app. It’s also about putting together all the assets and resources that you’ll need to push the app live so it has the best chance of being noticed and downloaded by your users. It’s about getting all aspects of your organization in the right mindset to go live – from marketing and promotion to testing and customer support – so that you are in position to support and learn from your customers.
And to do that it’s really about getting your team in the right rhythm of writing code, reviewing code, and pushing and testing releases. Because once you’re live in the app store, you’ll want that steady and familiar rhythm under your belt so you don’t stumble in front of paying customers. So, even while we are developing the app, these are the practice cycles for the entire team (from organization to marketing to developers) that form the muscle memory to be truly successful with the app, once live.
During this phase, we will work with you to establish the following things:
- An operational system of iteration for the team;
- A working mobile app;
- The infrastructure to learn from your users; and
- A plan to enhance your app going forward.
Let’s dig into each of these bullet points.
Developing the operational system for the team
A successful mobile app is the product of consistent production of working builds that steadily implement requirements. And that simply boils down to getting the right team on the same page, and in the same rhythm.
We work with clients with internal dev teams big and small to make clear the division of responsibility, and we are happy to plug into the team the client wants to bring to the table. Is it your entire dev team minus mobile expertise? Or are we taking the bulk of the responsibility and mostly working with one or two point people? Will the client provide business stakeholders to test the app? Who will be the primary project manager? Knowing who and which people are responsible for what will make development go smoother, not to mention faster, for the dev phase through to release.
So who needs to be on the team? As an example, a typical project team might consist of:
- 3 Developers: iOS, Android, and Server/Architect. This group writes code, reviews each others’ code, maintains the development and testing infrastructure, and publishes builds.
- Product Owner. This person owns the requirements from the user’s point of view and is focused on making sure that the most up-to-date requirements are implemented.
- Scrum Master. This person runs the project day-to-day, orchestrating the process and being the ultimate decider of what the team works on each sprint. (Note: could be the Product Owner on smaller projects.)
- Tester. The people responsible for the testing approach and execution once a release is available.
- Designer. This person is on hand to make sure the implementation matches the agreed-upon design and should be doing UX testing to make sure the app flows smoothly and is easy to use, as designed.
Then as we get ever closer to launch, the team grows a bit larger:
- Stakeholders. Anyone with a stake in the mobile app. Usually, this means the person(s) representing the business unites for an enterprise-level company or the CxOs of a small startup.
- Support. The team tracking customer issues in the Customer Relationship Management system (CRM).
- IT. The person(s) most responsible for the company’s existing technology infrastructure. They should control the keys to any company accounts, for example, Google or Apple app accounts.
- Legal. Especially for larger organizations, a member of the legal team is necessary to have to address compliance issues. For example, they are crucial for the deployment of apps in the health and wellness space.
- Marketing. If they haven’t been there from the beginning of the entire project, they absolutely need to be here now. Marketing should be aggressively preparing for launch and lining up customers.
Once this superteam is in place, what is the operating system to get them all in the same rhythm?
Left to our devices, we prefer to follow (and always recommend) an Agile Development Process. We go into the details here, illustrating how our Agile process works much like the New England Patriots’ way. In our history, it’s been a tried and true method. And, while we’re happy to adapt to the workflow the client is used to, there are some tenants we try to replicate each time:
- Weekly sprints with frequent builds. There’s no better way for our clients to measure exactly where we are and to see the quality in near real-time. Weekly builds also provide immediate feedback (ie. is the design working for users?)
- Daily 15 minute standups. We take time every day to listen to each developer talk about what they are working on, what’s done, and if there are any issues or blockers. Nothing works better to stay on the same page as a team than this face-to-face daily debrief.
- Weekly sprint planning meeting. This is time set aside to figure out what features are next and, most importantly, estimate the amount of time the next steps will take. Since Agile methodology attempts to release a build weekly, we need to frequently plan what’s in the next build – meaning fully complete features that are ready for test. This way, we’ll have the most accurate projections possible which helps us keep on target for the release date.
- Documentation. We make sure that all requirements are documented via richly detailed Stories, which include details of test and acceptance criteria. Detailed Stories make sure there is a rhyme and a reason for every developmental decision, and that requirements can easily be picked up by developers and built with clarity and accuracy. Let’s get it right the first time!
These tenants help us to stay Agile; meaning we stay transparent, flexible, measurable, and adaptable as the project progresses. And, as one can see from these bullet points, we also work hard to foster a team culture of communication.
Developing the mobile app
In many ways, actually creating the mobile app and supporting back end services is the most straightforward part of the Development phase. If the two previous phases were completed to the utmost degree (including that Pre-Development checklist), and the team is on the same page with the sprint cycle and action items, then the MVP (Minimum Viable Product) version of the app will come together without much fuss.
Every project is different, but during this development process there are a few aspects that we have found to be essential to success:
- A methodology for doing estimates. In order to figure out what tasks can be completed during each sprint, we as a team conduct estimations for each task. Then we later assess how accurate those estimates were, so subsequent estimations will be more accurate. If you really want to get into the weeds, we are partial to the Fibonacci scale technique for estimates.
- Reviewing code at each check in. Changes made to the code repository must always be reviewed for standards and quality, by hand. A backlog of code to be reviewed is a sure sign of concern.
- QA testing each build point. As each build is pushed out, the QA team tests completed features against requirements and acceptance criteria, reporting back any issues they come across. Those issues must be managed, with a workflow that addresses issues while managing the backlog of new requirements to build.
- Again, it’s the rhythm of the team that will lead to a successful product. Assembling the code is one thing, but the process of a great team working in the same direction is what really wins the day. And at this point, a solid MVP of the mobile app is ready for launch.
But it’s not over just yet.
Learning from your users, as a process
We would never hand over a functioning app and say goodbye. In many ways, the development process is just beginning with the launch of the app. That’s why our many years in the industry and experience launching apps in every vertical is another huge advantage we bring to the table. We’re there with you through launch, through marketing, and through the discovery of what your users like and don’t like. We’re there as you continue to refine your roadmap based on your stragegy and what the users are saying.
Your first batch of users will be the best QA for your new app. But your team will need a way to collect user feedback and track customer issues, in order to create the next version of the app that addresses all these concerns. Working with your team, we’ll help you implement a workflow to manage these changes.
Additional we’ll now dive with you into the data – what are users clicking on? Where do they appear to get stuck? Your analytics are critical for understanding user behavior and this is where we’ll work with you to make sense of the broad combination of detailed user data, specific bugs and issues, and your roadmap, to figure out what to do next. We’ll work with you to segment users so you can truly understand the problem
Many times, the rhythm of the sprint won’t change much as we continue to work. We’ll work with you to make sure the build-test-release cycle is smooth and on schedule.
Versions 1.2, 2.0, and beyond
It’s not over after version 1.0 is released. Enhancing your mobile app with each new iteration should happen for the lifetime of the app. In fact, that’s precisely what gives your app a long life in the first place. To that end, our job is to be your partners through each iteration. For some companies, this can taper off after a few releases. For others, we’ve been the owners of each release for years and years. It all depends on your mobile support needs.
As more data rolls in, the breadth of that data will most likely widen and also get more specific. For example, releasing a new feature can logarithmically increase the amount of data your app collects on user behavior. We’ll be on hand to help you manage your growing data, as well as interpret the data to inform what to build next.
And in this way, the rhythm we established at the start of the Development Phase simply continues on; we might hold a champagne toast or cut a cake to celebrate the release of the MVP, but we know that the work isn’t over as long as you are keen on continuing the partnership to release 1.2, 2.0, and beyond.
In that way, it’s routine. But also terribly exciting. After all, the best apps aren’t released on launch day; they’re tempered through continued iteration from a team of experts invested in its success.
And that’s our story. We’d love to be part of yours. Share your business with us and we’ll bring our app A-game to the table. Connect with us here: https://www.rocketfarmstudios.com/contact-us/