Choosing the best Agile methodology for your development needs
To be Agile is to be active and involved. But how do we achieve these goals? Let’s look at some of the popular tools of the Agile trade.
What is the best Agile methodology?
Answering this question is a little like explaining what tool is right for the job without first knowing what the job is. All Agile methodologies share much of the same principles and practices. The right question is "Which one best suits the project at hand?"
No matter which track you follow, using Agile methodologies takes a commitment from more than just the software developer. Close collaboration between business experts and the development team and frequent face-to-face communication is essential to the success of any Agile project. To be Agile is to be active and involved. But how do we achieve these goals? Let’s look at some of the popular tools of the Agile trade.
The Agile Manifesto
In February of 2001, a group of 17 software programming practitioners came together to develop a manifesto on how to more effectively 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:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Depending on the school of thought you are from, these tenets might be completely foreign to you. But they are the de facto set of tools required for any Agile approach. The rest is simply 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 involvement between the customer (who is receiving the software) and the development team. The customer drives development output by prioritizing the most important functions as user stories. The development team delivers the user stories iteratively through continuous programming, testing, planning and close collaboration. Working software is delivered very frequently, typically every 1 to 3 weeks.
Pros: Fast, aggressive delivery model; High collaboration; Minimal documentation up front.
Cons: High discipline methodology; requires dedicated people from outside the IT department; Requires that everyone on the team have intimate knowledge of XP to be successful; Little documentation for handover.
Use: Best suited for smaller development teams consisting of senior developers with excellent communication skills who are able to work with and manage non-IT people.
SCRUM
SCRUM takes a more broad-brush approach to building software than XP. It is a framework for managing and controlling iterative work at the project level. In SCRUM, a “product owner,” let’s say a business application owner, works with both business and IT teams to identify and prioritize system-wide functionality in the form of a “product backlog.” Various team members sign up to deliver shippable increments of working software in what is known as a sprint, which generally last up to 30 days.
Scope creep is controlled by the development team so that no functionality can be added to the sprint once it is committed. Once a shippable increment is delivered, the product backlog is analyzed and, if needed, reprioritized and the cycle begins again.
Pros: Excellent control over scope creep; Encourages teamwork and transparency; Good visibility to management on development deficiencies and therefore is adaptive; Scales very well to multiple teams and geographic locations.
Cons: Focused on course-grained features; Sometimes leads to “quick-and-dirty” programming; Little documentation for handover.
Use: Best suited for product-focused IT shops where major focus is on delivering broad features in collaboration with product and project managers.
Feature-Driven Development (FDD)
FDD is a developer-centric process which consists of modeling a feature into its overall shape then delivering the model as a build in short two week iterations. Unlike SCRUM and XP, FDD focuses on specific units of work that go through a stringent process which proceeds through domain walkthrough, design, design inspection, code, code inspection and then promotion to the build. Models are developed which drive a feature list. A development plan is then created and a design package is created 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 timely manner.
Pros: Excellent documentation artifacts; High quality as a result of design and code inspections; Controlled 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 consuming if model is not initially correct; Time-consuming task tracking by project management; Time-consuming 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 major requirement.
Conclusion
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 choose depends highly on the IT environment and its internal processes you work within. Changing IT culture is difficult if what is currently being used works. But the benefits of an Agile approach could be the catalyst for taking the IT team to a whole new level of productivity.
