Rob Grady

There have been a few posts (here and here) regarding the role of developers in requirements gathering. While some might see the removal of requirements as a way to get developers closer to the customer or gain efficiencies in development, that topic is for a longer post. The best projects and best results have been working with passionate developers.

In my experience, ‚Äògood‚Äô developers don’t want requirements thrown over the fence but would rather take an active role in not only understanding but contributing in defining the solution. The myopic view on process-driven development often leads organizations to view the development process as a machine and people as cogs in that machine.
Too often this goal of optimization, titles and processes (which are all necessary) can reduce a developer to a ‘cog’ in the wheel. While the ‘plan’ sure looks good on paper, it doesn’t account for job satisfaction, growth or passion. While developers can be technology focused, enabling the technology team as a contributor further up in the process provides rewards in passionate developers downstream.

A CEO once asked me, “What are processes for?” I responded with the standard answer about efficiencies, standardization among other reasons and he stopped me. He said, “Processes are so people know what to do. And, when they don’t work, thats OK, we just modify them.” Processes are necessary but rarely do they inspire.

Inspiration comes from people working together and from my experience, involving the development team early yields a better solution, quality product and ultimately satisfied customer.