Observing a discussion on which approach to software development projects is best can be like watching a “Smack Down” cage fight. The debate can be endless--those committed to traditional approaches square off against Agile Enthusiasts, Extreme Zealots and Scrum Loyalists.
The truth is that each has its strengths and weaknesses, good points and bad. Instead of standardizing on an approach, why not become proficient in each and let the natural nature of each project drive the method to be used? In this way, the answer to the question “Which method is best?” is simple: “It depends.” Just like there isn’t one best tool in a tool box, there is no one best SDP method or framework.
So how do you align the method to the natural attributes of a project? First, you have to understand the various SDP approaches--what they have in common and what makes each unique. Once that understanding is in place, it is relatively easy to see which approach best serves a specific project’s needs. This article provides an overview of several popular SDP approaches and identifies some basic criteria for selecting one approach over another for any given project. These approaches are:
A quick review of each approach will set the stage for the comparison chart provided at the end of the article. More complete definitions can be found on www.wikipedia.com.
Most software development project can be well serviced using the traditional PM model of:
It is important not to confuse project management approaches with SDP or traditional SDLC approaches. The traditional SDLC or Waterfall method proposes that software be developed in six stages as follows:
Students of SDLC thinking will recall that this lifecycle approach was developed when programming languages were very procedural (like Cobol, Fortran, etc.) and DBMS were in their infancy. Applications developed with these tools were very costly to change. In addition, most applications before SDLC appeared on the scene were poorly documented and rarely met end-user and operational needs. Thus, a sequential approach that validated needs and architecture before building commenced was born.
However, project management--whether traditional or not--has absolutely nothing to do with SDLC thinking, a common mistake among even seasoned veterans in the software development space. What has happened to the SDLC model is that the tools have become more flexible and robust, the cost of rework has been reduced and the need to have a total design in place before programming begins carries less risk.
This has allowed more iterative approaches to be viable, allowing software to be evolved (versus well planned and tightly scoped). However, the trade-offs to these alternative approaches is usually related to fixing time frames (e.g. what can be done in three weeks) or fixing budgets (e.g. what can be done for $50,000)--neither of which tend to lend themselves to large-scale, mission-critical and complex projects.
Under the Agile/Extreme approach to SDP, requirements and solutions evolve through collaboration between self-organizing cross-functional teams. This iterative approach claims advantages over the traditional SDLC approach because it embraces the principles espoused by the Agile Manifesto as follows (also from Wikipedia):
In actuality, none of these principles are at odds with traditional approaches. In fact, enlightened organizations have embraced these types of principles for decades prior to Agile’s arrival on the scene in the mid-1990’s.
So what really makes Agile different from a traditional SDLC approach? In a word, tools. With the dawn of developer workbenches, non-procedural languages and robust/flexible DBMS came the ability to rapidly prototype and cost effectively use heuristic approaches to develop applications. All of that can be very effectively used with a waterfall method, dramatically compressing time while affording management with a more predictable view of the future.
Where Agile shines is on short-throw projects where teams have difficulty discovering requirements without prototypes and management can tolerate vague work plans. While I am certain that Agile enthusiasts will whole-heartedly disagree with this point of view, I am equally certain that the way SDP are conceived and run is as much due to philosophy as it is technique.
Around 2003, I had the privilege of leading a talented development team on an 18-month effort to re-engineer a company’s core business processes and underlying IT systems. The project was scoped and planned using a traditional SDLC approach for a fixed fee and delivery date. However, part of the plan was to frequently test the assumptions driving the requirements and design effort and recalibrate as needed (i.e. the plan was made adaptive). In addition, state-of-the-art heuristic prototyping techniques were used to flesh out various components of the system when needed. In essence, within the framework of a traditional SDLC, Agile approaches were used, thus allowing the nature of what needed to be accomplished drive the method and not visa versa.
Imagine selecting the tools needed to build a house prior to understanding the nature of the house to be built. Should we use nail guns or hammers, power saws or hand saws? The answer of course is yes, use what works best. Fit the tool to the job lest we begin to use screw drivers to drive nails.
A cousin to Agile methods is Scum, whose roots can be traced to the works of Ken Schwaber, resident Advanced Development Methods and one of the founders of the Agile Alliance. A Scrum effort is more structured and rules-driven than Agile or Waterfall methods. This can be seen in the time boxing and role definitions used in a Scrum effort. Wikipedia explains it this way (emphasis is mine):
“Scrum is a ‘process skeleton’, which contains sets of practices and predefined roles. The main roles in Scrum are: (1) the ‘ScrumMaster’, who maintains the processes (typically in lieu of a project manager); (2) the ‘Product Owner’, who represents the stakeholders; and (3) the ‘Team’, a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.
During each “sprint”, typically a two-four week period (with the length being decided by the team), the team creates a potentially shippable product increment (for example, working and tested software). The set of features that go into a sprint come from the product ‘backlog’, which is a prioritized set of high-level requirements of work to be done. Which backlog items go into the sprint is determined during the sprint planning meeting. During this meeting, the Product Owner informs the team of the items in the product backlog that he wants completed. The team then determines how much of this they can commit to complete during the next sprint. During a sprint, no one is allowed to change the sprint backlog, which means that the requirements are frozen for that sprint. After a sprint is completed, the team demonstrates the use of the software.”
Basically, in a Scrum approach a very small component of the overall application gets developed. Therefore, an entire project like a complete ERP, CRM or HRMS might be comprised of many sprints. Again, following a Scrum model does not necessarily mean abandoning traditional SDLC approaches. Within a Sprint, the SDLC framework is alive and well (the backlog being the entire project). While Scrum was first conceived in a product development light, it is very suitable to small enhancement and software maintenance efforts where a team’s goal is to provide continuous improvements in small increments to existing applications.
Choosing the Best Approach
The following table summarizes the attributes of each of the above approaches to software development in terms of project attributes:
However, keep in mind that within a given project some parts of that project may lend themselves to traditional, Agile or Scrum approaches and it isn’t necessary to standardize one approach over another. In fact, a hybrid approach, fitting the tools to the need will most likely yield the greatest success.
External source: http://www.gantthead.com/content/articles/249454.cfm