Worried that development projects are perennially running behind schedule? The answer might be to think in terms of individual products, not long-running projects.
Project picture from Shutterstock
Speaking at Gartner’s Application Architecture, Development & Integration Summit in Sydney yesterday, analyst Nathan Wilson pointed out that while project-oriented approaches remained common, especially in larger enterprises, they rarely delivered the expected results or managed to stick to a schedule. “90% of projects are 90% done 90% of the time,” Wilson said. “Things get to almost done and then get stuck.”
Switching to a product-based approach, where you work on a specific piece of software, not an overall vision, can speed the process up, Wilson said. It also ensures more frequent conversations between developers and end users, which means that features included are more likely to be useful.
The traditional project-oriented approach often creates a feast/famine cycle, where users are only intermittently asked about their needs. “Users will ask for everything they can possibly think of, because they don’t know when they will see you again.”
Wilson advises setting an annual budget, but not making advance plans about what will be developed over that 12 month period. “Roadmaps are evil in an agile environment, especially roadmaps that have dates. You’re either lying to your clients or you’re prohibiting new ideas from showing up.”
A lack of integrated development processes creates issues. “Defects tend to be created very early in the process and found very late in the process,” Wilson said. “The earlier you detect, the lower the cost of fixing defects.”
Lack of research ahead of rolling out new projects also creates a problem. “We think we know what users are going to expect. When we get the product in their hands, there’s a lot of problems reported,” Wilson said. “Those aren’t defects because the code was written wrong; those are defects because the wrong code was written.”
A shift towards agile programming methodologies has help reduce some of those problems, but Wilson warned it wasn’t an approach that suited everything. “Most people know how to do agile at a certain scale, but are disappointed with how it works at a very large scale.”
“There are great solutions for agile at the project level that don’t scale to the portfolio level,” Wilson said. “So some tools are loved by developers but don’t give prog mgmt people everything they want.”
Automation can be useful, but only for frequently repeated tasks. “To make an automated test worthwhile, you have to run it ten times,” Wilson said, noting that the initial creation of a repeatable automated test would take roughly seven times as long compared to a one-time test.
Comments