The answer is no, it isn’t simple developing an app or any software with the agile methodology. There are a bunch of things you need to do and it never ends. You have two options, go with the industry standard agile development cycle ( ) or try to outsource on your own (with no coding knowledge, I assume). On the latter choice, don’t forget you will need development over and over throughout the life of the app.
What type of code do you need?
There are more than just 1 coder needed. Not only is there native, cross-platform, web, and many other languages, you also need people that are more artists (but still do code) called User Experience (UX) developers. Then, there are the backend developers that write code in multiple languages (at the same time occasionally). Then you need to test and iterate. I have only mentioned a couple of the experts needed in order to compete with teams that have coders on staff.
Why do you need to continually update?
Google, Apple, your users, you, and everything in between are things your app relies on. Anyone of these, or combination of them, can cause your app to stop working and you will lose users fast. Just take Oculus as an example. They added a feature and it lost them millions of users ( ). Teams with coders (like Oculus) work in an agile development flow that allowed them to react very quickly and get it fixed, but they still lost many users which could kill a smaller, less equipped team reliant on outside development firms. There are many many stories out there about this type of thing. You can’t get away with “just building an app”, that is a myth.
Agile development takes what you need to develop (app or any software) and institutes a bunch of ceremonies, roles, and speed in your company. This is all done through “sprints” of development that a Product owner dictates through a backlog commitment list that is discussed with the whole team often (development input is REQUIRED), all while making the user the focus and revolving all new iterations around them. USER-CENTRIC
Informal Definitions You Will Run Across in Agile development
I will use our system to let you see how these things work. First, we get the scope under control by giving you feedback from our development, sales & agile teams. With code, there are a bunch of things that can be done and a bunch of ways to attack the issue. As Product Owner, it is your responsibility to say yes or no to features for any given iteration.
Backlog Commitment List
This is the lifeblood in your plans. What you do is take a bunch of user stories for features and pieces of the development you want. Once you get that list whittled down to a manageable slice, agile development lets you know how long it will take and how much it will cost to develop that iteration. From there you can either say “yes” or “no” in which case we move forward with the actual development or try to refine the scope further in order to bring cost/time of dev. down.
The goal is to have sprints that last 1–2 weeks by the time you get rolling (post MVP).
User stories are what you write in order to “put yourself into your user’s shoes”. These are used to help more deeply connect what you need developed with WHY you need it developed. This is important for your development team to know while they are helping you refine the scope and consider what pieces will be on the next sprint.
Users are your #1 focus (followed closely by how you will make money from it). If you have users you will find a way to monetize them, most likely. However, it is smart to have a plan to make your users so happy and dependent on your app that they would (and will) pay you for the experience.
Therefore, you must have great user stories that are exactly what they want. If you swing and miss, you go back to the drawing board and fix the problem. Don’t be afraid to fail, that happens all the time with these things, be afraid to NOT LEARN from those failures and this all starts with how good you are at putting yourself into their shoes (in my opinion).
These are quick agile development rounds. Ultimately, the goal is 1–2 weeks, as stated above. Before that, though, your MVP will need built ( ) and that will take some time. With development experts on hand, it will make it much easier to know how long that will take and through detailed planning, your budget can definitely be kept in mind. Keep in mind, coders in America, Canada, and the UK are ~$100-$200 per hour! It can get pricey quickly.
Keeping iterations in the future (after MVP) small will help greatly reduce the amount of engineering spend you make on any given piece.
I recently that explains these in more depth and very well.
Are there alternatives to agile development?
Yes, waterfall development is what you would use if you outsource your development. That is when you tell the team what you need, get it developed, deploy to users, find another team to fix the problems that have come up and repeat. This process is necessarily longer and why outsourced apps are behind the times and most likely can’t even spend enough to keep pace.
Let’s think about it. To find a team takes a month or so, then the team develops what you want over the following couple months, then you deploy it to users (MVP). Great! Now, your users start complaining or wanting new better features to keep them in your app, engaged, more often and for longer periods of time. You NEED this, so you find another firm to develop it (or go to the same). They will charge you for a completely new project and your development (again) will take a month or two do get done (assuming you can scope things properly as a non-coder, which is VERY difficult).
Bottom line, agile is better and that is why teams with coders always will beat teams that outsource. You can have one too for $495/m with our membership.
As you can tell, it is a never ending story and the cost can get away from you without knowledge of code and how to develop an app. I haven’t even gotten into the different releases you will need to do (your MVP goes to a very small tester group of family and friends ideally, for example). Testing is also vital because there is no such thing as a completely bug-free app (on every device). Even the best freeze, crash, or otherwise ooze user repellent. I could go on, but I’ll stop for now.
If you are friends with a coder, talk to them to help you vett people that will work on your project (you need a team and unless you would marry the person -figuratively-, don’t get a co-founder, equity is too important!
Come take our 5-day trial and we can help you refine your scope and show you how the system would work for you.