Implementing an SDLC


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.


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. 🙂


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!

Planning for Team System

Now that I have had the time to get into Team Foundation Server and Team System, I am really jazzed about the possibilities. Having said that, I have a few helpful hints that you should consider before adding Team System to your organization.

Planning your process

The first step is to choose a methodology. For most of you, the MSF Agile or MSF for CMMI will work fine. It just depends on how much process you want surrounding your work. CMMI has a lot of documentation and a very controlled change process. MSF Agile, on the other hand, is an Agile methodology, which, for those not familiar, means the process is driven more by schedule than functionality. The idea in Agile processes is to deliver on a regular basis with as much funcationality as possible. Yes, this is an over simplified answer, but it works for now.

For those who like Scrum, Conchango has released Scrum for Team System. It is a very thin process guidance template overall, as it has very few document artifacts. Scrum is designed to work with or without a lot of documentation.

What would I chose? I am quite fond MSF Agile, although I like a few of the Scrum reports, especially the breakdown reports. I also like a few of the old MSF documents, as well as a few CMMI documents, esp. change request documentation. The fortunate thing is I can download the MSF process template and add documents, reports, and other items, to my hearts content.


For those interested in changing their own templates, it is actually quite easy. First, go to the Team Menu and find the Process Manager option. Once option, click download and choose a root directory to download to. This is the way you update to the latest version of the process guidance templates from Microsoft downloads.

My suggestion is you seriously examine each of the process templates and determine which your organization is closest to. If you are not currently involved in a formal SDLC process, you will probably want to institute MSF Agile, as it is the simplest to institute up front and requires no extra work on the server. Scrum is also a good alternative for companies without a formal SDLC currently. If your organization has instituted CMMI, MSF for CMMI is your best option, although you might want to customize.

Migration of Source Code

The next decision point, for your first project, is migrate or not. If you currently use SourceSafe as your source control repository, Microsoft has a command line tool for migrating source. If you use another SCM, Component Software has a tool for migrating source from a variety of SCMs like CVS, RCS and SVN (and SourceSafe). Before migrating source, make sure your database is verified and has no problems. This is especially true with SourceSafe.

If you use a source control repository like SourceSafe, all of your source is located under a single root. The same is true in Team Foundation version control, but the source is organized based on your team project, at least in most cases. As you create a Team Project, you can connect to existing source, which is the case if you migrate the full source control repository in one step. If you have not migrated all code, you will want to migrate on a solution by solution basis and connect to a single Team Project.

Do not take your migration strategy too lightly, as you will get bitten if you approach this without some thought.

What version of Team Foundation Server?

This largely depends on your organization. If you have five or fewer people that need Team Explorer installed (ie, have a DIRECT stake in the project, will have tasks assigned, etc.), you can use the Workgroup edition that comes free with every Team System product. If not, you will have to get the Team Foundation Server full edition.

Single or Dual Server install? In most cases, Single is fine. The tests MS has done show a single server install, on a decent server, will handle teams up to hundreds of members. Check out this blog entry for more info. If you have more than 500 members, you might consider a dual server install, of course.


Hope this helps!

Technorati Profile