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.

Comments

• Anonymous
  November 16, 2010
  I agree that a lack of conscious attention to process is a common failing. Not to single them out, but particularly in 'Microsoft Shops'. I also agree that improving the team's process should be the responsibility of the team. Where I might disagree with you is where you say that there should be an iteration focusing on process improvement. To paraphrase Adizes: The one thing that will always be relied on is change. Change causes problems. Problems require solutions. Solutions cause change. So, firstly, this means you will always have problems. :)  But these problems will change as the life-cycle of the team/project progresses. The team needs to constantly review their practices & processes all the time to make sure they are solving the right problems at the right time. Process improvement is not something that can be done once, and the best solution found. It should be continuous and constantly reviewing and improving it should be burned into the team's dna.

• Anonymous
  November 17, 2010
  Hi Kevin, Thanks for the comment. The MQ milestone that I referred to at Microsoft is not a once off. It has happens between every release - and this for the reasons you mentioned i.e things change. Now every org is a little different, and they would need to choose the mechanism for improvement that suits them best. What I find with most customers however, is they simply tell me that they are too busy "building features" to focus on improving the process. If they perhaps dedicated some time to process improvement (and think of it as a feature) it might help. A few years ago Microsoft did something similar with security. Today security is just embedded into the day to day activities - but before we got here, we had to spend time working on it. Another example -  would you look to change your build system that is maybe 80% working,in the middle of a project. Probably not. But you might look to make it when the project is done.

• Anonymous
  November 17, 2010
  To use your example of the build system, here is how one of the teams I coach might handle it; I think this ties in with exactly what you are saying about thinking of process improvement as a feature... Assuming they were a product dev team they would probably be working in two week iterations. At the end of each iteration they get together outside of the team room, just the team, and answer the following 3 questions:

1. What are we doing right that if we don't discuss we might not continue to do?
2. What can we improve?
3. What is puzzling us? There are a number of games/techniques that can be played to derive these answers. The build system issue would come up under Q2. They would write a story for it as follows: ACTOR:    The Dev Team ACTION:   <specific actions to fix the build system> REASON: <specific business value for doing this> This would get popped onto the teams backlog and would get estimated and then prioritised along with all the other Stories on the backlog.