Process Driven or People Driven Software Development?
Day 3 of TechEd and time for some reflections......
Solidsoft as an organization prides it's self on the customer centric, forward looking and professional manner in which we deliver our services. To that end we continually appraise the technology we use and the methods we employ. With this as a backdrop my thinking this week has been to consider the manner in which organizations, and of course ours, deliver successful outcomes for both our customers and ourselves. I have deliberately steered clear of saying successful projects as that is only part of what we can provide and therefore must not be the only focus. I'll say it again our focus is to deliver success for our customers, we want to help our customers succeed but not in a manner that is not successful for Solidsoft as well.
This leads me to the simple question I started with - should software development be process driven or people driven? A smart answer may be it's both of course! But is that smart?
This week, so far, I have attended a number of 'key' presentations, that's key to me! They include a number on Connected Systems Architecture, Anders excellent forward looking C# 3.0 but the two that have sparked my thinking, and I will say thinking that is still going on, were one on pure play Agile Development and Ivar Jacobson's Essential Unified Process EssUP. Now I picked these two as I expected them to be different sides of the same coin - how to deliver success for customers. Guess what, Ivar has had a major rethink about process, it's not people friendly!
At this point I thought it would be good to drop in an analogy of what is happening....
A number of years ago pre-Solidsoft I worked for a medium sized accounting software company. They had a document, well small book that described all the processes' I needed to follow as an employee. It was all part of their ISO 9000 coverage. So for the first ten minutes I flicked through it and decided it needed some serious reading, as I settled down to do that all hell let loose and my job started in earnest. So as all of us have done I popped into the drawer always meaning to return later.
About a month on I had need to get an urgent Fax off to a customer, now I had the standard company template on my PC so no problem there, next I considered a new problem - I had no idea where or how to Fax this off! Now in my drawer was my company handbook. In it it the a Fax procedure that was to be used company wide..... I now hit a number of problems, it wasn't people friendly and it had been written with headoffice in mind not our small southern satellite! The process was long and difficult requiring authorization from various people dependant on what it was for, about and to who....I couldn't work out how I was going to do it and worse still where I was going to do it and of course the clock was ticking and the customer was not going to be happy or successful.
So what was the solution? It was simply I followed the local practice that was in place, I went down to the admin office and asked them to fax it for me! How did I know how to do that? asked my fellow manager who explained it to me, simply and quickly. Now the process engineers out there would have course said ' The existing process should be modified to include this practice and while that is correct just think how much bigger that book is going to get! Or maybe we put it up on the web....
Ivar Jacobsan, god-father of the Unfied Process and Rational Unified Process stunned me yesterday when he virtually apologized for what he has produced over the last 15 years. His point was that the heavy weight processes he has defined and exalted over the years are just that - heavy, in fact far to heavy to be used. In his experience companies have either said they are following RUP or worse still have produced their own local version of it that works better for them. Hands up all of us who have done that! He believes that process in the way RUP and the like drive it is now counter productive to good practice. People just don't read the books, they don't read the documents that describe the process unless its around 4 pages long. Worse still, we may say we follow RUP but few really do......
So is Agile the answer - well yes and no. On it own it's maybe not enough. Finally what about the process maturity approach? Well that even worse, it's almost RUP on steroids. What we need is bits of all. We need agility, we need structure and yes we need process but we really mean is practice.
Where does this leave us? Well according to Mr Jacobson we all need his ESSUP but I'm not convinced. What I do know is it isn't as simple as selecting one of the solutions on offer. For now I need to do so more thinking but stay tuned this as they say has legs....