This is part 4 of the Building successful MVP with offshore team.
Now you have a specification of your application and developers. It’s time to put on the next hat – project manager. That’s the key part to your success – you have to manage the development process.
A quick note before we move on. You should own the code. Never let developer show you the pieces of the product without giving you the code. Create an account on github and make sure that developers work with a repository there. You SHOULD OWN your code.
Manage and prioritize the work. Don’t create a list of features and let the developers decide what to work on. Tell them what should be done in what order. Work on the unique features of your application first. Do not start with Sign In, Sign Up and so on – features that are common for most applications. Build the core of your application first. This way you can address the most challenging and unknown parts earlier in the process.
Tell developers to show you how UI will like ASAP. There is no need to build the whole backend with API and database to show the actual UI. Developers can always use fake data before building the backend.
- inbox (all new items come here before being prioritized)
- V1 or V2 or MVP or whatever version you plan to release (try to schedule only the version that you are working right now)
- Next Up – the next items that developers should work on (no more than 2-3 items)
- In Progress – this is what developer is working on right now (there should be no more than 2 items here, e.g. a feature and some urgent bug to fix)
- Testing – items are under QA’s testing
- Done – items that are done & tested
- Later – everything that you plan to work on after the current release
Most of the work items (bug, feature) move this way:
Later -> V1 -> Next Up -> In Progress -> Testing -> Done
Don’t overcomplicate it and create too many boards for any possible scenario and development steps. If in doubt – put items in the Later board.
Lear how to triage bugs. Not all bugs should be fixed, even critical ones. Consider the probability of the bug. It’s like insurance – yes if some bad thing happens, it can be costly, but the probability of it is so low and insurance is so high that it doesn’t make sense to have it.
Ask a developer to commit the code daily, especially at the beginning. This will give you a sense of the progress. Review the new code daily. No, you don’t have to learn to program nor to understand the code. But if one commit has a few lines added (sometimes these can be blank lines) and then removed in the next commit, it’s not a good sign. Look, it’s like writing a book – if an author writes only 100 words per day, it’s not good. GitHub will let you compare the changes. You can also track the progress with GitHub activity monitoring tools.
Be proactive. Get everything ready for the next item the developer will work on ahead of the time. Prepare UI design, UX flow, business and data validation rules, and so on.
All this work should not take you too much time. Depending on the number of developers it can be no more than 2 hours a day. Yes, it looks like a lot of work, but this is the road to a happy and frustration free launching.