Which Is More Important for Development—Software or Method?
Determining the superior software development methodology is the subject of countless articles, papers, and studies. This raises a question: As project management software continues to gain popularity, which is more important—software or method?
Each new consultant has a different opinion on which methodology is best for increasing productivity and guaranteeing on-time delivery. Then there are the opinions of the developers—which are nearly as varied as developers’ personalities—and the sales and marketing departments at project management vendors, who would have you believe that if you just switch to their new tool, everything will be better.
When shopping for project management software, separating the signal from the noise is difficult. But development experts like Scott Ambler remind us that “repeatable processes have nothing to do with successful software development; repeatable results have everything to do with it.” Reading case studies where software development firms have implemented new project management tools reveals some eye-popping statistics:
- Reduced product time to market by 75 percent
- Twelvefold improvement in predictability of software delivery
- Reduced number of open product tickets by 92 percent
Of course, case studies from implementing a new methodology always have similar numbers; rarely do you see a study where a new method or tool didn’t have an immediate or fantastic effect.
So if processes are unimportant and results mean everything, what happens when the results are viewed through rose-colored glasses, as above? How does one decide on which tool or method is best, and whether the method or the software is more important?
In short, you don’t—there’s no one-size-fits-all solution. Different teams and projects can require different methods. Is your team colocated, or are you working with developers around the world? How large is your team? Are you developing a UI-intensive platform for a large user group, or a niche tool for a small number of technical users, like a data warehouse? Understanding the personalities and unique needs of your team is the first step.
Deciding on a tool or method is surprisingly similar to developing software. No matter the process or methodology, you always begin by defining your requirements and objectives.
- What do you need your software or process to do?
- What problems are you attempting to solve?
- Who are your end-users, and what do they need to best perform their functions?
Ask all your stakeholders these questions, and take your time when evaluating methods and tools. Make sure to test several options, preferably on smaller teams, before making a large investment or signing a long-term contract. Seek out the advice of trusted third parties to verify what you’re hearing from vendors.
In short, neither methodology nor project management software is more important; what truly matters is flexibility. If you try to put your development team in a box, you’re going to get bad results.
The next time a sales representative tries to tell you how his system will solve all your ills, remember that sometimes the right “tool” can be as simple as Post-It notes on the wall or an Excel spreadsheet.
