Agile methodology is a collection of innovative, user-centered approaches to system development. It tries to define an overall system plan quickly, develop and release software quickly, and then continuously revise the software to add additional features. After the downsides of the traditional software development approaches were identified (too many documentations, all requirements must be known at the beginning of a project,…) it became obvious that we needed another approach. And that’s how Agile was created.
Agile software development (also called “agile”) isn’t a set of tools or a single methodology, but a philosophy of people who had realized that in software development it’s pretty hard to predict:
- The number of changes and priority changes in software requirements
- How much design is needed before construction is used to prove it
- The time for analysis, design, construction and testing
Therefore, the solution to those problems was an incremental development which was significant departure from the heavyweight document-driven software development methodologies— such as waterfall or iterative methodologies that were in general use at the time.
Agile development methodology is a conceptual framework for undertaking any software engineering project. There are a number of agile software development methods but the most popular are Extreme Programming (XP) and Scrum. In general, agile methods attempt to minimize risk and maximize productivity by developing software in short iterations and by deemphasizing work on interim work artifacts. Furthermore, it is people oriented and can be a great choice when starting a new project.
These are key characteristics of the agile methodology:
- Deliver frequently
- More iterations
- Less defects
- Test frequently
- Collaborative approach
- Maximum ROI
It is very effective in environments where frequent changes in the requirements happen quite often due to various business reasons. Since it has more iterations and more than one built deployment for a project, it involves more client interactions and testing which brings a solution for the requirement. Some people believe that there is less documentation in Agile, but it includes documentation and it can be used either in small or in large projects.
One of the really interesting facts about Agile is its manifesto (http://agilemanifesto.org), that says:
- Individuals and interactions over processes and tools (in agile development, self-organization and motivation are important, as are interactions like co-location and pair programming)
- Working software over comprehensive documentation (working software will be more useful and welcome than just presenting documents to clients in meetings)
- Customer collaboration over contract negotiation (requirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important)
- Responding to change over following a plan (agile development is focused on quick responses to change and continuous development)
The various agile methodologies share almost 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 are a few methodology types:
Scrum uses the real-world progress of a project — not a best guess or uninformed forecast — to plan and schedule releases. In Scrum, projects are divided into succinct work cadences, known as sprints, which are typically one to three weeks in duration. At the end of each sprint, stakeholders and team members meet to assess the project’s progress and plan its next steps. This allows project’s direction to be adjusted or reoriented based on the work completed, not speculation or predictions. Philosophically, the emphasis on an ongoing assessment of completed work is largely responsible for its popularity with managers and developers alike. But what allows the Scrum methodology to really work is a set of roles, responsibilities, and meetings that never change.
- Product Owner: In Scrum, the Product Owner is responsible for communicating the vision of the product to the development team. He or she must also represent the customer’s interests through requirements and prioritization. Because the Product Owner has the most authority of the three roles, it’s also the role with the most responsibility. In other words, the Product Owner is the single individual who must face the music when a project goes awry.
- ScrumMaster: The ScrumMaster acts as a liaison between the Product Owner and the team. The ScrumMaster does not manage the team. Instead, he or she works to remove any impediments that are obstructing the team from achieving its sprint goals. In short, this role helps the team remain creative and productive, while making sure its successes are visible to the Product Owner. The ScrumMaster also works to advise the Product Owner about how to maximize ROI for the team.
- Team Member: In the Scrum methodology, the team is responsible for completing the work. Ideally, teams consist of seven cross-functional members, plus or minus two individuals. For software projects, a typical team includes a mix of software engineers, architects, programmers, analysts, QA experts, testers, and UI designers. The team is responsible for determining how they will complete the task at hand. This grants teams a great deal of autonomy, but similar to the Product Owner’s situation, that freedom is accompanied by a responsibility to meet the goals.
Extreme Programming (XP)
XP 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 and 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:
1. Planning Game
2. Small Releases
3. Customer Acceptance Tests
4. Simple Design
5. Pair Programming
6. Test-Driven Development
8. Continuous Integration
9. Collective Code Ownership
10. Coding Standards
12. 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 for each iteration. In order to maximize productivity, the practices provide a supportive, lightweight framework to guide a team and ensure high-quality software.
Feature driven development
Lean Software Development is an iterative agile methodology. 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 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:
1. Eliminating Waste
2. Amplifying Learning
3. Deciding as Late as Possible
4. Delivering as Fast as Possible
5. Empowering the Team
6. Building Integrity In
7. 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 a product being “pulled” via customer request. It focuses on decision-making authority and ability of 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. 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 continuous 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 (WIP): this helps balance the flow-based approach so teams don’t commit to too much work at once
- Enhanced flow: When something is finished, the next highest thing from the backlog is pulled into play
The Crystal methodology is one of the most lightweight, adaptable approaches to software development. Crystal is actually comprised of a family of agile methodologies such as Crystal Clear, Crystal Yellow, Crystal Orange and others, whose unique characteristics are driven by several factors such as team size, system criticality, and project priorities. This Crystal family addresses the realization that each project requires a slightly tailored set of policies, practices, and processes in order to meet the project’s unique characteristics.
Several of the key tenets of Crystal include teamwork, communication, and simplicity, as well as frequently adjusting and improving the process. Like other agile methodologies, Crystal promotes early, frequent delivery of working software, high user involvement, adaptability, and the removal of bureaucracy or distractions.
When to use which methodology
- Project management wrapper around methodology in which developer practices are defined
- 30-day sprints in which priorities are not changed
- Daily Scrum meeting of Scrum team
- Burndown chart to display progress
- Intended for 10-12 co – located OOP programmers
- 12 highly specified, disciplined development practices
- Minimal documentation
- Rapid customer and developer feedback loops
- Methodology dependent on size of team and criticality of project
- Emphasis on face-to-face communication
- Consider people, interaction, community, skills, talents and communication the first-order effects
- Starts with minimal process and build up absolutely necessary
FEATURE DRIVEN DEVELOPMENT
- Scalable to larger teams
- Highly-specified development practices
- Development is an architectural shape, object model and sequence diagram
- Two – week features
When not to use Agile
Even though agile methodology is the best solution for many projects, there are situations where is better to use traditional software development methods:
- When you have to formally document the requirements, design, code, and testing cases during each phase of the software life cycle. This is usually the case when you build infrastructure application rather than business application.
- When deliverables must pass through a chain of approvals and tollgates. Applications that require phase-end reviews or reviews of major deliverables by senior management, by a PMO or any other office are not candidates for agile.
- When you have tools to create the software models but not to translate them to the low end software code.
- When you need to follow traditional software management processes and procedures. If the client and users are uncomfortable with anything but traditional ways of developing software, and remain unmoved by the value proposition for agile methods, that’s ok.
- When application users are NOT always accessible to you. Agile management depends on an effective, day-to-day working partnership between the development team, the client, and empowered users. If this partnership does not exist, or is likely to be weak, an agile project will face much higher risks than it should.
- When the project team can’t adapt to changes in working durations, overlaps & shifts. If project team can’t adopt new responsibilities and roles, it’s better not to use agile then.
- When you don’t have team with multiple skills, many times in one person (software architect, business analyst), it’s better not to user agile because agile asks for premium people.
As seen from everything abovementioned, we can say that Agile has got a number advantages and our team uses it every time we are faced with tight deadlines and we have to, as always, be quick and efficient. In my opinion, development teams with a maximum of 10 people are best for agile, for agile loses its original purpose with teams above that number. RUP is still the best method for larger projects that need a lot of documentation and have teams with more than 15 people. If you haven’t already tried Agile, do it – you might like it and it may sometimes solve some of your possible developmental problems.