1

We have a startup and it is our first experience. We want to create a mobile application and its website implementation.

We have 3 main parts:

  1. Mobile application
  2. Website application
  3. A server that can work with both of them

We are 4 people and one extra man can be added if needed. 2 people will work on the mobile app and 2 will work on the website, the server and graphic designs.

My question is: How can I manage this team to work parallel together? I mean how to control work progress? How long should the deadlines be?

Let's consider we want to create a UI for Android and I think it takes 5 days. Can I say "Jack, go to your home and write this part of the project and I'll meet you next week with Android UI?"? Or must I break it up into 5 mini-projects (first day: design layers, second day: write menus, third day: write tabs, etc.) and say "Come here everyday and we can check the work progress together."?

Sorry if they are stupid questions, but maybe you had them in your first project!

|improve this question
  • 1
    If you only have 4 people, there’s little sense in having two teams. Implement each feature for both platforms at once in a single vertical slice. It will save on a bunch of back and forth & rework because the API never took the needs of mobile app into consideration. – RubberDuck May 5 '18 at 2:27
  • Swarm together; don't work in parallel. That way lies madness, pain, and endless suffering! – Todd A. Jacobs♦ May 6 '18 at 7:02
  • To expandon Todd's comment. Consider that having 50% of all features 100% complete is worth around 50%. Having 100% of all features 99% complete is worth exactly nothing. – Kempeth May 8 '18 at 12:13
  • Try to find an extra man that knows how to run a startup/project and can give you the valuable advice you need to make the most of your time. That'll be more valuable than learning every lesson the hard way. – Erik May 9 '18 at 15:05
2

Oh the memories, first project. Due to your small group size and the high uncertainty of your project, I'd chose an agile approach, e.g. Scrum.

So form a cross-functional team that is covering every aspect of development. And decide what rules are irrevocable when the shit hits the fan (and it is going to hit it real hard, trust me). You need a solid rule set to guide you as a team through rough weather.

Reflect about the product vision. What are you going to build? What are the core functionalities? What has the greatest value?

Then cast user stories out of these thoughts ("As a customer I want to see the sum of my order at a glance so I'm not surprised when checking out.") and fill your backlog with them.
Order your product backlog so that you can produce the highest value.
Think in increments.

Start producing value as soon as possible. And be a team. Communicate, communicate, communicate. Try pair-programming if possible. I hate stale quotes, but the whole is more than the sum of its parts.

And for the big picture always have the turned iron triangle in mind. Agile PM is often misunderstood as "It doesn't matter how long it takes or how much it is going to cost; we are agile." Agile PM is about producing the highest possible customer value within a given time and a fixed cost baseline.

|improve this answer
  • 1
    Thank you very much Stephan! I will read all your referenced links. If I had 15 reputations I could give you +1. – user3486308 May 6 '18 at 6:26
  • No worries, glad I could help. – Stephan Weinhold May 7 '18 at 13:17

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.