Growing up, I played football / soccer at school. We were all much, much younger when we first learned the game; so young that I think we could barely even count up to eleven, so it should have been no surprise to the coach that he had some difficulty in conveying the idea of team sports. He wanted us to stop thinking of ourselves as individuals, which was not easy as we were only just beginning to develop our own individuality. As a result of our youthful enthusiasm, we each spent most of the time running after the ball as if that were the only way to win.
Now that I am much, much older I see very similar behavior in adults; not on the soccer field but in various aspects of software development, especially the selection and implementation of new tools. The all too frequent view seems to be that if we could only get the right tool, we would be successful. Just as each of us boys in my team was running around thinking the ball was all that was important, I now see development team members ‘running around’ thinking that the tool is all that is important.
As my teammates and I got older, we began to understand that strategy was actually more important than the ball. Sometimes what a player does off the ball is as important, if not more so, than what the player does with the ball. When it comes to software tools, what we do outside the tool is as important, if not more so, than what we do with the tool. I’m talking about process; the business equivalent of the sports strategy. If we don’t have a good process dictating what we do as a team, then the tools we have are likely to make things worse, not better.
But so many times I have seen development teams trying to work out the best way to employ a software tool and not realize that it is their process that they need to examine first, not the tool. Take a testing tool as an example. Is there a clearly understood process within the organization into which the tool can fit? Are there parts of the process that cause problems or are inefficient? The tool will not solve the problem of bad process; the bad process must be addressed first. How does the testing aspect of the project fit into the larger project process? Will the project use agile concepts which demand testing early and often or will a more traditional approach be used in which the test team will be faced with a great deal of testing at a later time? How is the test management tool itself going to fit into whichever of these processes are in use? We must realize that we are a team, with a singular objective, not a group of individuals with personalized agendas.
Without process, how could anyone tell whether any particular tool is actually going to be useful or not? As individuals we run after the ball, sorry, I mean the software tool, as though it is the solution to our problems and that by just getting the tool, we’ll score a goal. The problem is, unless we have a strategy, we could just as easily score a goal for the other team.
Our mission to helping our customers - large corporations, small businesses, professional services firms, government agencies and individual developers – with the means to effectively and affordably manage their software development and testing lifecycles, so as to decrease the time to market and increase return on investment.
At Inflectra, we are fully committed to provide our customers with the very best products and customer service. We believe in going the extra mile to ensure that each customer is satisfied with our software products. We have the experience and the commitment to deliver the products customers need to deliver their projects and assure quality every step of the way. (Learn More)
We are so confident that you will be fully satisfied with our products that we offer a 30-day, unconditional, money back guarantee! (Learn More)