AGILE MODEL & METHODOLOGY

Agile is a way to manage projects. It can be used for virtually anything, but it was founded in
software development. This lesson focuses on agile for software development, but many of the
principles can be expanded to other fields.

Agile breaks down larger projects into small, manageable chunks called iterations. At the end of each
iteration (which generally takes place over a consistent time interval) something of value is produced.
The product produced during each iteration should be able to be put into the world to gain feedback
from users or stakeholders.

Unlike Waterfall project management, which is strictly sequenced: you don’t start design until
research is done and you don’t start development until the designs are signed off on; agile has
designers, developers and business people working together simultaneously.

As made popular by the “Agile Manifesto”, agile values:

Agile realizes that software (and marketing) projects are inherently unpredictable. Over the course of
any project there are likely to be changes. Be it market changes or feature changes as the product
comes to life. Agile embraces this unpredictability. By breaking down projects into small chunks, it
makes it easy to prioritize and add or drop features mid project. Something that is impossible in
traditional waterfall projects.

WHY AGILE ROCKS

SPEED TO MARKET

Agile lets you get your concept to your users as quickly as possible. During every sprint an agile
project delivers something of value. At any point, you may determine you want to launch what has
been delivered and start building a user base or testing your hypothesis.

FLEXIBILITY

Agile is based on accommodating change. Software projects consistently change. As a product comes
to life or the market expands, you should be able to react and update the product accordingly. Agile
also realizes that great ideas are bound to come mid-project and being locked into a scope doesn’t
let you take advantage of these realizations.

RISK MANAGEMENT

Incremental releases means that the product can be used early in the process by stakeholders and
users. This lets you identify issues and feature deficits early in the process. Being adaptable to
change means it isn’t a problem to change the scope midway through the project, something that
would be impossible in a waterfall style project.

COST CONTROL

Unlike a fixed budget project, agile is flexible with regard to scope. More often than not, our clients
realize features they originally requested are no longer necessary. This allows them to launch sooner
and pay less. Agile isn’t about paying a lot with uncertainty, it’s about paying for only what you need.
Need to stick within a budget? No problem! We can rearrange the product backlog so that critical
new features are implemented at the expense of less important features, not your budget.

QUALITY

Agile integrates testing throughout the process. Consistently delivering tested software means higher
overall quality and less time spent on QA-ing the full application.

RIGHT PRODUCT

Incremental releases let you test your product early and often. Even if you don’t release it to the
public, it’s much easier to locate flaws and things that can be improved when you have an actual
product to play with vs a series of designs.

TRANSPARENCY

Agile lets you see, feel and use a project consistently throughout the project. You don’t see things in
compartmentalized silos; you see how things work together

HOW AGILE WORKS

THE AGILE LIFE CYCLE

There are many different flavors of agile. Ultimately, it is up to your team to come up with the best
process for you. Generally they all follow a short life cycle, which repeats during each iteration. This
lesson focuses on Scrum, but many of the features are universal.

Scrum projects are broken down into short iterations (generally 1 - 3 weeks) called sprints. The
lifecycle of each sprint includes:
KICK OFF/SPRINT PLANNING

Each scrum project begins with a kick-off meeting. The first meeting is generally the most extensive
as the initial project backlog needs to be created and the project team introduced. Additionally,
before each of the future sprints there is a sprint planning meeting.

First, the kick-off meeting. The kick-off meeting’s goals are:

PROJECT BACKLOG

Behind every project is a project backlog. The project backlog is a list of all the product features
generally defined by “user stories”. User stories define everything potential users want to do on the
site.

They are defined for each of the user groups on the site and are structured like:
INDEPENDENT NEGOTIABLE VALUABLE ESTIMABLE SMALL TESTABLE

Remember that the project backlog is always fluid and never locked in. The project lead will be in
charge of reprioritizing the backlog between sprints. And if new features are dreamed up or
requested by users, they are encouraged to be added to the backlog. The one exception to the fluid
backlog is during a sprint. While the sprint is in session, it is important to not add features. That
keeps the team focused and makes sure that the project can be properly tracked.

FEATURE ESTIMATION

To be able to estimate what can get done per sprint and how long the full project will take, it is
necessary to estimate how long each user story will take. Because one of the major challenges in
development is accurately predicting how long things will take to get done, agile uses relative
estimation.

Features are rated on a 1, 2 or 3 point scale. More precise estimation is more challenging and ends
up less accurate. It is easy to compare things relatively on a scale of 3. And if something is particularly
challenging that you don’t think it fits within the “3 point” bucket, it should be broken down into
smaller features that can each fit into the respective buckets.

There are a number of ways to handle feature estimation. It can be as simple as just talking about it
or it can be slightly more complex using “planning poker”.

It’s also important to determine the sprint velocity of the team working on the project. That is how
many “points” the team can complete per sprint. This velocity is averaged over time. And in typical
average time value- the more sprints you do, the estimates and velocity become more and more
accurate. That is to say that in some sprints you may not hit your goal number and other sprints you
may exceed it. Over the course of a standard project, this averages out.

THE SPRINT

Agile projects are broken down into small, consistent time intervals. These intervals are referred to as
sprints. They can be as short as a few days and generally are no longer than 3 - 4 weeks.

We typically work in 1 - 3 week sprints depending on the extent of the overall project. During a sprint
there is a dedicated team that includes designers, developers and business people working together.

Before each sprint, there is a sprint planning meeting (often combined with the sprint review
meeting). This meeting determines what the goals are for that sprint. Based on the team velocity, a
set of features are pulled from the top of the backlog. During the sprint, no features are added and
the sprint goals don’t change. The only exception to this is if the team finishes a sprint early. Client
communication is generally limited to the daily stand-up results, but some firms allow for an open
dialog via a chatroom.

DAILY STANDUP

Every morning of the sprint the project team gets together for a short (under 15 minute) meeting.
This meeting takes place at the same time every day and includes everyone on the project. Everyone
stands up for the meeting to keep everyone focused and to keep the meeting short. Often a timer is
set so that the meeting does not run long.

Each person on the team is tasked to answer 3 simple questions:

𝟏. 𝐖𝐡𝐚𝐭 𝐝𝐢𝐝 𝐲𝐨𝐮 𝐝𝐨 𝐲𝐞𝐬𝐭𝐞𝐫𝐝𝐚𝐲?

𝟐. 𝐖𝐡𝐚𝐭 𝐚𝐫𝐞 𝐲𝐨𝐮 𝐠𝐨𝐢𝐧𝐠 𝐭𝐨 𝐝𝐨 𝐭𝐨𝐝𝐚𝐲?

𝟑. 𝐃𝐨 𝐲𝐨𝐮 𝐧𝐞𝐞𝐝 𝐚𝐧𝐲 𝐡𝐞𝐥𝐩 𝐨𝐫 𝐚𝐫𝐞 𝐭𝐡𝐞𝐫𝐞 𝐚𝐧𝐲 𝐛𝐥𝐨𝐜𝐤𝐞𝐫𝐬 𝐢𝐧 𝐭𝐡𝐞 𝐰𝐚𝐲?

These three questions allow for complete transparency. Everyone on the team is in the loop, and the
answers make people accountable for what they say they will deliver. The results of this meeting are
typically shared with the client. This daily communication makes sure that if something is holding up
the team, they can get a response quickly.

SPRINT REVIEW MEETING

The sprint review always starts with a functional demo. A conversation then takes place on how it
can be improved and if there needs to be any reprioritizing of the project backlog. Then the team
collectively plans out the next sprint.

KEY TO SUCCESS

COMMUNICATION

Any project benefits from good communication. Agile projects are no exception. If you haven’t run an
agile project before, communication is especially important. Being kept in the loop about what is
ahead of schedule and what is behind schedule can help alleviate concerns with unpredictability. A
transparent process keeps people at ease and lets them focus on what is important: delivering the
best possible product to their users.

DEDICATED TEAM

Agile works best with a dedicated team of people who are willing and want to collaborate. The better
the collaboration, the better the product.

GOOD PLANNING

For an agile project to succeed, it requires good planning. This doesn’t mean planning everything
down to the day or week like in a traditional waterfall project, but it does mean thinking through the
project ahead of time: coming up with a robust project backlog and estimating features as best you
can.

CONCLUSION

Agile is meant to improve your life, not complicate it. It is meant to help you release your products
faster, better and for less money. It is meant to be less risky than waterfall. It is meant to help teams
work together better to generate their best work. Give it a whirl. Start with a small project that you
can handle, and I bet you will enjoy it.