All About Agile!!

What is Agile?
In traditional software development methodologies like Waterfall model, a project can take several months or years to complete and the customer may not get to see the end product until the completion of the project.

A non-Agile projects allocate extensive periods of time for Requirements gathering, design, development, testing and UAT, before finally deploying the project.

In contrast to this, Agile projects have Sprints or iterations which are shorter in duration (Sprints/iterations can vary from 2 weeks to 2 months) during which pre-determined features are developed and delivered. 

We can say that, Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project (incremental delivery), instead of trying to deliver it all at once near the end.

What is User Story?
User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

User stories are often written on index cards or sticky notes, stored in a shoe box, and arranged on walls or tables to facilitate planning and discussion. As such, they strongly shift the focus from writing about features to discussing them. In fact, these discussions are more important than whatever text is written.

In short, user stories are very slim and high-level requirements artifacts.

What is Iterations?
In the Agile methodology, each project is broken up into several ‘Iterations’.

An Agile iteration is a short 1-2 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. At the end of each iteration, a working product should be delivered.

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).

What is a Sprint?
A Sprint is the basic unit of development in Agile Scrum development. It is a set period of time during which specific work has to be completed and made ready for review. A typical sprint lasts about 3-4 weeks.

Each sprint begins with a planning meeting. During the meeting, the product owner (the person requesting the work) and the development team agree upon exactly what work will be accomplished during the sprint. The development team has the final say when it comes to determining how much work can realistically be accomplished during the sprint, and the product owner has the final say on what criteria need to be met for the work to be approved and accepted.

What is a Test-Driven Development (TDD) ?
It is also called test-driven design, it's a development methodology whereby the developer writes a unit test as a starting point and then writes code that will allow the test to pass. The development of the entire system proceeds one test at a time.

Test-driven development can produce applications of high quality in less time than is possible with older methods.

What is an Epic?
Epics are significantly larger bodies of work. Epics are feature-level work that encompasses many user stories. Epics generally take more than one or two sprints to develop and test.

Burndown Charts
The burndown is a chart that shows how quickly you and your team are burning through your customer's user stories. It shows the total effort against the amount of work we deliver each iteration. Burndowns are great because they:
a). Make the reality of the project clear.
b). Show the impact of decisions.
c). Warn you early if things aren't going according to plan.
d). Get rid of all the wishful thinking around dates.

How does Agile work?
Agile works by breaking projects down into little bits of user functionality called user stories, prioritizing them, and then continuously delivering them in short two week cycles called iterations.
a). 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 things user stories and they become the To Do list for your project.
b). Size Things Up: Next step is using Agile estimation techniques, you size your stories relatively to each other, coming up with a guess as to how long you think each user story will take.
c). Set 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.
d). 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.
e). Update The Plan: Then as you and your customer starting delivering one of two things is going to happen. You'll discover either you're going fast enough or you have too much to do and not enough time. At this point you have two choices. You can either: do less and cut scope (recommended) OR you can push out the date and ask for more money.

How is Agile different?
a). Analysis, design, coding, and testing are continuous activities. So long as there are features to build, and the means to deliver them, these activities continue for the duration of the project.
b). Development is iterative 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.
c). When reality disagrees with their plans, Agilists find it easier to change their plans than reality. They call this adaptive planning.
d). 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.
f). 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 burn out, drama, and dysfunction traditionally associated with our industry.
g). 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.
h). 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
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.
a). 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.
b). 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.
c). 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.
d).  And finally, MOST importantly, it's just not a great way for handling change.
f).  Analysis, Design, Code, Test..instead of treating these fixed stages Agilists believe these are continuous activities. By doing them continuously:
f1). Quality improves because testing starts from day one.
f2). Visibility improves because you are 1/2 way through the project when you have built 1/2 the features.
f3). Risk is reduced because you are getting feedback early, and
f4). Customers are happy because they can make changes without paying exorbitant costs.

-K Himaanshu Shuklaa..