Agile Ramblings

Technology, Market and People: What makes for a successful project?

April 20th, 2006

Most software practitioners I’ve met think the choice of technologies (programming languages, tools, libraries, etc.) has the largest influence on a project’s success. I actually think it is a minor influence and I think the project’s alignment with market demands is the single largest determinant of success.

While there are those who would explicitly claim the significance of technology, when asked directly developers may cite another factor. However, I make my claim regarding this “conventional wisdom” based on behavior; in most any project I’ve been involved in, a tremendous amount of time and energy is dedicated to selection of programming languages, technical evaluations, and debates about architecture and patterns.

By contrast, it seems the topic that gets the least attention is a very simple question: Are we solving the right problem? It amazes me how often, because of lack of interest or a strong sense of faith, developers do not question why they are building the application they spent countless hours working on.

From a separation of roles and responsibilities perspective, it seems appropriate that developers should not concern themselves with such a question; it is the job of the product manager. However, I’ve seen the most successful teams consist of a cross functional group, where each member took an active interest and responsibility for the project’s outcome. (Anyone been involved in a technical success, but it was a business failure?)

Agile software development can help a lot; the emphasis on communication, feedback and iterative development encourages the identification of real user need. It is amazing how much clarity can be achieved when developers and users sit together in the same room or you demo an application every two weeks. Alternatively, I find that traditional, specialized and compartmentalized development models, where information is “handed over the wall” or communicated with documents instead of conversation encourage a very myopic view by developers. Even if you wanted to better understand the business goals, pressures and motivations for the project, there may not been anyone accessible to ask.

Though I make a living being a proponent of agile development, giving too much significance to the process is just as misguided as emphasizing the technology. Agile development can be an effective means at understanding market needs, but it is not an end unto itself.

If I were to quantify my idea, in terms of percent influence on success, alignment with market needs accounts for 65%-75%, process, practices and team dynamics for about 20%-25% and technology for only 5%-10%. Similarly, I think the time and effort spent evaluating issues or devising tactics should be proportional to their importance. Simply put, I’d rather spend three weeks training a development team about user’s daily activities than three weeks evaluating the choice of Java vs. Ruby or SOAP vs. REST.

I’ve seen numerous examples where the development group had horrible practices or made many poor technical choices; it was amazing they ever got anything done. Yet, their products were great successes and wins for their organization. I’ve also seen cases where the architecture was beautiful and most any developer would awe at its magnificence, but it was flatly rejected by their user base. Unfortunately, I’ve even been involved in a case that was a marvel of agile adoption(well, at least the engineering practices): thousands of tests running in seconds, pair programming, and elaborate continuous builds: but it didn’t do much for the company’s bottom line.

Ultimately, you can’t win if you cross the wrong finish line.

Entry Filed under: Software Development, Teams, Strategy