What is Agile?

Agile is a time boxed, iterative approach to software delivery that builds software incrementally

from the start of the project, instead of trying to deliver it all at once near the end.

It works by breaking projects down into little bits of user functionality calleduser stories,        prioritizing them, and then continuously delivering them in short two week cycles callediterations.

How does it work?

At its core, Agile does the same thing you and I do when faced with too much to do and not enough time.

You make a list

Sitting down with your customer you make a list of features they would like to see in their software.              We call these thingsuser storiesand they become the To Do list for              your project.

You size things up

Then, using Agileestimationtechniques,              you size your stories relatively              to each other, coming up with a guess as to how long you think each user story will take.

You set some priorities

Like most lists, there always seems to be more to do than time allows. So you ask your customer to

prioritize their list so you get the most important stuff done first, and save the least

important for last.

You start executing

Then you start delivering some value. You start at the top. Work your way to the bottom. Building,

iterating,

and getting feedback from your customer as you go.

You update the plan as you go.

Then, as you and your customer starting delivering, one of two things is going to happen. You'll discover:

You're going fast enough. All is good. Or,

You have too much to do and not enough time.

At this point you have two choices. You can either a) do less and cut scope (recommended).

Or you can b) push out the date and ask for more money.

How is Agile different?

Analysis, design, coding, and testing are continuous activities

You are never done analysis, design, coding and testing on an Agile project. So long as there are

features to build, and the means to deliver them, these activities continue for the duration of the project.

Development is iterative

Iterative development means starting with something really simple, and adding to it incrementally over time.

It means evolving the architecture, accepting that your requirements are going to change,

and continuously refining and tweaking your product as you go.

Planning is adaptive

When reality disagrees with their plans, Agilists find it easier to change their plans than reality.

They call this adaptive planning.

And while there are many ways to changes plans, the preferred way is to flex on scope.

Roles blur

Roles really blur on Agile projects. When it’s done right, joining an Agile team is a lot like

working in a mini-startup. People pitch in and do whatever it takes to make the project successful—regardless

of title or role.

Yes, people still have core competencies, and, yes, they generally stick to what they are good at.

But on an agile project, narrowly defined roles like analyst, programmer, and tester don’t really exist - at

least not in the traditional sense.

Scope can vary

Agile deals with the age old problem of having too much to do and not enough time by doing less.

By fixing time, budget, and quality, and being flexing around scope, Agile team's maintain the integrity

of their plans, work within their means, and avoid the burnout, drama, and dysfunction traditionally associated

with our industry.

Requirements can change

Traditionally change has been shunned on software projects because of it's high perceived cost late

in the game. Agile challenges this notion and believes the cost of change can be relatively flat.

Through a combination of modern software engineering practices, and open and honest planning,

Agilsts accept and embrace change even late in delivery process.

Working software is the primary measure of success

The rate at which teams can turn their customer's wishes into working software is how Agilists measure productivity.

Project plans, test plans, and analysis artifacts are all well and good but Agilists understand they

in themselves are of no value to the end customer.

Agile vs Waterfall

Waterfall challenges

Traditional Waterfall treats analysis, design, coding, and testing as discrete phases in a software project.

This worked OK when the cost of change was high. But now that it's low it hurts us in a couple of ways.

Poor quality

First off, when the project starts to run out of time and money, testing is the only phase left.

This means good projects are forced to cut testing short and quality suffers.

Poor visibility

Secondly, because working software isn't produced until the end of the project, you never really know

where you are on a Waterfall project. That last 20% of the project always seems to take 80% of the time.

Too risky

Thirdly you've got schedule risk because you never know if you are going to

make it until the end.

You've got technical risk because you don't actually get to test your design or architecture until late

in the project.

And you've got product risk because don't even know if you are building the right until it's too late to

make any changes.

Can't handle change

And finally, most importantly, it's just not a great way for handling change.

The Agile Approach

Instead of treating these fixed stages Agilists believe these are continuous activities.

By doing them continuously：

Quality improves because testing starts from day one.

Visibility improves because you are 1/2 way through the project when you have built 1/2 the features.

Risk is reduced because you are getting feedback early, and

Customers are happy because they can make changes without paying exorbitant costs.

User Stories

Because life's too short to write everything down

User stories are features our customers might one day like to see in their software.

User stories are like Agile requirements except that they’re not. For one there’s no guarantee all these

features are going to make it into the final version of the software. Secondly, Agilists know their customers

are going to change their mind - and that’s OK. Because they weren’t really requirements to begin with.

They are written on index cards to encourage face-to-face communication.

Words are slippery things. Get a comma wrong and it cancost you a million

dollars. That’s why Agilists love index cards. They make it impossible to write everything down and          instead force you to get off your butt and go talk to your customers about the features they’d like to see in          their software.

Typically no more than a couple days work, they form the basis of our Agile plans.

User stories form the basis of the Agile plan. They are sized and prioritized like any other wish list. You

simply start at the top and work your way down. Nothing big or complex. Just a prioritized todo list and a

desire to get things done.

We get them by sitting down with our customers and asking lots of questions.

Big rooms with lots of white space to draw are great for gathering user stories. In these story gathering

workshops we draw lots of pictures (flowcharts, screens, storyboards, mockups, anything that helps) and break

the functionality down into simple easy to understand words and phrases our customers understand. User

stories!

Clickhereto see a short video on user stories.

Estimation

The fine art of expectation guessing

While we aren’t very good at estimating things absolutely, it turns out we are pretty good at estimating things relatively.

Sizing stories relatively means not worrying aboutexactlyhow big a story is, and worrying more how this story's size        compares to others.

This style of estimation (relative over absolute) forms the corner stone of Agile Planning. By sizing our

stories relatively, and feeding actuals back into our plan, we can make some really accurate predictions

about the future while based on what we've done in the past.

To learn more watch this short video on Agileestimation.

Iterations

Agile's engine for getting things done

An Agile iteration is a short one to two week period where a team takes a couple of their customers most important

user stories and builds them completely as running-tested-software.

This means everything happens during an iteration. Analysis, design, coding, testing. It all happens here.

The beauty of working this way, is every couple weeks the customer gets something of great value (working software),

but it's also a great way to track progress (measuring the rate at which the team can turn user stories into production

ready working software).

Clickherefor a short video on Agile          iteration mechanics.

Planning

The fine art of expectation setting

In its simplest form, agile planning is nothing more than measuring the speed a team can turn user stories

into working, production-ready software and then using that to figure out when they’ll be done.

Our to-do list on an agile project is called the master story

list. It contains a list of all the features our customers would like

to see in their software.

The speed at which we turn user stories into working software

is called the team velocity. It’s what we use for measuring our team’s

productivity and for setting expectations about delivery dates in the

future.

The engine for getting things done is the agile iteration -

one to two week sprints of work where we turn user stories into working,

production-ready software.

To give us a rough idea about delivery dates, we take the

total effort for the project, divide it by our estimated team velocity,

and calculate how many iterations we think we’ll require to deliver our

project. This becomes our project plan.

# iterations = total effort / estimated team velocity

For example:

# iterations = 100 pts / 10 pts per iteration = 10 iterations

Now, as we start delivering, one of two things is going to

happen. We are going to discover that a) we are going faster than

expected or b) we are going slower than we originally thought.

Faster than expected means you and your team are ahead of

schedule. Slower than expected (more the norm) means you have too much

to do and not enough time.

When faced with too much to do, agile teams will do less (kind of like what you and I do when faced with a really busy weekend).          They will keep the most important stories, and drop the least important. This is calledadaptive planningand it’s how Agile teams          work within their budgets and keep their projects real.

Watch this video onestimationto learn more about Agile Planning.

Unit Testing

Unit tests are snippets of test code developers write to prove to themselves that what they are developing actually works.

Think of them as codified requirements.

They are powerful because when combined with acontinuous integration processthey enable us to make changes to our software with confidence.

Refactoring

As we add more functionality to the system we need a way of maintaining our

design and keeping our house in order. In Agile we call this refactoring.

For example, instead of copying and pasting code every every time we need some functionality,

it's much easier to maintain if we extract that code into a one place and call it

from where ever we need it.

Continuous Integration

Continuous integration is about keeping it all together. On a team of more than one,        you are going to have people checking code in all the time. We need a way to make sure that          all the code integrates, all theunit testspass, and a warning if anything goes wrong.

Test Driven Development

Test Driven Development is about writing the test first before adding new functionality to the system.

This seems backwards as first, but doing this:

Defines success up front.

Helps break our design down into little pieces, and

Leaves us with a nice suite of unit tests proving our stuff works.

Agile developers work in this circle of life when adding new code. Write the test first. Make it pass.

Then refactor.