I and three other people got some money to build an educational mobile app (sociology for high school students). The software requirements are decided largely by ourselves. The team will consist of the following people: two experts, one whose role is to create the teaching material (questions, text, etc) and one who will provide expert advice on pedagogical principles and teaching sociology; a programmer (me); and a person who will design the UX and UI.

I have previously worked on such projects in academia without a proper framework for software development, but this time I would like to do it right from the beginning and follow the best practices. Therefore I would like to ask: What kind of a development process would fit for this type of work and how do we go about choosing one? I am not sure how using scrum would work here; it's a small team and the people involved have varying commitment levels (we don't have a tight deadline). Is there any other development process type that would work here?

  • Is the app stand alone or does it communicate with servers in any way?
    – david25272
    Jan 30, 2017 at 23:19

5 Answers 5


I don't believe any standard process fits this case, as you clearly have people of different expertise areas. The commitment levels aren't what prevents Scrum from working; the varying expertise areas are what prevent it from working. Scrum assumes that people are homogeneous, which isn't clearly true in your case.

Because the expertise areas are different, I would simply use a project management tool where the work is split into small well-defined chunks, and each chunk is assigned to the person that can best do that particular chunk. You also need to have good estimates for the duration of these chunks.

You also need to have regular meetings where each person tells what he has done since the last meeting and what he plans to do in the near future. If you expect that the work one person is doing can before finished delay the work of other persons, you could very well have short stand-up meetings each day. However, if you don't believe such dependencies occur often, the meeting could be as rare as a weekly meeting.

  • 1
    This is a good answer, sometimes we get hung up on "using" agile or XP or scrum or SEMAT or other methods that we forget that simple project management techniques and processes already exist that we can use (I highly recommend a quick flip through the PMBOK)
    – user7433
    Feb 1, 2017 at 14:41

If I had 2 domain experts I would go with Domain Driver Development. You can use for instance Whirpool process

to clarify different aspects of the domain and together with UX designer transform it into mobile app functionalities. In that way you (and the team) would gradually understand the domain deeper and create app with the possibly highest business value. You will then quickly reach prototype which can verify your assumptions and you will get valuable feedback. This approach (and much more) is described in great book The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses by Eric Ries. You can then use any methodology like Scrum to organize your work and make your development process itself better and better.


I doubt that a process perfectly fitting your situation already exists. I'd rather look into various processes, analyze them, and pick useful aspects from them. Keep the roles of the people and their interactions in mind.

E.g. I'd likely include the "retrospective" from Scrum, i.e. have regular meetings where you discuss what went well or bad, and how to improve (and at the next meeting, find out if the steps to improvement worked or not).

XP (extreme programming) is a collection of methods which can be used in (typically) agile environments.


Keep it simple and just use basic project management techniques:

  • make an action plan:
    • create a list of tasks with the deliverables for each task, for example you could start with the user interface and expand from there or if there's learning modules start from there
    • list all the dependencies for each task
  • estimate how complex each task is
  • estimate how much time the tasks will take (this can be a ballpark figure)
  • have a status meeting every week or two weeks to make sure things are going smoothly; remember that you are accountable to make sure this goes smoothly (you are because you're caring enough to ask on this forum!)
  • make a list of stakeholders and their commitment levels; that will also help you figure out how often you have to report in on the status of the project and who else you can turn to for advice

In terms of the coding/user interface, what you will really want to do is start with a prototype that goes end-to-end so you can test the whole of the major workflow in your app. It's not fun to implement screen by screen and then find out something is missing. This is similar to Agile where every week you have something that runs and can be shown to sales/marketing/clients/executives/other stakeholders.

Focus on the must-have tasks and make sure things are moving along with whatever information the experts need to provide and that's basically your process, typical project management rather than worrying about SCRUM or Agile.


Scrum doesn't really require homogenous participants. You state tasks with deliverables, put two weeks worth into your scrum, and off you go. The only difference is that where you could put 80 points into a two weekly scrum with four programmers, you can only put 20 programming points, 20 UI design points, 20 teaching material points, and 20 whatever the last guy is doing points.

I'd insist on reviews - a task is done when all the related work is done, tested, reviewed, and accepted. So if "expert advice on pedagogical principles and teaching sociology" turns out to be something that nobody can make sense of, or that isn't useful for the one who creates all the teaching materials, for example, then it won't pass the review.

I'd say that scrum will be quite useful when people don't want to pull their weight, because after two weeks it becomes painfully obvious that they haven't done so. They can say "I'll do this next week" and then they better get going, or at the end of the second scrum it becomes really obvious and you may have to have a talk to someone about whether they want to be part of this team or not.

Imagine at the end of the project you say "A did 43% of all the work, B did 41%, C did 13% and D did 3%" - and you have the documentation to prove it.

PS. Someone disagreed with this being scrum. It is. It is absolutely fine to have specialisation in your scrum team. I have a graphics designer in my team, and nobody else can do that person's job. So you have the choice of including them in the scrum, or have your team depend on outside influences outside your control. Ten times better to have them as part of your team.

Someone also disagreed with people being responsible for what they are doing. That's not normally part of scrum, but if a team member doesn't pull their weight, they will eventually be ex-team members and in a company, they will eventually be ex-employees.

  • 2
    What you're describing isn't Scrum. A cross-functional team is the core of Scrum. There's also no such thing as "programming points" or "UI design points" - all top level tasks or stories share the same points. It's also inherently not Scrum to consider individuals over the team performance.
    – Thomas Owens
    Jan 31, 2017 at 1:09
  • It seems you are valuing the process more than the people. That's not scrum either.
    – gnasher729
    Jan 31, 2017 at 11:11
  • 3
    The official definitions of Scrum are captured in the Scrum Guides. If you deviate from this, you aren't doing Scrum. That doesn't mean that your process is wrong or isn't good, but calling something what it isn't doesn't help in communication. I didn't down vote at first, but this answer isn't useful since it fails to effectively communicate by misusing terminology. It may sound pedantic, but effective communication is very important to me. If you change the wording to make it clear that what you describe isn't Scrum, please ping me so I can revert my down vote.
    – Thomas Owens
    Jan 31, 2017 at 11:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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