The eternal quest for perfection: The engineer’s fear of agility in mobile apps
Developing mobile solutions bears some special risks in industries with a strong engineering focus. Just like IT professionals, engineers are a special breed. It might seem at first glance that both roles have similar educational backgrounds and can understand each other well, but there’s a potential culture clash when it comes to agility in mobile apps. It might easily be underestimated, and it needs to be addressed and monitored along the full project lifecycle.
The agile advantage
Fifteen years after its introduction, agile has been established as the standard methodology. Agile takes an iterative approach to project management and focuses on creating minimum viable products (MVPs) that will continue to be improved upon. In a VersionOne study of 3,880 software development professionals, 95 percent of respondents said their organizations practice agile. Forty-three percent noted they work in organizations in which the majority of teams use agile methodology — a significant increase from the 31 percent figure from the 2009 study.
Modern software development is based on iterative improvement and agility — particularly agility in mobile apps. It’s a core paradigm in the IT industry to start small, with a minimum viable product, and add more functions in subsequent releases to let the solution’s capability grow over time. This ensures stability and controllable software development cycles.
The agile approach has proven to be successful in the IT industry. Vitality Chicago reports that agile projects are more successful than waterfall projects — projects that follow a sequential order of events, so as one stage is completed, developers can move onto the next. For large projects, only 23 percent of agile projects fail, compared to a 42 percent failure rate for waterfall projects. Medium agile projects only reportedly fail 11 percent of the time, compared to 25 percent of the time for medium waterfall projects. Small agile projects also have an edge with a four percent failure rate compared to 11 percent.
That being said, agile is not a standard approach in many other industries. If a new car model goes into production, it needs to be complete. Like most other products, a car is released to the client only once and its first version must be perfect. When it’s handed over, its functions and capabilities need to be complete. Every missing mandatory function and every defect in the car is extremely difficult and cost-intensive to fix after it has been manufactured. Most products are designed, built and produced with the goal of being perfect and complete in the first release to the customer. This approach has proven to be successful for most engineers.
Agility in mobile apps
Software — particularly for mobile apps — is different from most of these other products. Regular upgrades and extensions are part of the core DNA. Apps can be constantly improved for all users. There’s no need to have them perfect and complete in the first release. In contrast, this is even counterproductive. It increases the complexity of a first release and bears the risk of adding more and more functions the users might expect from the app to make it perfect.
In project environments with engineers as the business solution owners, this can raise conflicts and lead to never-ending project iteration cycles. By nature, engineers expect solutions to be perfect and complete, so they can’t apply the concept of iterative improvement to their projects and products. They’re educated, trained and measured against the quality of the first — and often only — release of their products.
Engineers intuitively have the same expectations for enterprise mobile solutions. The first release of an enterprise app needs to satisfy every imaginable user need. The expectation is that it’s perfect and polished. However, the risk is high that something else will happen. The mobile app development project for the first release will never end. Every change request will raise the wish list for new functions, and each function will lead to new defects in the next test cycle.
The longing for a perfect, one-size-fits-all mobile app that addresses all possible users’ needs is usually doomed to fail. The need for perfection and the fear of having missed something prevents these decision-makers from agreeing on fundamental and necessary steps in the mobile app lifecycle, releasing the mobile solution to users and preparing the next release cycles.
To address this issue, it’s important that the development team and the client are aware of the very special nature of agile projects and mobile apps. A change management process needs to be set up to educate the client team and users to settle their expectations for agility in mobile apps from the beginning. It’s vital to focus on the quick release of a stable, high-quality MVP that addresses the very core needs of the users. The product will then be constantly improved in further releases to reach perfection step by step.