“If debugging is the process of removing software bugs, then programming must be the process of putting them in” Edsger Dijkstra
"One man’s crappy software is another man’s full time job." Jessica Gaston
"Why do we use agile methodologies for software development? Let me illustrate by running through a typical "pre agile" scenario.
Customer: We need a new risk assessment system. We made our business case, got funding, and now need to get the system developed.
IT professional: Great! Let us see your requirements and we will get started.
Customer: Well, we would like to be able to access these two databases and…
IT professional: No, no, not like that. We need your requirements in the "system shall" format.
Customer: What is that?
IT professional: Easy! Give us a list of what you want the system to do! For example, who can use the system?
Customer: Anyone with authorization.
IT professional: Here is an example. The system shall allow access upon presentation of a qualifying username and password. Simple! Of course, we will need to go into detail about what that means, but that is what we are looking for.
So, off the customer went to gather requirements! This process could take months, sometimes even years. Eventually, there was a long list of requirements in the "system shall" format, so there would be another meeting with IT.
Customer: Here are my requirements!
IT professional: Great! Are you sure this is what you want?
Customer: Well, we don’t think of how we interact with systems like this, but we think so.
IT professional: We will let you know when we are done.
Months would often pass, and you had no idea how it was progressing or the development approach. What you received were milestone updates that used terms like “logical design and physical design”. Eventually, IT would contact you to conduct “user acceptance testing” (UAT).
IT professional: Here is the software you requested. We are very proud of it! We met all of your requirements.
Customer: Great, can you show me how it works?
IT professional: Not yet! We need to do UAT first. Here is that long list of requirements you gave us, and we are going to go down the list and make sure you got everything you asked for.
And so, you would. Checking off each requirement until you were through the list. When that list was completed, you were done.
But the system often wasn’t what you wanted! Software is all about user interface and “feel,” not just about core functionality. While the “system shall” requirements were met, the customer was often very unsatisfied. That led to this final interaction.
Customer: This isn’t what I wanted!
IT professional (pointing to the list): It is EXACTLY what you asked for.
I lived this, and it was as frustrating as it sounds for all parties.
Which is why we now have “agile" as an option.
Next, I’ll provide an overview of the agile manifesto.
Coda
It has been nearly a year since I last wrote a post, but in fairness, I have been very busy! My wife and I moved from Maryland to Florida, and we have a new grandson. I have also been very busy at work (that is another story!). But those are excuses. The real reason is that I got out of the habit of writing! With some downtime for the holiday, I am getting back into the habit.
Comments