PROCESS (Incomplete)

Latitude 40 employs a development methodology referred to as “Agile Development”. This is quite different from the traditional “Waterfall” approach which treats analysis, design, coding, etc. as separate phases to be performed sequentially.

Once you get through one phase, you move on to the next and there is no turning back. This just doesn’t work well for today’s projects that demand more agility in the process. By the time you get through the analysis and design phases and start on development, requirements have often changed. There’s just no good way to incorporate those changes into the Waterfall model. The project must be continued without change, and the final result isn’t what is really needed or wanted. So you get to work on a second release to fix everything that isn’t right, again starting at the first phase. This isn't efficient because the initial release for a large project may take years to develop. How much of that time was a waste?

Agile Development runs through those phases in 1-4 week cycles (called “sprints”) for a very limited set of functionality at a time, with the most important functionality first.

The goal of a sprint is to develop all the planned functionality to completion so it can be delivered in working form for the customer to use and provide feedback on right away. That important feedback might result in changes that can be developed as part of the next sprint, or a subsequent one if the priority for those changes aren't high.

During this process, if your needs change for any functionality that hasn't been built yet, then the change has absolutely no impact. If your needs change for something that HAS already developed, then you just add that change into the pipeline and it will be addressed based on the priority you assign.

Traditional Waterfall

VS

Agile Development

At the Symposium on advanced programming methods for digital computers in Washington, D.C. on June 29, 1956, Dr. Herbert D. Benington presented the first known description for what became known as the "Traditional" or "Waterfall" model for software development. This model became the standard for software development for more than 40 years.

Must have perfect and clear requirements, plans and expectations prior to beginning development
Requires the completion of each phase before moving on to the next
Once a phase is complete, you can't go backwards or make changes
The most important decisions about the project are made up front when you rarely have perfect knowledge
That's why it is often stated that the beginning of the project is the dumbest day of the rest of the project

Unfortunately, there aren't a lot of real world scenarios that fall into this category.

In February of 2001, a group of 17 software developers met in Utah at the Snowbird Resort to uncover better software development methods, as well as, help others along the way. This meeting gave way to The Agile Development Methodology and The Agile Manifesto was published shortly afterwards.

Do not need perfect requirements at the beginning of the project
Software is developed in a 1-4 week iteration called a 'Sprint'
Each Sprint allows for the refinement and re-prioritization of the project requirements
Working, tested code is delivered at the end of each Sprint
Allows for changes and corrections to be made as the software is being developed
You often need to see the wrong product to know what you really want

Fortunately, the majority of real world scenarios fall into this category.

How Agile Works

Product Backlog

The Agile process begins by identifying all features and functions for the desired product. These items are filtered into a Product Backlog that is prioritized by the Product Owner who facilitates the manipulation of the Product Backlog

Sprint Planning

Once the Product Backlog has been prioritized, the team decides on which features and functions they will work on over the 2 week period called a Sprint. They will estimate out how long each item (called a Story) will take to develop and plan accordingly.

The Sprint

Now that the team has decided on what features will be developed during the first Sprint, the development process can begin. The code is developed and tested for each feature within the Sprint. At the end of the Sprint, all completed features will be delivered to the customer to be further tested and verified. Allowing the opportunity to suggest changes and/or new features based on the delivery.

Sprint Review/Backlog Refinement

Delivery of all completed features that are verified and accepted by the customer leads to a review of the Sprint. It also allows for the refinement and re-prioritization of the Product Backlog.

And that's how it works. With the Backlog Refinement completed, the process begins again with another Sprint Planning, then the Sprint, the Sprint Review, and you guessed it, Backlog Refinement.

By utilizing the Agile Software Development Methodology, projects are typically more productive, faster to market, have fewer defects and produce happier customers. But don't take our word for it, check out the Harvard Business Review Analytic Service Report.