SDLC along with the words “Agile”, “Iterative”, “Kanban”, etc are, in my opinion buzz words. You can pick up a book and learn “Agile development”, you can take a few courses and get your “Scrum Certification”, but following the documented approach, as is, will only get you so far.

To really understand SDLC you have to get into the guts of how things really work; why do people do things the way they do and understand the “natural processes”.

For Start-ups, small companies, new companies, walking in one day, or starting of with something like “We are going to follow agile development”, works. It works real well because they choose to start with the textbook definition; it works real well because you have new developers who will be agile and flexible, and do things the way you choose to do. For such an environment, someone can walk in and make sure that things are being followed the way they are supposed to be; but unfortunately, this is not how it works when you try to take something that has been running for a (very) long time and you try to make it different.

As an example, look how some auto manufacturers have decided to implement and offer “high MPG vehicles”; some chose to restart and build a brand new vehicle; others attempted to re-purpose or salvage their offerings.

So talking about SDLC methodologies; Who really wants to follow a waterfall model? that makes you sound too outdated and boy, I wouldn’t want that on my resume. (Sarcasm). For many, waterfall is still the best methodology but they still want to move to something that’s more agile; and there is no harm in doing so, just as long as you understand and implement something that works well for you.

Now, to build something that works well for you, you really must understand YOUR current “Application Lifecycle” and see how it can be optimized. SDLC is just a very small part of the “Application Lifecycle” and once you understand, document and optimize your “Application Lifecycle” you can focus on modernizing your SDLC.

So, to build the example of understanding the “Application Lifecycle”, I will draw up a few diagrams. I will focus on the positive paths and not the negatives so that the model doesn’t get too complicated and I will also make some assumptions/skip extensive detailing, saving that for a separate post.

Starting the cycle.

1. Once you have gone through all the (painful) steps of creating a product (in no order: Sales, Requirements, Dev, Qa, Test, Release, Etc) you end up with Product
2. Customers use this product and they
3. Report issues
4. Reported issues go to your support team (hopefully)
5. and the support team analyzes these issues.

Pretty simple right?

You have now documented the beginning of the cycle as after product deliver, you are getting things back that require work. So what does support do after they Analyze the issue?

1. Confirm the issue and provide additional documentation (if needed), sending it to
2. Some review board, or decision maker as to what to do with this supposed issue, and determine if its something that needs to be resolved now (defect) or something that needs to be done at a later time (enhancement), or maybe you do not want to do it. In any case, 
3. The review board makes a decision in regards to releasing it (now).

At this point, hopefully there is some queue setup that allows intake of things for development to work on as they will trickle things into their work queues (depends on what SDLC methodology you follow)

1. Development picks up work and resolves the issue; after the issue is resolved, it is
2. sent to QA for additional testing, and once 
3. QA approves the resolution, its 
4. given to Release Management, who then
5. releases the resolution
6. giving you a packaged resolution.

All this assumes that there was actually a code defect, and that it required immediate resolution as it was critically impact a live customer. Things get a bit more complicated when you bring enhancements, non-code issues, and other things into the picture.

Also, big “hand waves” are done at various points in my flow, for example, the following things need to be looked at as well

1. How is the intake of work managed and prioritized, and by who?
2. What is the regression/integration process?
3. Who manages the movement of the issue from one area to another?
4. How are issues that should not go to the review board handled?
5. How does the information go back to the customer?
6. How is information distributed to other customers?
7. … and so on….

Understanding the Application Lifecycle, really does take “process improvement” to the next level as it allows you to follow several different best practices when it comes to SDLC or even the Organizational Lifecycle; For some organizations, they have a dedicated Business Process Office (or process office) that is responsible for looking at the big picture and ensuring that process is continuously optimized and improved.

So the next time you find yourself, wanting to “improve things” ask your self, “how big” of an impact you plan to make.

Being involved in such efforts right now, I wish you good luck.