Implementing an SDLC
July 20, 2006 2 Comments
Introduction
Recently, I have been involved with talks on the Software Development Lifecycle (SDLC) at the company I am currently working at. The discussions seem to have bogged down into Agile versus waterfall, with some Scrum versus {other Agile method here}. The crux of the problem lies in Scrum, with its trappings, being seen as the silver bullet that will rescue our process. As with any other topic that stirs emotion, many of the arguments presented are based on false pretenses.
What is a SDLC?
Simply put, SDLC is used to manage the full lifetime of an application, from conception to death. SDLC is the processes and methodologies put into place to ensure the application gets built correctly (and hopefully to business need), deployed correctly and decommissioned once it becomes a legacy. Tis definition is a bit lacking, but let’s roll on anyway.
With the basic definition out of the way, let’s delve into building software. In every project, you have some sort of charter or vision. The vision is not always written down, which is a mistake, but there is always some type of high level commitment (or idea) what is being built. From the initial vision, there is a set of functionality that is required to realize the vision. These individual items are catalogued in some method (Excel, Project, database, tracking software) and then refined into tasks that have to be completed to get the product done. When “enough” functionality is complete, the product can ship.
Waterfall versus Agile
A great majority of the fights I have seen are based on ignorance of these two words leading to an over-generalization of the one you dislike. In a black and white world, waterfall describes a process in which all of the documentation and planning is completed prior to any work being done, while Agile describes a process in which very little documentation is done prior to pounding out code. The world is not black and white, however, and an objective look at the two reveals more similarities than differences. Unfortunately, we often put on blinders when we start talking traditional versus agile methods.
The main difference I see in waterfall (CMMI, traditional, etc.) and Agile methodologies is the fact that Agile is always time boxed for a particular iteration while most companies using traditional methods are focused on features. In the end, both become feature driven, as you are not going to release a product until a certain set of features are completed, tested and stabilized. What Agile brings to the table (noting that you CAN do this using more traditional approaches, as well) is the ability to pull the trigger to flip into stabilization mode at the end of any iteration and have a release out the door within a month. This is very "kewl", but I can do this in watefall too, baby!
Caught on vernacular
Yes, words mean something, but drop it for a moment, as it clouds the issue.
When you have a conflict over traditional and agile methods, and you want it to erupt into a full blown fight, get caught up in terms. Make sure you say “scrum” at least 100 times per meeting, along with an occasional “backlog”, “burndown” and “sprint” thrown in for good measure. For those of you with the “deer in the headlight look”, these are Scrum terms (Scrum is AN agile method).
Since we have had terms rear their ugly head, let’s put this in a human readable format. The backlog is a prioritized list of functionality. There are two catalogues of items: one for the project as a whole and another for the current “sprint”, a term used to describe a period (generally two to four weeks) in which work is done to complete a specific set of functionality (aka, an iteration). A burndown is a chart of what has been completed out of the functionality list (backlog) and there are generally two burndown charts (one for the entire project and one for the functionality for the current period).
Do the words really matter? I would say not, at least not in the decision process, where they tend to lead one to the Intellectual Violence anti-pattern. Ultimately, you have to agree on what you call things, but you can call an iteration a sprint or a cow patty for all I care; the only thing that is important here is cow patty should mean cow patty and not hamburger. If this flew over your head, you are simply not sarcastic enough to survive in this industry. 
Documentation
There is a false idea that traditional methods equal documentation and agile methods do not. This is patently false. If you cannot describe what you are building prior to building it, you are playing. I am not against playing, by any means, as R&D is necessary for parts of every project, but you are not “working” on specific functionality if you have not figured out what you are building … period.
The main perceived difference is you generally have functional specifications followed by technical specifications in traditional methods and allow these items to evolve a bit more in agile. I have, however, worked in non-agile environments that allowed evolution to take place and find it is the case more often than not.
If you have no documentation, you are freewheeling. Even if you wait until you are on task to determine your direction, you should have documentation. Should it be written formally or stuck in comments and culled out by a tool like nDoc? That is up to the organization to decide.
My preference
I personally like MSF for Agile. It is very much like Scrum in many ways, except the wording, but has a few set deliverables that I find necessary to have a properly working project. Am I stuck on MSF Agile to the point I would not adopt another methodology? Not only no, but “hell no”. While most "new ideas" ARE NOT really new, we do occasionally learn something new or find a new combination of old ideas that revolutionize the industry. Conversely, we sometimes get stuck on the panacea idea and adopt ideas that are detrimental to our organizations … but, I digress.
Why MSF Agile? First, I am fond of Cooper’s Persona idea to describe users as “real” people. If you can describe your users and their motivations, prefs, etc., you are more likely to create an “intuitive” user interface. I also like MSF’s use of Usage Scenarios as mandatory up front documents. If I can describe how a user completes his tasks, filter through his persona, I end up with a good model to code against and a more useful user interface. In addition, my test plans and help documents tend to “write themselves”. I also have a very business focused application, which is extremely useful.
I have tailored my own Team System process guidance to include some Scrum items. This may change at the next organization I work with, but it works for me now. This is a personal preference, of course, and may not work for you. I really like the way Scrum meetings are set up and have adopted the daily meeting concept. I also like some of the reports in conchango’s “Scrum for Team System” process guidance template. But, I also find many holes in the system which I have plugged up with MSF Agile. 🙂
Summary
In my experience, the SDLC you choose and the development methodologies you employ are based on your own corporate needs and culture. There is nothing wrong with adopting some waterfall methods up front, requiring certain documents, etc. The key idea is setting up a process that will get you from point A to point B with the least amount of issues. If process is getting in the way of delivering software, you are doing something wrong.
Your mileage may vary! 
Stop Making Sense 