The demand for enterprise mobile apps just isn’t letting up. The research firm Gartner expects that by the end of 2017 enterprise user thirst for mobile apps will be growing five times more quickly than internal IT organizations can deliver those apps. And a recent Opinion Matters survey found that enterprises are already hitting deep backlogs, with 85% of enterprises surveyed reporting that they already have a significant mobile app development backlog.
Such a backlog, as we’ve covered earlier, suffocates an enterprise’s ability to innovate and be competitive. When enterprises take too long to give development teams the app specs they need, and those apps take weeks and months to build and ship, the enterprise just lumbers along in its digital efforts. That means worker productivity lags, too. Most of the time customers aren’t happy with their experience, either.
Why are enterprises having difficulty fulfilling their app demand? There are a number of reasons, notably that enterprise development teams often work the way things were accomplished a decade ago when IT was more centralized. First, the app needs approval from IT and then timelines are set. And the app needs to be prioritized along with everything else on development team’s plate. When apps are approved, everyone tends to try to shove his or her pet features into them and the apps end up trying to achieve too much right out of the gate.
Enter the MVP
The result of all of this, of course, is that the time between the app request and its delivery is extended considerably, and when the app finally does arrive – if it doesn’t meet the required needs or is less than optimally executed – a big and time-consuming effort turns into a big and costly setback. It’s one of the reasons why so many enterprise mobile apps fail, with 50 percent of respondents to a recent survey saying that their mobile apps failed because of poor user experience.
It’s also one of the reasons why more enterprises are embracing the Minimum Viable Product, or MVP, as a way to get try to get apps with the features users need as quickly as possible, while not investing too much time in apps that users don’t desire. “In the strictest definition of MVP, it refers to a product that delivers the highest ROI relative to risk,” says Scott Amyx, CEO at Amyx+, a smart wearables and Internet of Things strategy and development agency.
What does that mean, practically, to CIOs and development teams trying to develop more apps that are more on target to user needs? Asaf Yigal, cofounder and VP of product at data analytics platform provider Logz.io, says it means that developers should start with a minimalist, but useful, definition of the app that is to be created.
At Logz.io, Yigal explains, the company develops with an agile methodology. “It’s critical for us to be able to define the MVP before we start a project,” he says. “There are two key objectives when defining a MVP. The first objective is that the majority of the users need to be able to benefit from a new feature – this means that we don’t address edge cases in development at all. The second objective is that we need to be able to analyze how users will be using the new feature. We are a data-driven company, which means that we log all relevant events in every feature we develop and build internal dashboards that display how users are interacting with a given feature,” he says.
Small teams, small apps, tight focus
Greg Archbald, founder & CEO of oil and gas industry software provider GreaseBook, has worked with dozens of oil and gas companies, ranging in size from those with tens of billions in revenue to those with less than one billion in revenue. Archbald explains that while the “super majors” of the industry have plenty of success extracting hydrocarbons, they don’t necessarily excel in building software. “Even the companies that have managed to land themselves some really strong development talent tend to struggle with project scope,” says Archbald.
Why? It’s the sheer number of people that become involved in the development process, he explains: ”I’ve seen first hand how layers of management, engineers, and production supervisors (all with the best intentions) become involved, and this is where issues begin. Everyone needs the app to do something different, and pretty soon feature creep settles in.”
This is especially true for development teams that find building systems easy, but dealing with people more difficult. “For much of software to be successful, it must focus on the human elements, not the technical. And, most larger companies don’t realize this soon enough and ultimately set themselves up for failure,” Archbald says.
So who’s going to keep app development on track? It could start with learning when to say “no,” Archbald says. “This is very tricky because, as part of a development team working for a large company, you’re paid to develop, not to tell upper-management “no,” he says. But to be able to succeed with the MVP and clearing app backlog, it’s about clearing both unnecessary people and features. “The word ‘no’ is exactly what MVP stands for. And at larger companies, a successful MVP isn’t just about a limited set of features, but also about a limited number of people involved.
“It sounds counterintuitive, but many projects in the development succeed not in spite of the limitations but because the limitations were put on them. Limitations of the amount of input, manpower, beta-testers, and even funding – all of which are unheard of at the enterprise level – force a team to figure out more creative solutions.”
Jordhy Ledesma, CEO at creative design, information architecture, and custom programming consultancy Information Providers would likely agree. “Keep the development team to less than a handful of teammates. Develop using the SCRUM project management framework (which advises to code in sprints and ship functionalities in batches) and limit the project duration to less than six months,” says Ledesma. “What is sometimes misconstrued by the DevOps community is that MVP is about a tangible, minimal product more than a methodology to leverage. In other words, it’s an iterative process that helps us to refine our concepts, prototypes, data, analyses, and learnings to deliver high value to our target customers. It’s a framework.”
It’s not just about enterprise software; as more things and devices become interconnected, it’s going to be even more important that enterprises reduce risk with apps. “Our agencies work with both large enterprises and startups. When they come to us to conceptualize and develop wearables and IoT products and services, they almost always start with an aspirational vision. Sometimes, that means a laundry list of sensor technologies or data analytics capabilities,” explains Amyx.
“We work with them to understand, from the customer perspective, what is the biggest pain point and then to focus on delivering a focused solution that addresses the top problem statement. After we learn from an iteration, we do it again to incorporate customer feedback into the product roadmap. A tight MVP methodology turns a potentially daunting process into doable mini-sprints while helping our clients to focus. They are often surprised at the nth iteration how their product/service is vastly different from what they had originally envisioned,” Amyx says.
Originally published on DevOps. Published on November 3, 2015. Author George V. Hulme.
