Building your dream app. A guide for the non-techie.
– Starting development can be daunting. In part I we reviewed the available avenues for creating content for mobile, in part II we’ll be discussing the processes and procedures for developing a mobile application.
Know your competitors! Start a document listing all similar products on the market identifying what they do, what they do well, what they fail at, and what they do not do. How will your product differentiate itself? If there are many competitors – identify the top five. If you don’t have any competitors you’re not looking hard enough. Even if it’s not a direct competitor there are always things you can use to draw comparisons. Note: you’re not looking to be “better” than the competition but rather to discover how you can differentiate yourself. In this phase you’re trying to force yourself to “think outside the box”, to discover your niche, and define what it is that will make your product special and unique.
Before you do anything, before finding developers, locating designers, or investors – you need to know exactly what it is your building. Your should have a strong and clear vision – both functionally and visually. You should be able to talk in detail and at length about it – as if it already existed. It’s not that your vision won’t change – it will change significantly in the early stages but it’s vital that you’re able to articulate it in order to bring others in and reap the full benefits of their knowledge and experience. The place to start this process is with good old fashioned pencil and paper (yes, pencil not pen). It will most likely seem silly at first and if your like me your drawing will be crude at best – not important. Do not waste time making things pretty rather focus on iteration and annotation. First off you want to draw all the screens you are aware of and label them with a title and/or brief description indicating what they do. You want to add to each screen the controls and interactions that you foresee being on it – simple shapes are all that’s needed. If you will have a pop over dialog redraw the screen a second time with the pop over displayed. As you add items annotate each with a simple description as to what it does. Draw in any screen transitions and provide simple descriptions for these as well. As an example I’ve included sketches for a simple example application I use to help demonstrate the app creation process here. Repeat this step as often as you can over a few weeks, show and discuss with family and friends. Do not obsess about someone stealing your idea or beating you to market. Far and away it’s the implementation rather than the idea that makes or breaks a project. A well thought out and executed project plan will help to reveal an idea that doesn’t hold water. Similarly even the best idea if not properly executed will fail miserably.
At this point you’ve performed your due diligence and you have a rock solid vision of what you want to build. You’re about to start spending money, I would strongly suggest spending a little more and engage a designer – preferably one with a portfolio of mobile applications. If you’re good with photoshop or some other design tool and have familiarity with the types of controls and interactions available for mobile you might be able to take on this task yourself. If you’re building a game or other graphic intensive application spend the money. Personally I use swordsoft. Low end but it gets the job done all for a whopping $6.99. At this stage, as a developer and project manager, I want to create a formalized storyboard that I can leverage to build a product backlog. Avoid going to high def at this point as the project will continue to evolve though the rate of change is slowing. As with the rough sketches I’ve attached a sample document here.
This is crucial and will make or break your project. I am a big proponent of agile software development and I recommend becoming familiar with agile and retaining a project manager that practices in an agile manner. A primary goal of project management is to break the project down into individual deliverable units identifying the beneficiary, the reasoning, and any dependencies. We use this to construct what is referred to in agile circles as the product backlog – essentially a road map of what needs to be completed to create the finished product. The product backlog is not fixed and can change over time. It is the project managers job to safe guard the backlog and guard against “scope creep” – only letting items that are essential onto it and prioritizing the release of items on it into the work stream. As stated, I’m a proponent of agile, but all things in moderation – I see far too many get fixated on the “proper” way to implement agile making what is supposed to be a flexible process overly rigid. To start reaping the benefits of agile only a handful of processes need be implemented.
Product Backlog – A prioritized features list, containing short descriptions of all functionality desired in the product. A typical backlog is comprised the following types of items:
- Technical work
- Knowledge acquisition
User Story – A short, simple description of a feature told from the perspective of the person or system that desires the capability. Typically each user story is used to create a single product backlog item. I however do not hold to the belief that all backlog items require a user story.
Sprint – A sprint is a single cycle of work that is expected to bring about a deliverable product feature to be reviewed and approved. A sprint is typically anywhere from one to four weeks.
Sprint Backlog – A list of tasks to be completed during the sprint. Product backlog items are selected by the team and the tasks necessary to complete are identified. Most teams estimate how many hours each task will take someone on the team to complete.
Sprint Planning Meeting – At the meeting, the product owner describes the highest priority backlog items/user story to the team. The team asks enough questions that they can turn a high-level user story from the product backlog into a list detailed tasks for the sprint backlog. There are two artifacts that result from a sprint planning meeting:
- A sprint goal
- A sprint backlog
A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner
Sprint Review Meeting – Each sprint is required to deliver a potentially shippable product increment. This means that at the end of each sprint, the team has produced a coded, tested and usable piece of software. At the end of each sprint the sprint review meeting is held, typically this takes the form of a demo of the new features
Daily Scrum – Each day of a sprint, at the same time of day, the team holds a meeting lasting no more than 15 minutes. At the meeting are present the team, the product owner, and the scrum master. At the meeting each team member answers three questions:
- What did you do yesterday?
- What will you do today?
- Are there any obstacles in your way?
Scrum Master – Part coach part protector of the team. The scrum master keeps the team on track acting as a gatekeeper for those that would directly access the team and pull them off task. Additionally the scrum master helps to make sure the team does not over commit – taking on more than they can achieve in a given sprint.
Product Owner – Typically a project’s key stakeholder. Part of the product owner responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is done primarily through the creation of the product backlog, a prioritized features list for the product. Although the agile PO prioritizes the product backlog during the sprint planning meeting, the team selects the amount of work they believe they can do during each sprint, and how many sprints will be required.
A final thought about the project manager… a project manager that can write code, especially within regard to one or more of the languages and/or frameworks being used is a huge advantage. This not to say the project manager should be spending time coding but rather that he or she will have a much better grasp as to what is possible, what types of hurdles might be encountered, possible workarounds, and some insight into the quality of code being produced.
The temptation is strong to just have your project manager acquire the development team for you. I absolutely recommended that the project manager be tapped for their knowledge in this area – he or she will no doubt be aware of various developers and firms. Strictly speaking however it is a potential conflict of interest. That being the case make sure the selection of development resources is a joint decision between you and the project manager – ask them for multiple recommendations and gather recommendations from others. Do give your project manager veto power on developers – you do not want your project saddled with conflict from the start. In regard to gauging technical prowess noted Android developer Donn Felker has some great advice on hiring developers in a two part blog entry that can be found here and here. Development is the most significant cost when creating an app and we’ll be discussing this further in part III.
Next up: How much – A hard look at costs