Agile Methodologies for Software Development
The various agile methodologies share much of the same philosophy, as well as many of the same characteristics and practices. But from an implementation standpoint, each has its own recipe of practices, terminology and tactics. Here, we have summarized a few of the main methodology contenders.
Scrum is a lightweight agile project management framework with broad applicability for managing and controlling iterative and incremental projects of all types. Ken Schwaber, Mike Beedle, Jeff Sutherland and others have contributed significantly to the evolution of Scrum over the last decade. Scrum has garnered increasing popularity in the software community due to its simplicity, proven productivity, and ability to act as a wrapper for various engineering practices promoted by other agile methodologies.
In Scrum, the “Product Owner” works closely with the team to identify and prioritize system functionality in the form of a “Product Backlog”. The Product Backlog consists of features, bug fixes, non-functional requirements, etc. – whatever needs to be done in order to successfully deliver a working software system. With priorities driven by the Product Owner, cross-functional teams estimate and sign-up to deliver “potentially shippable increments” of software during successive Sprints, typically lasting 30 days. Once a Sprint’s Product Backlog is committed, no additional functionality can be added to the Sprint except by the team. Once a Sprint has been delivered, the Product Backlog is analyzed and re-prioritized, if necessary, and the next set of functionality is selected for the next Sprint.
Scrum has been proven to scale to multiple teams across very large organizations with 800+ people
Lean Software Development is an iterative agile methodology originally developed by Mary and Tom Poppendieck. Lean Software Development owes much of its principles and practices to the Lean Enterprise movement, and the practices of companies like Toyota. Lean Software Development focuses the team on delivering Value to the customer, and on the efficiency of the “Value Stream,” the mechanisms that deliver that Value. The main principles of Lean include:
✧ Eliminating Waste
✧ Amplifying Learning
✧ Deciding as Late as Possible
✧ Delivering as Fast as Possible
✧ Empowering the Team
✧ Building Integrity In Seeing the Whole
Lean eliminates waste through such practices as selecting only the truly valuable features for a system, prioritizing those selected, and delivering them in small batches. It emphasizes the speed and efficiency of development workflow, and relies on rapid and reliable feedback between programmers and customers. Lean uses the idea of work product being “pulled” via customer request. It focuses decision-making authority and ability on individuals and small teams, since research shows this to be faster and more efficient than hierarchical flow of control. Lean also concentrates on the efficiency of the use of team resources, trying to ensure that everyone is productive as much of the time as possible. It concentrates on concurrent work and the fewest possible intra-team workflow dependencies. Lean also strongly recommends that automated unit tests be written at the same time the code is written.
Kanban is an agile methodology for managing the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.
Kanban is based on 3 basic principles
Visualize what you do today (workflow): seeing all the items in context of each other can be very informative
Limit the amount of work in progress this helps balance the flow-based approach so teams don’t start and commit to too much at once
Enhance flow when something is finished, the next highest thing from the backlog is pulled into play
Kanban promotes continuous collaboration and encourages active, ongoing learning and improving by defining the best possible team workflow.
Extreme Programming (XP)
XP, originally described by Kent Beck, has emerged as one of the most popular and controversial agile methodologies. XP is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every 1-3 weeks.
The original XP recipe is based on four simple values – simplicity, communication, feedback, and courage – and twelve supporting practices:
✧ Planning Game
✧ Small Releases
✧ Customer Acceptance Tests
✧ Simple Design
✧ Pair Programming
✧ Test-Driven Development
✧ Continuous Integration
✧ Collective Code Ownership
✧ Coding Standards
✧ Sustainable Pace
In XP, the “Customer” works very closely with the development team to define and prioritize granular units of functionality referred to as “User Stories”. The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration by iteration basis. In order to maximize productivity, these practices provide a supportive, lightweight framework to guide a team and ensure high-quality software.
Feature-Driven Development (FDD)
The FDD variant of agile methodology was originally developed and articulated by Jeff De Luca, with contributions by M.A. Rajashima, Lim Bak Wee, Paul Szego, Jon Kern and Stephen Palmer. The first incarnation of FDD occured as a result of collaboration between De Luca and OOD thought leader Peter Coad. FDD is a model-driven, short-iteration process. It begins with establishing an overall model shape. Then it continues with a series of two-week “design by feature, build by feature” iterations. The features are small, “useful in the eyes of the client” results. FDD designs the rest of the development process around feature delivery using the following eight practices:
✧ Domain Object Modeling
✧ Developing by Feature
✧ Component/Class Ownership
✧ Feature Teams
✧ Configuration Management
✧ Regular Builds
Visibility of Progress and Results
FDD recommends specific programmer practices such as “Regular Builds” and “Component/Class Ownership”. FDD’s proponents claim that it scales more straightforwardly than other approaches, and is better suitable to larger teams. Unlike other agile methods, FDD describes specific, very short phases of work which are to be accomplished separately per feature. These include Domain Walkthrough, Design, Design Inspection, Code, Code Inspection, and Promote to Build.
|Fixed Bid||Time & Material||Retainer|
|Basic||Based on a specification prepared mentioning the cost to ensure the budget for the total project and deliverables and timelines to ensure all needs are met within stipulated timeline.||Based on the cost incurred by the resource utilization in a particular time period||Based on the need for a dedicated pool of IT resources as per the requirement, preference and expectation.|
|Applicability||Well Defined and specified solutions with relatively lower to medium levels of complexities Projects with clearly identified risks and assumptions Projects with a little scope for changes and enhancements during executionActively participating clients with a very strong decision making capabilities while providing a strong and regular feedback||Projects with variable scopes due to which accurate cost estimation is a complex task Projects with evolving specifications that leads to longer implementation phase Large scale and complex projects are best executed using this approach.||Scarcity of good resources Inadequate IT skills and rare skill resources Hiring & training issues High employee attrition rate High Employee Cost and inflation Improper utilization of resources|
|How it works||Based on the specifications received from Clients, we will prepare a proposal that will cover visual aspects, documentation, application design, testing, warranty period, change management, communication protocols, milestones, timelines and commercial details. Our analysts will discusses the project in detail and prepare a low level specification documents mentioning the various elements of the project.||This model can be adopted at any phase of the project such as, post-specification, pre-specification, post-architectural design, etc. and can involve problem definition, solution definition, research, business analysis, specifications, visual mapping, architectural design, documentation, coding, change management, testing, roll out and maintenance & support. Our analysts work in close collaboration with clients in order to define a realistic ticketing system based on project's complexity, proposed timelines, planned budget.||The model initiates with the identification of Client's requirements in terms of project volume, complexity, technology and infrastructure which is followed by SLA (Service Level Agreements) in order to define team composition as well as working methodology. The resource skills and roles matrix defines the costing.|
|Benifits||Risk mitigation Delivery within stipulated time-frame Calculated cost with desired quality||Adequate modification scope during execution Regular update on process and progress based on which clients can plan forward to squeeze or expand the project Optimized cost and timelines||Access to a highly competent resource pool having expertise across a range of technologies and industry verticals Allows clients to access experienced IT services at a predicable cost in predictable environments while focusing internal resources on strategic priorities Optimized cost and timelines|