As a rule, software projects cannot be planned down to the smallest detail and are subject to constant change. This is not different in developing mobile applications. To react to these challenges, agile approaches like Scrum are the solution for many teams – but does this make sense in every case?
Let's consider a standard scenario.
The basic conditions
We assume that following initial position is considered typical for mobile projects in a lot of cases: a relatively small team consisting of two or three developers, with the core work being done by one Android and one iOS expert. Cross-cutting topics such as backend connections, system architecture and design are conceptualized and implemented with the support of another developer.
The project has a relatively short duration of three to four months. So as soon as the developers are installed and have found their feet, the project is almost over.
Since the minimum size for a Scrum team is not reached regularly and hardly any sprints are possible because of the project’s short duration, Scrum does not seem to be the right method for this type of project at first glance. One might be tempted to think that the best way to manage such small projects is the waterfall model.
But this conclusion is wrong.
Use scrum wisely
I rely on Scrum, or on the use of its individual artefacts even in smaller projects and that helps me, the team and the client to complete projects successfully.
Even if developers independently implement on their respective platform, they still have to establish intensive technical coordination. Since development for the two platforms runs in parallel and have equal prioritization, a common backlog can be used just as well. At planning poker the developer can estimate the implementation effort for their platform. And since the complexity of technical implementation of tasks for each platform is usually the same, potential misunderstandings can still be brought to light. The sprint length is selected to be as short as possible, and meetings are cut accordingly. The sprint results can directly be provided to the client as increments via beta-testing platforms.
I use an adaptation of the Scrum-from-textbook artefacts for projects with technically complex framework conditions. In this case, a backlog per platform is maintained, in which prioritization is adapted so that the implementation of, for example, a peripheral connection with client-specific protocols is developed initially on one platform. This experience is used to synergize development for other platforms.
It is no disadvantage that the client‘s vision of the final result is not defined until the project is complete and that change requests always have to be discussed and implemented. The team is agile and can respond to change requests even if only individual Scrum elements are used. In this way, the client receives exactly the app they want, and not the one we would have developed on the basis of rough initial ideas.
Conclusion
So, Scrum and Mobile – can this go well? Why yes, of course! But it is important to not simply use the model because it is there to be used. Look carefully: are the appropriate framework conditions valid for the entire Scrum process? Or would it be better to use only certain artefacts? Be critical and you'll find that nothing stands in the way of a successful mobile project.
Want to learn more about Scrum? Check out the "Scrum Compact" section on our website.
Comments