Answering this question is like explaining what tool is right for the task without first understanding what the job is. All Agile methodologies share almost same concepts and practices. The right question is “Which one best matches the project at hand?”.
No matter which track you follow, using Agile methodology takes a commitment from more than just the software developer. Close collaboration between business professionals and the development group and regular face-to-face communication is important to the success of any Agile project. To be Agile is to be active and included. But how do we attain these goals? Let’s look at some of the popular tools of the Agile methodology.
The Agile Manifesto
In February of 2001, a group of 17 software programming practitioners came together to develop a manifesto on the best ways to better build software. They didn’t agree on much but four things became clear and they are what the manifesto and all Agile methodologies are based upon:.
- People and interactions over procedures and tools.
- Working software over detailed documentation.
- Customer collaboration over contract settlement.
- Responding to change over following a strategy.
Depending on the school of thought you are from, these tenets might be entirely foreign to you. However they are the de facto set of tools required for any Agile method. The rest is just application of the right Agile methodology for the job.
Extreme Programming (XP)
Extreme Programming is an Agile methodology where there is a high level of participation in between the customer (who is receiving the software) and the development group. The customer drives development output by focusing on the most crucial functions as user stories. The development team provides the user stories iteratively through constant programming, testing, planning and close collaboration. Working software is provided very frequently, normally every 1 to 3 weeks.
Pros: Quick, aggressive delivery design; High collaboration; Minimal documentation up front.
Cons: High discipline methodology; requires dedicated people from outside the IT department; Needs that everybody on the group have intimate knowledge of XP to be effective; Little documentation for handover.
Use: Best suited for smaller sized development teams consisting of senior developers with exceptional communication abilities who are able to deal with and handle non-IT individuals.
SCRUM
SCRUM takes a more broad-brush method to structure software than XP. It is a framework for managing and controlling iterative work at the project level. In SCRUM, a “product owner,” let’s state a business application owner, works with both business and IT teams to identify and prioritize system-wide capability through a “product backlog.” Numerous team members register to provide shippable increments of working software in what is known as a sprint, which normally last approximately Thirty Days.
Scope creep is controlled by the development team so that no functionality can be enhanced the sprint once it is dedicated. As soon as a shippable increment is provided, the product stockpile is assessed and, if needed, reprioritized and the cycle begins again.
Pros: Excellent control over scope creep; Encourages team effort and transparency; Excellent presence to management on development shortages and for that reason is adaptive; Scales very well to several groups and geographic places.
Cons: Focused on course-grained functions; In some cases results in “quick-and-dirty” programming; Little documentation for handover.
Use: Best suited for product-focused IT shops where major purpose is on delivering broad features in collaboration with product and project managers.
Feature-Driven Development (FDD)
FDD is a developer-centric process which includes modeling a feature into its overall shape then delivering the design as a build in brief 2 week iterations. Unlike SCRUM and XP, FDD concentrates on particular devices of work that go through a strict process which proceeds through domain walkthrough, design, design assessment, code, code evaluation and after that promotion to the build. Models are established which drive a feature list. A development plan is then developed and a design package is developed for each feature. Inspections are held followed by a unit test then a promotion to the main build.
FDD promotes tight control over the development process resulting in tangible, working software produced repeatedly and in a prompt manner.
Pros: Excellent documentation artifacts; High quality as a result of design and code inspections; Managed build process; Model is class-oriented lending itself to object-oriented programming languages such as Java; Great insight to quality metrics early in the development process; Scales well to larger teams.
Cons: Requires a high degree of design and development skill; can be time taking in if design is not at first appropriate; Lengthy job tracking by project management; Lengthy planning.
Use: Best suited for corporate developers in regulation-driven environments such as insurance, finance, banking and government which have some degree of process maturity and where quality is a significant requirement.
Summary
So which Agile methodology is the best? None of them. Each is a tool for a specific job, not a one-size-fits-all approach. Which one you pick depends highly on the IT environment and its internal processes you work within. Changing IT culture is hard if what is presently being used works. However the benefits of an Agile approach could be the catalyst for taking the IT group to a whole new level of productivity.
