Reacting Agile

Apple's continuous release cycles have become part of the consumer consciousness. Since the 1920's, and the auto industry implementation of planned obsolescence, the product cycle has been revolving ever faster. These days driven by fanaticism and features rather than deliberate sabotage of older versions the consumer phone market continues to release new models of hardware and software every few months. While this ongoing cycle is a proven part of Apple's success it is increasingly forcing other organisations to be more agile in their approach to application management.

Now that more companies are relying on mobile applications to interact with their staff and customers they have no choice but to jump onto the continuous upgrade bandwagon. At very least they need to ensure that their application will continue to work, and for many sectors it’s important to leverage new features and functions as they evolve. Having worked for many different organisations I have seen large companies that are nimble and small companies that are over governed. Generally speaking however the larger the company the more likely there will be a lack of agility. After all a large company is beholden to shareholders, it has invested in process maturity, and does not rely on cowboy style decision making.

How can you tell if there is a problem? For mobile application development, if you cannot keep up with Apple (also a very large organisation) then something is wrong. Because if your well-meaning process ensures that it will take you longer than 6 months to release a new application then by the time you release it will be out of date again.

When thinking about mobile applications in isolation it’s easy to think that they are already being handled in an agile way. However B2E, B2B, and complex B2C mobile applications have integration to back-end systems. This integration layer and god forbid if any changes are required to back-end systems, is where the agility fades. Additionally for many large organisations it’s not necessarily the systems lacking agility but often the governance processes that are stifling. Some of the reasons large organisations are not agile include:

• Empowerment of decision makers 
• Compartmentalising 
• Lost IP 
• Lack of focus on innovation and R&D 
• Focus on risk 
• Focus on architectural purity 
• ROI timescale

For example if your ROI is calculated over a 5 year period but your mobile application is only relevant for 12 months then there is potentially a mismatch. How about some controversial ideas:

• Don't build the best solution; build the quickest to market solution!
• Don't build a fully scalable architecture build a throw away architecture!
• Don't build a scalable solution build a point solution!
• Don't build a big team and management structure build small cell like teams

Realistically many organisations are now moving towards a framework enabling continuous development cycles, and/or running multiple small projects in parallel. An initial investment in a repeatable process and appropriate architecture lays the foundation for more agility and an increased speed to market. When it comes to the mobile application lifecycle consider what is really important to these solutions:

• Meets user expectations? 
• Stability? 
• Supportability? 
• Appropriately scalable? 
• Lasts a year or 2? 

The continuous release cycles from consumer mobile companies like Samsung and Apple is driving innovation and demand for the latest in hardware and software. In response the term “agility” is often thrown around however it means many things to many people. It's now quite common to use an agile methodology when creating mobile applications and websites. The development of user interface driven applications achieves fantastic results when a team is able to iterate and/or leverage prototyping tools. The ability to release the latest mobile applications is often hampered by the lack of agility across an entire organisation.

There are many inspirational stories of great results where a relatively minor investment has enabled small innovative teams to succeed or fail. The trick for large companies is to leverage the benefits of this model while balancing risk and reward.