Part 3: The Growth Phase
If you’ve read through parts 1 and 2 of this blog series (covering the Foundation phase and the Build Phase), you’re no doubt eager to dive into the Growth Phase, for this is really where most of the activities that non-developers think of as “development” are taking place. Mystifying terms like “agile” and “scrum” come to mind, as do mental pictures of people with well-chewed fingernails and easily access cans of highly-caffeinated sodas. Well, we do use an agile approach and scrums, which we’ll get to in a moment, but not all of our developers’ nails are bitten down to the quick and not all the sodas we consume are designed to keep us up all night.
Sorry if we’ve burst your bubble.
Agile and scrums – the means to an end
Once we have completed the baseline build that we described in the Build Phase post, we enter the growth phase. Like many development houses, we use an agile approach, which is simply a process by which development is managed and coordinated across the team. Agile emphasizes individuals and interactions over processes and tools, working software over comprehensive documentation, collaboration with the customer rather than contract negotiations, and responding to change over following a rigid plan. You can read the Manifesto for Agile Software Development online if you’re interested.
“Scrums” are a manifestation of “agile.” A scrum involves developers performing various tasks in a highly coordinated manner during two-week bursts (or “sprints”). Scrum teams have frequent but brief meetings to discuss where they are, and at the end of each sprint the scrums have completed some element of the product. The framework that we chose during the Build Phase guides the sprints and the activities to be accomplished by each scrum team – and, if we have chosen the framework properly (which we do), the choice enables each team to achieve its goals with minimal complication.
At the same time, it’s valuable to point out that the agile/scrum approach to development assumes that changes will arise in the course of development. As we discuss the project progress with you, as we test software builds and user interfaces and user responses to the early builds, things invariably change. The agile/scrum approach assumes that this will happen, and the rapid sprint cycle means we don’t waste money building things that ultimately aren’t as valuable to your business.
Testing and refining your app
As noted above, the Growth Phase also involves a lot of testing and the assimilation of feedback. As soon as we can, we start testing the app to validate that it is doing what it is supposed to do for users. If we discover that it is not performing in the desired manner, we can determine what changes need to be made to achieve the desired experience.
This also helps us, help you understand where the inflection points exist within a long-term development cycle. At some point, you have a vision of the app in its mature, perfected state. But long before the app arrives at that state, it’s got to get into the hands of users and begin to make its promise known. We work with you to review the testing and feedback to determine when to release a broad, public version of the app to the marketplace. This won’t be the mature, perfect version, but neither will it be an “alpha” version that does little. This will be a true version 1.0 that will provide users with the essential features that they need, even if it does not yet provide all the features that you intend to make available. It may generate revenue – or it may be offered at no charge just to put a stake in the ground for you and the user community. As we continue to work on the features and functionality of the app, we’ll continue to test the app and gather feedback and move the app in the direction of that mature, perfect form that you envision.
All that said, there comes a point at which that version 1.0 is really ready to be released. Because of the infrastructure we’ve set up for you, because of the agile/scrum approach that we’ve taken to drive development, releasing the app is relatively simple. Instead of pushing the newly built app to a staging server for testing, we simply change one line of code and the build is pushed to a production server. We’ve worked with the Apple and Android stores for a long time, so we know the human interface and app submission guidelines. We know how to prepare an app for submission to these stores, so what could be a multi-week process for a less experienced developer is a quick and painless process for Distillery.
Not the end but the beginning
The Growth Phase does not really end with the release of your app. Think of it more as a kind of raising-the-child phase. Yes, you’ll have spent a lot of time and effort bringing this baby into the world, but once it’s finally here you’ll realize that you’re going to be nurturing this baby for quite a long time as it grows and gets bigger and engages the world in new and better ways. That, too, is where all the early work you’ve done with Distillery pays dividends. All those early discussions about business and marketing plans, all the discussions we’ve had internally about design frameworks and data hooks – you’re now set up to capture actionable information about how users are actually using your app, what is working the way you want it to work, and what you may want to refine in new and different ways.
So, no, the release of your app does not mark the end of the application development process. It’s just the beginning, and if you partner with a development firm that truly understands that, it’s the beginning of a long relationship that will bear fruit that gets only better year after year.
Part 3: A Guide to Application Development for Non-developers
