The classic project management model and the agile model have the same goals. Both want to organize a project and deliver it in a timely fashion, but classic project management and agile development have different ideas about how this process is most effectively achieved. Both approaches recognize that planning is essential if developers are to create a meaningful and responsive product.
Agile development diverges from the classic model in terms of when planning occurs. In the classic model, all planning happens before actual project development begins. Milestones are determined, including the number hours dedicated to achieving specific goals. Likewise scope and features are locked in. The System Development Lifecycle (SDLC) essentially recognizes that the development process is ongoing, that review and maintenance phases will recognize limits in the version under development, which can be implemented in future releases.
The agile approach does not require as much planning up front. Under the agile model, planning is more flexible. This flexibility has both positive and negative potential. On the positive side, changes may be incorporated later in the planning process. This recognizes both the creative capability of programmers as well as the reality that sometimes limitations cannot be seen in all instances prior to the start of the actual development process. These are concepts which are critical to fluid meaningful development, and should not be dismissed lightly.
On the potentially negative side, if the planning phase cannot be said to be definitively completed, it would be possible to 'talk something to death', which is to say, never to move past the planning phase and commit to actual development. This potential is even more of a concern when the development process solicits the input of highly creative individuals.
In the open source arena this can lead to a project 'forking' into different products as schism between personalities over the direction a product should take may eventually lead to breakup of development teams, or the loss of key team members. Such a dramatic segue may be entertaining to read about on open source project chat boards, but it has no place in serious commercial development. Clearly, even though creativity minds should be given a chance to add meaningfully to product development, there must be a line of demarcation where leadership prevents the chaos of uncontrolled egos and creativity.
Scrum is the process which attempts to create and maintain a balance between uncontrolled creative minds and the leadership necessary to drive a product in a stakeholder driven meaningful direction. To provide a brief analogy, picture a hallway with a closed door at the end. Now fill the hallway with cats and attempt to herd them through the doorway. Some will move quickly, some will need to be enticed, other will need to be carried. You will get them all through the doorway in the end, but the process and mechanics will be predictable in concept, unpredictable in practice, and perhaps unattractive or comical to behold. Once all of the cats have been herded through the first door, you close the door firmly, walk down and open the next door, and begin anew to herd your cats toward the second door.
The scrum concept will move all of the team from one stage to the next in similar fashion. It permits individual team members to contribute their own creativity, while at the same time keeping leadership (the scrum master) in a position to close off doors when needed to keep what is essentially a herd of cats manageable. Creative minds want to create, they generally do not want to manage. One of the basic principle of agile development is 'working software over comprehensive documentation', and lack of interest in management principles may be a badge of honor or propriety among developers. Yet management is an inescapable necessity in successful commercial development. Scrum provides the smaller steps necessary to provide distinct milestones without the feeling of micromanagement which can impede creativity and new ideas.
For more information on putting scrum to work for you projects, please contact us.