The People
It should go without saying that process is really only a small part of how software development in any company gets done or executed. The process is in place to attempt to guide and assist when questions come up or there are issues found during development. These problems can be with the intent of a feature or sometimes even with the 'code' implementation itself. In this respect each one of the processes above meets the need - they can all provide some level of guidance for an individual or group attempting to develop software. However with the exception of the 'agile' stack a good number of them miss the point... process is not helpful in dealing with people. Real people are doing the development and real people are hard to predict for over time.
The Process
Every software project I have ever been involved with attempts in some way to be predictable in its delivery of items. Items for the project may include documentation, code or a myriad of other things but in general the 'what is delivered' only matters in so much as this discussion being about software development. Some projects focus on Dates (not these or these) the times during the project on which certain "items" within the project will be delivered. New functionality or even the entire system development might be driven by these dates. Sometimes these magic dates are called 'Milestones'. These milestones are points in the project when supposedly major portions or steps of the project will be considered done (most of the time without a clear definition of what 'DONE' is). Gantt charts, carefully laid plans, deadlines, etc. etc. etc. all put in place to suffice a process that in the end is attempting to control and make predictable the delivery of software. All are attempts to stay in control of something that in most cases by its very nature is 'out' of the control of the person doing the planning.
OK - so maybe that last statement is a little harsh. Lets be realistic though, I am sure everyone reading this blog has been on one project or another where the schedule, deadlines and all, in addition to what was 'TO BE DONE' in the given time frame was essentially dictated to them by either management or a project/program manager that was being told to essentially get 'X' thing done by 'X' date. Addmitedly the world is full of deadlines - and some deadlines are needed, but having two of three sides of a triangle dictated doesn't leave alot of room for the 'last' variable to move around alot.
But in the end we plod forward, bad news is supressed because no one wants to hear it... and then everyone ends up on a DEATH MARCH to the end of the project. Everyone gets irritated because the work they may be doing is not of the highest quality (in some cases even mediocre quality) and everyone feels dirty about not adhearing to best practices when it comes to development. There are no unit tests, the documentation is shotty - and the delivered "thing" is held together with spit and bailing wire.
MOST Processes miss the point its not about the deadlines, its about the people - and maximising what they can do to get the most delivered possible with the highest possible quality.
Agile and people - some implementors miss the point
Most processes I have worked with and in focus on variables that most people think of as being easily controlled. Things like the delivery date or the number of people working on the project. It is true that these things are easily modified and very measureable but the item that most project/program managers don't consider is what happens when you don't fiddle with those things but instead work to fully understand the work and how much of it the development team can actually accomplish CORRECTLY.
How gaining this knowledge helpful or different from what most methodologies do and tout? First, having this understanding is a very agile practice in my mind. WARNING BROAD SWEEPING STATEMENT FOLLOWS: Usually project and program managers understand what needs to be done, but they don't understand the constraints in the existing software or sometimes even the existing systems if we are discussing full life cycle systems development. This is where controlling the work list is important and priority is KING.
Agile processes are all about knowing the priority work list and what the people CAN accomplish. In essence it is all about the people involved (project and program managers included in the 'people involved'). Agile is about knowing what the people are capable of doing, producing a measurement of that (velocity) and using it as a way to understand how much work a given group is capable of in a time box. This turns the tables and empowers the people involved to push back and say no to things because they have a definative measure of what they are truely capable of accomplishing well and correctly. That is not to say that on occasion some teams will go above and beyond, but that doing so becomes a CHOICE and not a MANDATE because the speed of the team is no longer a variable and if it is - it tends to be a very predictable one.
Agile is all about the people. People understanding themselves and the people they work with. Understanding what each one of them does best and putting those things together to get a deployment of working software out the door. Agile is about making the software delivery as predictable as possible. Agile is about adding the right process to the people to allow for that predictability. Agile is not about imposing or over imposing but focuses in on the people involved and helps them with the right 'touch' and guidance, the right process. In that respect - agile process is the hippy of the software development world - one that I am more then willing to embrace because it is the people that matter. Without the people - nothing gets done and if you have a process that works well with the people and not counter to them I would argue you are going to get alot more done with people being generally happier about it.
