Developers and the Process Paradox

I recently moved into Developer Solution Specialist role. This role has a decent amount of focus around application lifecycle management. As such, I have been spending a decent amount of time talking about development and testing processes. The one interesting bit that has struck me is the concept around process and developers.

Consider this. An organization, whether it be a bank, hospital or retail shop, has a set of processes. Quite often, this process would start off as a manual process. For example, taking orders might initially start off being manual. In order to achieve some optimization, they look to take this process and automate it. This is typically where a team of developers would come into play. They would build an application that would automate this process. Assuming this is well done, this automation of the processes would result in a significant productivity improvement. In the case of taking orders, you would now have a central system that would be easy to share, create and data mine. The sales people get to spend more time selling , and less time doing admin.

Developers, and other roles in the software developer lifecycle like business analysts, architects, testers, dbas etc all play a critical part in improving this process. Now this is where the interesting paradox comes in. Development teams spend a decent amount of time improving other’s processes, but spend very little time on improving their own.

Software development on its own is also a process. There are different kinds of streams. For example, you have a process when a bug occurs in production. You have a different process for dealing with a feature request, and you might have a different process for dealing with legal requirements.

Yet, it is interesting as to how little time is spent on improving processes within a software development team. For many teams, it it like we are still handling of invoices on paper. At a recent event, where we had more than 150 attendees, virtually no one in the room had a defined process for dealing with a bug in production. That is, the process for dealing with it is totally ad-hoc. Surely the time has some for software teams to improve their own processes.

At Microsoft, they have a milestone (aka iteration) called MQ. MQ stands for Milestone Quality. You can check an oldish video on it here. The basic premise is to spend some time (or an iteration) focussed on improving processes. Brian Harry also references MQ.