Mobile development sprints
It is not unusual to have a long wish list of functionality for your new app. A brief for a new project tends to come across my desk littered with ideas. Some great, some not so, but the brief always states that all of the functionality needs to be released in one version of the product. My first task, when writing the proposal for the project, is to break the initial wish list down into a list of prioritised features and functionality.
These features are then grouped into packages of work that we call ‘development sprints’. The concept is borrowed from the Agile project management and delivery methodology which you may be familiar with. The general idea is to always have a functioning piece of software to pass on to the users at the end of each development sprint.
A different approach?
If, like many project owners, you are starting a new mobile project having come from a history of initiating web projects this may come as something of a surprise. Most websites are little more than collections of documents often with only limited functionality. Even web applications can, more often than not, become an exercise in bolting together and augmenting some pre existing modules of functionality. The web has reached a level of maturity such that most projects no longer require brand new development from the ground up. Most clients want essentially the same thing wrapped up in a different box. I may be deliberately over simplifying the situation to make the point. *smile*
This has led to web projects being viewed as disposable items. As a result, very rarely does a website evolve with an organisation. Instead, every 3 years or so, the current website is thrown away and a new system and design is put in its place. This culture has led to a squeezing of budgets and timelines so that phases of a project such as testing and review can be be hit, or even removed all together. After all, in most cases if there is a problem with a web based solution, or something needs changing, it can be updated or fixed almost instantly.
Such a view of the world would terrify most people who commission and run software projects. A software project is a complex beast. In many cases more time is spent planning, testing, and reviewing than is actually spent building. And when this isn’t the case the results are often obvious for all to see.
A truly Agile approach fits perfectly into the world of software projects because it gives planning, testing and review processes the place of honour which they deserve. The whole project can be arranged such that the software, at whatever stage, is testable. Testing and review in this way means that problems are spotted and fixed before they can have knock-on effects later down the line. It also offers sensible opportunities to change the scope of the project, for whatever reason, without wasting lots of effort.
A mobile app, while possibly far less complex and far smaller than traditional software, is perfectly suited to this approach of development. There are a number of advantages in taking this approach over simply setting a timeline for all of the desired functionality and ploughing on through to the end.
Apps should do a few things and do them really well
Apps, like traditional software, enable the user to get something done. They are action or task based. If your prospective app does not enable the user to complete a task then you should be considering the validity of your project. The best apps do one or two things and they do them really well. By forcing a review of your desired functionality you are able to focus on what the core features of your app are. These core features should be the focus and will be the things that hook your users and drive the success of the app.
More frequent / rapid user feedback
Once your app is released with its core feature set your users can drive the apps evolution and development. Experience has taught us that, with the best intentions, the long initial wish list is often little more than the best guess or the personal preferences of the individuals initiating the project. Your app will be used by real users in ways that you hadn’t ever imagined. Real users will also have their own list of things that they want your app to enable them to do.
Priorities will change
This user interaction, as well as the usual political winds that blow through any organisation, will change the priorities for your app. It maybe that a great new idea emerges once your app is out in the wild. It maybe that the platform vender provides exciting new opportunities via a software update. The mobile marketplace moves so quickly that you do not want to get tied into a long development timeline. Short development cycles and frequent releases are much more important and effective in this environment.
Test / fix / release delays
It is worth noting that, unlike web projects, you have to get apps right first time. Especially when dealing with external review / release procedures like that which are used by Apple in their role as guardians of their own app store. If an issue makes it into a release you cannot fix it quickly. Each fix is a new release, which has to be approved by Apple. This approval process can take 2 – 4 weeks which means that your app may be misbehaving and there is nothing that you can do about it.
Shorter development cycles with a focus on planning and testing will enabled you to offset this risk. This approach is a must.
Good for the team
Something which should not be overlooked is also the morale of your team. Frequent releases show progress and offer bite sized chunks of success to those who are involved in the project. It is very easy for long drawn out projects to become bogged down and stall leading to moral sapping delays. Frequent releases keep your team engaged and creativity high.
Shorter development cycles have many advantages. In the short term there can be an extra expense due to the extra planning, testing, and review time however in the long term your project will have less wasted effort, less issues, greater flexibility and more creativity leading to a much more effective and economical solution.
Subscribe to our newsletter for free advice delivered to your inbox on a fortnightly basis.
Agile perspectives: the planning meeting
As a scrum master, I am usually asked all kind of questions about agile as a methodology. Some people explain to me why agile doesn’t really exist and […]