One of the pushes at Redgate Software over the last year or so is to move faster. We aim to develop software quicker and get the changes and improvements into the hands of our customers quicker. A new feature doesn’t help anyone if it sits inside of a VCS, undeployed, for months. Customers and clients need to see the software changes.
There are various ways to achieve this. The SQL Prompt team manages themselves, and being a small group, they have been successful at not only writing code quickly, but releasing often. In fact, they’ve released code to customers over 70 times in the last year. As a result, a few other development groups are looking to work in a similar, lightweight, rapid development manner.
However, that’s not an appropriate process for all developers. In fact, in most companies I’ve worked in, there is always someone that needs to manage and report on milestones and efforts to build software with some sort of plan. In addition, most products have a wider scope than something like SQL Prompt, which means more developers, more coordination required, and everyone must deal with more friction throughout the process.
One of our project managers wrote an interesting piece on how he worked to get the SQL Monitor team, one of our larger pieces of software, to meet their goals, and also move to a more rapid development and deployment process. It’s a look at the changes made in process and the adaptations to reality that occurred last year. I found it fascinating to read since I’d see the team dramatically improve the product in a fairly short period of time.
As with most of the stories about successful software development teams, buy in and support from management, especially project management is important. Without your leadership wanting and being willing to change, little will. Developers have to believe as well, but I suspect that if management truly supports improvement and is willing to change the way they work with developers, the people that write code are usually willing to go along for the ride