The Agile Manifesto is comprised of four foundational values and 12 supporting principles which
lead the Agile approach to software development. Each Agile methodology applies
the four values in different ways, but all of them rely on them to guide the
development and delivery of high-quality, working software.
1. Individuals
and Interactions Over Processes and Tools
The first value in the Agile Manifesto is “Individuals and interactions over
processes and tools.” Valuing people more highly than processes or tools is
easy to understand because it is the people who respond
to business needs and drive the
development process. If the process or the tools drive development, the team is
less responsive to change and less likely to meet customer needs. Communication
is an example of the difference between valuing individuals versus process. In
the case of individuals, communication is fluid and happens when a need arises.
In the case of process, communication is scheduled and requires specific
content.
2. Working
Software Over Comprehensive Documentation -> living document
Historically, enormous amounts of time were spent on documenting the product
for development and ultimate delivery. Technical specifications, technical
requirements, technical prospectus, interface design documents, test plans,
documentation plans, and approvals required for each. The list was extensive
and was a cause for the long delays in development. Agile does not eliminate
documentation, but it streamlines it in a form that gives the developer what is
needed to do the work without getting bogged down in minutiae. Agile documents
requirements as user
stories, which are sufficient for a software developer to begin the
task of building a new function.
The Agile Manifesto values documentation, but it values working software more.
3. Customer
Collaboration Over Contract Negotiation
Negotiation is the period when the customer and the product manager work out
the details of a delivery, with points along the way where the details may be
renegotiated. Collaboration is a different creature entirely. With development
models such as Waterfall, customers negotiate the requirements for the product,
often in great detail, prior to any work starting. This meant the customer was
involved in the process of development before development began and after it
was completed, but not during the process. The Agile Manifesto describes a
customer who is engaged and collaborates throughout the development process,
making. This makes it far easier for development to meet their needs of the
customer. Agile methods may include the customer at intervals for periodic
demos, but a project could just as easily have an end-user as a daily part of
the team and attending all meetings, ensuring the product meets the business
needs of the customer.
4. Responding to
Change Over Following a Plan
Traditional software development regarded change as an expense, so it was to be
avoided. The intention was to develop detailed, elaborate plans, with a defined
set of features and with everything, generally, having as high a priority as
everything else, and with a large number of many dependencies on delivering in
a certain order so that the team can work on the next piece of the puzzle.
With Agile, the shortness of an iteration
means priorities can be shifted from
iteration to iteration and new features can be added into the next iteration.
Agile’s view is that changes always improve a project; changes provide
additional value.
Perhaps nothing illustrates Agile’s
positive approach to change better than the concept of Method Tailoring,
defined in An
Agile Information Systems Development Method in use as: “A process or
capability in which human agents determine a system development approach for a
specific project situation through responsive changes in, and dynamic
interplays between contexts, intentions, and method fragments.” Agile
methodologies allow the Agile team to modify the process and make it fit the
team rather than the other way around.
The Twelve
Principles are the guiding principles for the methodologies that are included
under the title “The Agile Movement.” They describe a culture in which change
is welcome, and the customer is the focus of the work. They also demonstrate
the movement’s intent as described by Alistair Cockburn, one of the signatories
to the Agile Manifesto, which is to bring development into alignment with
business needs.
The twelve
principles of agile development include:
1.
Customer
satisfaction through early and continuous software delivery – Customers are happier when
they receive working software at regular intervals, rather than waiting
extended periods of time between releases.
2.
Accommodate
changing requirements throughout the development process – The ability to avoid delays
when a requirement or feature request changes.
3.
Frequent
delivery of working software – Scrum accommodates this principle since the team
operates in software sprints or iterations that ensure regular delivery of
working software.
4.
Collaboration
between the business stakeholders and developers throughout the project – Better decisions are made when
the business and technical team are aligned.
5.
Support,
trust, and motivate the people involved – Motivated teams are more likely to deliver
their best work than unhappy teams.
6.
Enable
face-to-face interactions – Communication is more successful when development
teams are co-located.
7.
Working
software is the primary measure of progress – Delivering functional software to the
customer is the ultimate factor that measures progress.
8.
Agile
processes to support a consistent development pace – Teams
establish a repeatable and maintainable speed at which they can deliver working
software, and they repeat it with each release.
9.
Attention
to technical detail and design enhances agility – The right skills and good
design ensures the team can maintain the pace, constantly improve the product,
and sustain change.
10.
Simplicity – Develop just enough to
get the job done for right now.
11.
Self-organizing teams encourage great architectures, requirements, and
designs –
Skilled and motivated team members who have decision-making power, take
ownership, communicate regularly with other team members, and share ideas that
deliver quality products.
12.
Regular
reflections on how to become more effective – Self-improvement, process
improvement, advancing skills, and techniques help team members work more
efficiently.
The intention of
Agile is to align development with business needs, and the success of Agile is
apparent. Agile projects are customer focused and encourage customer guidance
and participation. As a result, Agile has grown to be an overarching view of
software development throughout the software industry and an industry all by
itself.
Advertisements
·
Sprint
Backlog Refinement
·
Sprint
Planning Meeting
·
Daily
Stand-up Meeting
·
Sprint
Review Meeting
·
Sprint
Retrospective Meeting
Sprint Backlog Refinement
Product Backlog refinement is the act of adding detail, estimates, and order to items
in the Product Backlog. This is an ongoing process in which the Product Owner
and the Development Team collaborate on the details of Product Backlog items.
During Product Backlog refinement, items are reviewed and revised.
As mentioned above, Product Backlog refinement is an
ongoing activity, and unless it is being conducted at scale it does not restricted to be
a time-boxed event (or meeting). However, there is nothing to
stop teams from time-boxing each refinement session anyway. In general it is
good practice to use time-boxing.
Sprint Planning Meeting
The goal of Sprint
Planning is to answer the questions “What are we going to work on, and how are
we going to do it?” It’s also important for the team to have a shared goal and
a shared commitment to this goal before beginning their Sprint – the list of
items the team plans to work on during that specific Sprint. The team then
breaks down these items into tasks, typically no bigger than a 2 days’ worth of
work.
Daily Stand-up Meeting
Once we begin a Sprint, we have what we call a Daily Scrum every
day. Organized by the Scrum Master, Daily Scrum is typically a 15-minute
stand-up meeting to synchronize the work of team members, i.e. what’s done on
the prior day, what needs to be done today, identify any impediments, and
creates visibility around the work that everyone is doing in the Sprint.
Note That
At the end of the
Sprint, the goal is to have a Potentially Shippable Product Increment (PSPI).
We’re trying to get something of incremental value done every Sprint.
Sprint Review Meeting
Held at the end of
each sprint to demonstrate the added functionality. The goal is to get feedback
from the product owner and other stakeholders to ensure that the delivered
increment met the business need and to revise the Product Backlog based on the
feedback. This feedback will then become items that will be looped back into
the Product Backlog, where it can be ordered and pulled in by the team in a
future Sprint.
Sprint Retrospective Meeting
Retrospectives
typically last 90 minutes and are there to help us incorporate continuous
improvement into our team culture and into our Sprint cadence. This is where
the Scrum Team meets to reflect on their previous Sprint and to figure out how
to improve as a team by asking – what went well, what did not and what can be
improved. It allows the team to focus on its overall performance and identify
strategies for continuous improvement.
