Agile Development

Agile methodology is described as “iterative” and “incremental.” Iterative = small reasonable (bite-size!) goals. These manageable goals are known as "Sprints" or "iterations". The team should have a packaged increment (= progress!!!) at the end of each of these.

Agile was born in order to fix the problems of the Waterfall method. Waterfall is a very sequential linear process that has 8 steps: conception, initiation, analysis, design, construction, testing, implementation, and maintenance. The problem is, things are not completed piece by piece and checked.. all of the groundwork and plan is done initially and executed, then tested, then the final product is made. The teams of people working are often separated by their roles, and there is less cooperation. This leaves no room for changes or getting to see pieces of the product. So, there is a good chance the client may terribly dislike what they get at the end, and then there is nothing much to be done except scrap the project and start completely over-- which leads to a higher cost and time than if something else, such as Agile, were used.

An Agile team involves a mix of all the people involved: business analysts, developers, testers, and input from the client! The team will make a plan for their sprint on what they want to accomplish. There is a burndown where teams assign story points to their tasks.. this should not be solid numbers that can be compared to one another because this sets unrealistic deadlines on the team (and Agile is built to prevent this!). To help mitigate the issue, often the story points will count up in intervals without an easily definable pattern. Some companies uses Fibonacci series or T-shirt sizes to make the sizes somewhat of an eyeball measurement, but not something that can have a definition and date slapped onto easily. If it was 1, 2, 3, 4, 5, 6.. well you would expect 6 to take 6x as long as 1 and 3x as long as 2. If its Fibonacci or T-shirt sizes.. while you can do some fractions or exact calculations.. it is meant to just show if its "big", "huge big gigantic", or a "small-ish" task.

This team works on their Sprints/Iterations for a certain interval.. this could for example be something like 2-4 weeks. Each member takes a piece, works on it with the other members so that it is developed, tested, and shown to client for input. Afterwards, the team will debrief and decide what worked/didn't work depending on how far beyond/behind they were of their goals. All in all, this gets software out quicker because things are checked along the way and the client is aware of the progress and how it looks. Changes can be made, and as we know.. software is about change! There are always new things coming out and interfaces/OOD is there for implementing these new ways for the software to work.