"Since mobile is all the rage," Semeniuk says, "it's too easy to get caught up in the mobile-first strategy and not stop to consider the real customer value provided by the mobile application." Such value includes creating the right tool for the needed job: "Some applications aren't well-suited with mobile scenarios -- for example, those that require large amounts of data entry."
2. Find the right mix of development methodologies to meet project needs
The wars over development methodologies -- agile, XP (extreme programming), waterfall, and so on -- are fast giving way to a more fluid and flexible approach to producing and refining a product. Telerik's Semeniuk is one of many in the modern development world who sees development methodologies not as dogmas to be followed to the letter, but toolkits to be raided for what's useful. Confining a development team to one methodology is becoming a thing of the past.
"We have an iteration pattern for each problem," says Semeniuk, "in which we continually adjust or 'pull in' new agile practices that solve those problems. Sometimes we 'pull in' all of Scrum, because it solves the wide range of problems that come up in that particular environment. Sometimes we pull in pieces of Scrum or XP or Combine because it makes better sense if you're in maintenance mode." Semeniuk calls this the "agile buffet table" model.
For Telerik, though, the most important motive behind using any particular development practice is why. "We like to start with the 'why' and use agile to solve a real problem we're having. The biggest reason for that is when we try to just push out practices, they don't stick; people don't identify with the reasons these practices make sense. And not all practices fit all projects," he says.
Applico's Powers says his company also uses a variety of development models -- mainly agile and iterative. In his case, the "why" is driven by client needs.
"Some clients like rigid development timelines and documentation," says Powers, "especially ones that want to bring it in house. Others like the fluidity of the agile process and the ability to be brought in the loop at all times."
Some, however, caution that agile can't simply be sprayed onto an existing development process. A former program manager who has declined to be named but has five years of experience as a Scrum master has time and again seen agile used in development, but with no corresponding changes in other facets of bringing software to market.
"There's no intermittent QA; instead, there's old-school 'toss it over the wall to QA'-style QA," he says. "Instead of regular releases, they're using agile to get a release out, then having the schedule disrupted by support." In his purview, there has been a battle between traditional software releases and agile, with a lot of people simply using agile merely to drive old-school models.
3. Go with shorter lifecycles, cross-functional teams
The "mobile first" philosophy of modern development has also changed application lifecycle management in striking ways.
"Referring to a 'shorter development cycle' is misleading for Web development," says Andrew Frankel, former VP of engineering at TopShelfClothes.com. "It's no longer necessary to actually complete a full develop-QA-release cycle for every change. Small changes, such as changing text, can skip the usual process, since they can be deployed without any user impact. That frees the QA team to focus on testing actual application changes." Mobile and desktop app developers, he adds, aren't as lucky, since every change requires a new version.
For Telerik's Semeniuk, the biggest changes to application management are in Web and mobile. For those areas, he says, "You absolutely need short release cycles, because it's very difficult to pinpoint true customer value and interaction without actually measuring it."