Agile mobile development
For some agile has become a buzzword and excuse for running over budgets, not writing proper specification and lack of planning of customer testing. Our experience is that not only can agile principles be applied successfully in cross platform mobile development, they can be combined with budget discipline, a clear scope and time plan.
When our team was presenting to a customer in London a couple of weeks ago, the customer started laughing when we mentioned that our core methodology is agile development. Apparently it was the 4th meeting during the day someone mentioned agile without explaining what they meant. Our next article will be on the subject of how the cloud is replacing food which can be equally confusing when taken out of context but that’s another story.
In mobile development agility is especially important as it’s difficult to anticipate how a service will work across various mobile devices until you’ve tried it out. So here’s the short version of how we do mobile agile development with a fixed budget, timeline and clear scope while still getting as many advantages from agile and scrum as possible.
The concept of a 1-page scope overview is great but in reality most software projects require more details than this. Spend a week defining the use cases, creating wireframes and mockups, breaking down and clustering the features in phases and establishing the business rules. This is the starting point agreed and signed off as the scope of the project.
The timeline is fixed with milestones for external dependencies, iterative deliverables and the final milestones including feature complete version, release candidate and launch candidate. Changes to the scope and failure to meet milestones may lead to either
a) a change which has no impact on time or resources which is simply accepted as a change
b) a change replacing an existing part of the scope and thereby substituting the scope for the project
c) a reduction in scope if an external dependency is not met, e.g. an external API not ready in time
d) a change to the timeline if both parties agree that the change has higher priority than the timeline of the project
The budget is fixed based on the estimated resources, lead time required to deliver the project and assumptions in terms of external and internal dependencies.
There are 3 activities that may change the budget:
a) Changes to the project which adds additional resource requirements, e.g. adding additional functionality or changing an existing function late into the project
b) External dependencies not meet by the client or a third party, e.g. late deliverables of assets, issues with APIs and changes in business rules
c) Delays by the client including feedback not given on time, replanning of launch dates and changes of project team members on the client side
In addition to this delays caused by internal assumptions, e.g. resources available, complexity of a delivery, etc may cause changes to the budget but these do generally not impact the external budget.
So if scope, timeline and budget is fixed what is agile?
The development methodology is based on sprints delivered in iteration with feedback from the client after each iteration and daily stand-ups to review progress. Each sprint has a defined scope of features/use cases. The client can change any deliverable in the scope of the upcoming iteration as long as it doesn’t impact the resources available for the future sprints or the overall margins of the project. Changes can include user interface adjustments, business rules functionality, a new feature that replaces a feature defined as part of the scope, a change in a backend API, copy changes and much more.
And this is how we combine agile with predictable scope, timelines and budget. It’s as simple as that…