What is Agile Methodology?

How It Works,
Best Practices, Tools
Stackify September 17, 2017 Developer Tips, Tricks & Resources, Insights for Dev Managers

Agile Methodology is a people-focused, results-focused approach to software development that

respects our rapidly changing world. It’s centered around adaptive planning, self-organization,
and short delivery times. It’s flexible, fast, and aims for continuous improvements in quality,
using tools like Scrum and eXtreme Programming.

How It Works

It works by first admitting that the old “waterfall” method of software development leaves a lot
to be desired. The process of “plan, design, build, test, deliver,” works okay for making cars or
buildings but not as well for creating software systems. In a business environment where
hardware, demand, and competition are all swiftly-changing variables, agile works by walking
the fine line between too much process and not enough.

Agile Methodology Overview

It abandons the risk of spending months or years on a process that ultimately fails because of
some small mistake in an early phase. It relies instead on trusting employees and teams to work
directly with customers to understand the goals and provide solutions in a fast and incremental
way.

 Faster, smaller. Traditional software development relied on phases like outlining the
requirements, planning, design, building, testing, and delivery. Agile methodology, by
contrast, looks to deploy the first increment in a couple weeks and the entire piece of
software in a couple months.
 Communication. Agile teams within the business work together daily at every stage of
the project through face-to-face meetings. This collaboration and communication ensure
the process stays on track even as conditions change.
 Feedback. Rather than waiting until the delivery phase to gauge success, teams
leveraging Agile methodology track the success and speed of the development process
regularly. Velocity is measured after the delivery of each increment.
 Trust. Agile teams and employees are self-organizing. Rather than following a manifesto
of rules from management intended to produce the desired result, they understand the
goals and create their own path to reach them.
 Adjust. Participants tune and adjust the process continually, following the KIS or Keep
It Simple principle.

For training purposes, there’s a comprehensive, downloadable overview here.

Examples of Agile Methodology

The most popular and common examples are Scrum, eXtreme Programming (XP), Feature
Driven Development (FDD), Dynamic Systems Development Method (DSDM), Adaptive
Software Development (ASD), Crystal, and Lean Software Development (LSD). Teams
generally pick one or two methods. The most widely used methodologies are Scrum and XP,
which dovetail nicely.

Scrum is a hands-on system consisting of simple interlocking steps and components:

 A product owner makes a prioritized wish list known as a product backlog.

 The scrum team takes one small piece of the top of the wish list called a sprint backlog
and plans to implement it.
 The team completes their sprint backlog task in a sprint (a 2-4 week period). They assess
progress in a meeting called a daily scrum.
 The ScrumMaster keeps the team focused on the goal.
 At the sprint’s end, the work is ready to ship or show. The team closes the sprint with a
review, then starts a new sprint.

Here’s an example of how Scrum works: Bill meets with a customer to discuss her company’s
needs. Those needs are the product backlog. Bill chooses the most important tasks to work on in
the next two weeks. His team meets in a daily scrum to target work for the day ahead and address
roadblocks. At the end of the sprint, Bill delivers the work, reviews the backlog, and sets the goal
for the next sprint. The cycle repeats until the software is complete.
 Image via Open-Ware.org

eXtreme Programming. Often used with scrum, XP is an example of how Agile can heighten
customer satisfaction. Rather than deliver everything the customer could ever want far in the
future, it gives them what they need now, fast. XP is centered on frequent releases and short
development cycles. It uses code review, pair programming, unit testing, and frequent
communication with the customer.

Here’s an example of how XP works: Bill builds a list of customer requirements by having the
customer tell “user stories” that outline the features. From these, he builds a software release
plan. The software will be delivered in iterations, with one delivered every couple weeks. The
team works in programmer pairs, using daily meetings to smooth roadblocks. The customer
delivers feedback in the form of more user stories. The cycle repeats until the software is
delivered.

For more examples, see this article.

Benefits of Agile Methodology

The benefits of Agile are tied directly to its faster, lighter, more engaged mindset. The process, in
a nutshell, delivers what the customer wants, when the customer wants it. There’s much less
wasted time spent developing in the wrong direction, and the entire system is quicker to respond
to changes. For a more comprehensive list of benefits, see this post.

 Faster. Speed is one of the biggest benefits of Agile Methodology. A faster software
development life cycle means less time between paying and getting paid. That, in turn,
means a more profitable business.
 Increased customer satisfaction. With Agile, customers don’t wait for months or years,
only to get exactly what they didn’t want. Instead, they get iterations of something very
close to what they want, very fast. The system adjusts quickly to refine the successful
customer solution, adapting as it goes to changes in the overall environment.
 Values employees. Employees whose ideas are valued are vastly more productive than
those who are ordered to follow a set of rules. The Agile Methodology respects
employees by giving them the goal, then trusting them to reach it. Since they’re the ones
with their hands on the controls and the ones who see the obstacles that crop up every
day, employees are in the best position to respond to challenges and meet the goals at
hand.
 Eliminates rework. By involving the customer at more than just the phases of
requirements and delivery, the project remains on-task and in-tune with customer needs
at every step. This means less backtracking and less “out on a limb” time between the
time we do the work and the time the customer suggests revisions.

Best Practices

The list of best practices is long and involved, with dozens of tools to pick and choose. We’ve
outlined a short list of the main benefits below. For a more comprehensive best practices guide,
see this article.

 Set priorities. A product backlog is a list of prioritized tasks maintained by a product

owner.
 Maintain small release cycles. The product should be released in increments every 2-4
weeks, with stakeholders giving feedback before proceeding.
 Use pair programming. Two programmers work side-by-side at a single computer. This
technique actually results in an identical degree of productivity to separate programming
but delivers higher quality.
 Refactor. Rework code regularly to achieve the same result with greater efficiency and
clarity.
 Use test-driven development. Code the unit test first to keep the project on task
throughout. Test-driven development as an Agile best practice also produces greater
employee engagement, since it transforms testing from a boring grind to a coding
challenge.
Software Engineering:
Software engineering covers not only the technical aspects of building software
systems, but also management issues, such as directing programming teams,
scheduling, and budgeting.
Software engineering is an engineering branch associated with development of software
product using well-defined scientific principles, methods and procedures. The outcome
of software engineering is an efficient and reliable software product.
Software project management has wider scope than software engineering process as it
involves communication, pre and post-delivery support etc.
The need of software engineering arises because of higher rate of change in user
requirements and environment on which the software is working.
 Large software- It is easier to build a wall than to a house or building, likewise,
as the size of software become large engineering has to step to give it a scientific
process.
 Scalability- If the software process were not based on scientific and engineering
concepts, it would be easier to re-create new software than to scale an existing
one.
 Cost- As hardware industry has shown its skills and huge manufacturing has
lower down the price of computer and electronic hardware. But the cost of
software remains high if proper process is not adapted.
 Dynamic Nature- The always growing and adapting nature of software hugely
depends upon the environment in which user works. If the nature of software is
always changing, new enhancements need to be done in the existing one. This is
where software engineering plays a good role.
 Quality Management- Better process of software development provides better
and quality software product.
RE Engineering:
• Restructuring or rewriting part or all of a system without changing its functionality
• Applicable when some (but not all) subsystems of a larger system require frequent
maintenance
• Reengineering involves putting in the effort to make it easier to maintain
• The reengineered system may also be restructured and should be re-documented
When do you decide to reengineer?
• When system changes are confined to one subsystem, the subsystem needs to be
reengineered
• When hardware or software support becomes obsolete
• When tools to support restructuring are readily available

Economics of Reengineering:
• Cost of maintenance: cost annual of operation and maintenance over application
lifetime
• Cost of reengineering: predicted return on investment reduced by cost of
implementing changes and engineering risk factors
• Cost benefit: Cost of re engineering - Cost of maintenance
Re-engineering advantages:
Reduced risk
There is a high risk in new software development. There may be development
problems, staffing problems and specification problems
Reduced cost
The cost of re-engineering is often significantly less than the costs of developing new
software
The complete Software Re-Engineering lifecycle includes:
Product Management: Risks analysis, root cause analysis, business analysis,
requirements elicitation and management, product planning and scoping, competitive
analysis
Research and Innovation: Definition of a problem, data gathering and analysis,
identifying a solution and developing best-of-breed or innovative algorithms, verification
of quality for data and results, patent preparation
Product Development: Technology analysis and selection, software architecture and
design, data architecture, deployment architecture, prototyping and production code
development, comprehensive software testing, data quality testing, and product
packaging and deployment preparation
Product Delivery and Support: Hardware/Platform analysis and selection, deployment
and release procedures definition, installations and upgrades, tracking support issues,
organizing maintenance releases.
Project Management: Brings efficiency and productivity to your software re-engineering
project by utilizing modern, practical software project management, software quality
assurance, data quality assurance, and advanced risk management techniques.
Reverse Engineering:
Reverse engineering is taking apart an object to see how it works in order to duplicate
or enhance the object. The practice, taken from older industries, is now frequently used
on computer hardware and software. Software reverse engineering involves reversing a
program's machine code (the string of 0s and 1s that are sent to the logic processor)
back into the source code that it was written in, using program language statements.
Reverse-engineering is used for many purposes: as a learning tool; as a way to make
new, compatible products that are cheaper than what's currently on the market; for
making software interoperate more effectively or to bridge data between different
operating systems or databases; and to uncover the undocumented features of
commercial products.
Following are reasons for reverse engineering a part or product:
1. The original manufacturer of a product no longer produces a product
2. There is inadequate documentation of the original design
3. The original manufacturer no longer exists, but a customer needs the product
4. The original design documentation has been lost or never existed
5. Some bad features of a product need to be designed out. For example,
excessive wear might indicate where a product should be improved
6. To strengthen the good features of a product based on long-term usage of the
product
7. To analyze the good and bad features of competitors' product
8. To explore new avenues to improve product performance and features
9. To gain competitive benchmarking methods to understand competitor's products
and develop better products
10. The original CAD model is not sufficient to support modifications or current
manufacturing methods
11. The original supplier is unable or unwilling to provide additional parts
12. The original equipment manufacturers are either unwilling or unable to supply
replacement parts, or demand inflated costs for sole-source parts
13. To update obsolete materials or antiquated manufacturing processes with more
current, less-expensive technologies.
 CMMI Maturity Levels
Advertisements
 Previous Page
Next Page  

A maturity level is a well-defined evolutionary plateau toward achieving a mature

software process. Each maturity level provides a layer in the foundation for continuous
process improvement.
In CMMI models with a staged representation, there are five maturity levels designated
by the numbers 1 through 5

1. Initial
2. Managed
3. Defined
4. Quantitatively Managed
5. Optimizing

CMMI Staged Represenation- Maturity Levels

Now we will give more detail about each maturity level. Next section will list down all
the process areas related to these maturity levels.

Maturity Level Details:

Maturity levels consist of a predefined set of process areas. The maturity levels are
measured by the achievement of the specific and generic goals that apply to each
predefined set of process areas. The following sections describe the characteristics of
each maturity level in detail.

Maturity Level 1 - Initial

At maturity level 1, processes are usually ad hoc and chaotic. The organization usually
does not provide a stable environment. Success in these organizations depends on the
competence and heroics of the people in the organization and not on the use of proven
processes.
Maturity level 1 organizations often produce products and services that work; however,
they frequently exceed the budget and schedule of their projects.
Maturity level 1 organizations are characterized by a tendency to over commit,
abandon processes in the time of crisis, and not be able to repeat their past successes.

Maturity Level 2 - Managed

At maturity level 2, an organization has achieved all the specific and generic goals of
the maturity level 2 process areas. In other words, the projects of the organization have
ensured that requirements are managed and that processes are planned, performed,
measured, and controlled.
The process discipline reflected by maturity level 2 helps to ensure that existing
practices are retained during times of stress. When these practices are in place,
projects are performed and managed according to their documented plans.
At maturity level 2, requirements, processes, work products, and services are
managed. The status of the work products and the delivery of services are visible to
management at defined points.
Commitments are established among relevant stakeholders and are revised as
needed. Work products are reviewed with stakeholders and are controlled.
The work products and services satisfy their specified requirements, standards, and
objectives.

Maturity Level 3 - Defined

At maturity level 3, an organization has achieved all the specific and generic goals of
the process areas assigned to maturity levels 2 and 3.
At maturity level 3, processes are well characterized and understood, and are
described in standards, procedures, tools, and methods.
A critical distinction between maturity level 2 and maturity level 3 is the scope of
standards, process descriptions, and procedures. At maturity level 2, the standards,
process descriptions, and procedures may be quite different in each specific instance
of the process (for example, on a particular project). At maturity level 3, the standards,
process descriptions, and procedures for a project are tailored from the organization's
set of standard processes to suit a particular project or organizational unit. The
organization's set of standard processes includes the processes addressed at maturity
level 2 and maturity level 3. As a result, the processes that are performed across the
organization are consistent except for the differences allowed by the tailoring
guidelines.
Another critical distinction is that at maturity level 3, processes are typically described
in more detail and more rigorously than at maturity level 2. At maturity level 3,
processes are managed more proactively using an understanding of the
interrelationships of the process activities and detailed measures of the process, its
work products, and its services.

Maturity Level 4 - Quantitatively Managed

At maturity level 4, an organization has achieved all the specific goals of the process
areas assigned to maturity levels 2, 3, and 4 and the generic goals assigned to
maturity levels 2 and 3.
At maturity level 4 Subprocesses are selected that significantly contribute to overall
process performance. These selected subprocesses are controlled using statistical and
other quantitative techniques.
Quantitative objectives for quality and process performance are established and used
as criteria in managing processes. Quantitative objectives are based on the needs of
the customer, end users, organization, and process implementers. Quality and process
performance are understood in statistical terms and are managed throughout the life of
the processes.
For these processes, detailed measures of process performance are collected and
statistically analyzed. Special causes of process variation are identified and, where
appropriate, the sources of special causes are corrected to prevent future occurrences.
Quality and process performance measures are incorporated into the organization.s
measurement repository to support fact-based decision making in the future.
A critical distinction between maturity level 3 and maturity level 4 is the predictability of
process performance. At maturity level 4, the performance of processes is controlled
using statistical and other quantitative techniques, and is quantitatively predictable. At
maturity level 3, processes are only qualitatively predictable.

Maturity Level 5 - Optimizing

At maturity level 5, an organization has achieved all the specific goals of the process
areas assigned to maturity levels 2, 3, 4, and 5 and the generic goals assigned to
maturity levels 2 and 3.
Processes are continually improved based on a quantitative understanding of the
common causes of variation inherent in processes.
Maturity level 5 focuses on continually improving process performance through both
incremental and innovative technological improvements.
Quantitative process-improvement objectives for the organization are established,
continually revised to reflect changing business objectives, and used as criteria in
managing process improvement.
The effects of deployed process improvements are measured and evaluated against
the quantitative process-improvement objectives. Both the defined processes and the
organization's set of standard processes are targets of measurable improvement
activities.
Optimizing processes that are agile and innovative depends on the participation of an
empowered workforce aligned with the business values and objectives of the
organization. The organization's ability to rapidly respond to changes and opportunities
is enhanced by finding ways to accelerate and share learning. Improvement of the
processes is inherently part of everybody's role, resulting in a cycle of continual
improvement.
A critical distinction between maturity level 4 and maturity level 5 is the type of process
variation addressed. At maturity level 4, processes are concerned with addressing
special causes of process variation and providing statistical predictability of the results.
Though processes may produce predictable results, the results may be insufficient to
achieve the established objectives. At maturity level 5, processes are concerned with
addressing common causes of process variation and changing the process (that is,
shifting the mean of the process performance) to improve process performance (while
maintaining statistical predictability) to achieve the established quantitative process-
improvement objectives.

Maturity Levels Should Not be Skipped:

Each maturity level provides a necessary foundation for effective implementation of
processes at the next level.
 Higher level processes have less chance of success without the discipline provided by lower
levels.
 The effect of innovation can be obscured in a noisy process.
Higher maturity level processes may be performed by organizations at lower maturity
levels, with the risk of not being consistently applied in a crisis.