A good SDLC does not force developers to use any specific methodology such as Waterfall or Agile. Instead, it empowers project teams to decide which practices to use, within guidelines, for each project. Once the choice is made the teams remain on that pathway until production deployment.

Team empowerment is a greatly misunderstood concept. Empowerment does not mean senior leaders have abdicated their responsibility to lead their organizations. To the contrary, empowerment requires stronger leadership and accountability at the team level. Empowerment means allowing people at all levels of the organization to extend their decision making scope in order to furnish them with the latitude to more fully exploit their intrinsic resourcefulness, talents and skills. Empowerment leads to greater innovation, creativity, commitment and motivation; it broadens the breadth of individual and team contributions. Since the team has made the choice of which development practices to pursue, there is greater cohesiveness among its members.

Empowerment cannot be endowed without constraints. The last thing you want or need is for teams to select from any development model they desire. They might randomly choose any of the multitudes of models to be found on the net; or they may come up with their own model and call it “Because We Can.” If that’s allowed to happen, chaos becomes the rule the day. Restraint is found in limiting choices to among a preferred few. The select few are those practices that have been elected through management prerogative because they most closely align with IT strategy. Management continues to lead the organization, but has granted privilege to the project teams to choose how they control their implementations.

Having several practice models to pick from does not mean that everyone is going to be doing their own thing. That would defeat the purpose of the SDLC. The permitted models are subordinate to the overall SDLC framework. They are subsets of the grander design to achieve project success. They all have common deliverables and processes that bind them together to ensure consistency across the enterprise. They have to be agile enough to adapt to the organization’s culture and supple enough to be able to assimilate process improvements through the test of time. Depending on the team’s choice, the artifacts are flexible in terms of quantity of content, but are steadfast in the type and quality of content required, the documents needed, their naming conventions, their format and continuous improvement metrics.

In Chapter 2 of The Ultimate Guide to the SDLC, we examine, compare and synthesize best practices from twelve different historical models including waterfall, iterative and incremental varieties, RAD, agile variants, a hybrid and at least one that isn’t a model at all but a philosophy—Lean.