What Is Agile?
Agile proposes alternatives to traditional project management approaches.
Agile is typically used in software development to help businesses respond to unpredictability. In simple words, Agile is a time boxed, iterative approach that builds software incrementally from the start of the project, instead of trying to deliver all at once near the end of a project.
Agile works by breaking projects down into little bits called user stories, prioritising them, and then continuously delivering them in short two week cycles called iterations.
How does it work?
In basic terms, Agile suggests the same thing most of us should do when we have too much to do, and not enough time:
Sit with the customer and make a list of features they would like to see in their software. These are known as user stories and they become the To Do list for the project.
Using Agile estimation techniques, the developer sizes up each story to come up with an estimate as to how long each user story will take.
There always seems to be more to do than time allows. So Agile has the developer and customer work together to prioritise the list so you get the most important stuff done first, and save the least important for last.
Start at the top. Working to the bottom. Building, iterating, and getting feedback from the customer as the project progresses.
Then as the developer and customer start delivering, one of two things is going to happen:
At this point there are two choices. You can either
How is Agile different?
In a nutshell: Analysis, design, coding, and testing are continuous activities. With Agile, analysis, design, coding and testing are never complete or boxed off into separate sections. 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 requirements are going to change, and continuously refining and tweaking the product as the project progresses.
Planning is adaptive
When reality disagrees with their plans, Agilists find it easier to change their plans than reality. This is called this adaptive planning.
And while there are many ways to changes plans, the preferred way is to flex on scope.
Roles really blur on Agile projects. When it’s done right, joining an Agile team is a lot like working in a 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 flexible 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 large software projects.
Requirements can change
Traditionally change is a taboo topic on software projects because of perceived (high) 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 developers can turn customer 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. It’s purely about the end product and it working properly.
What’s Wrong With Traditional Approaches?
There’s no shortage of criticism for traditional management approaches when Developing Large Software Systems, where its recommended to take the path of sequential development. This approach suggests development in the same fashion as we would see on an assembly line, in which each piece is added in sequential phases, each phase dependent on the previous. This phase based approach sees developers first gather all of a project’s requirements, then complete all of its architecture and design, then write all of the code, and so on. It is widely debated these days this creates a lack of communication between the specialised groups that complete each phase of work, and restricts ongoing enhancement, innovation and improvement along the way.
It’s easy to understand the problems with traditional methodologies, as they assume that every requirement of every project can be identified before any design or coding occurs. But… could you tell a team of developers everything that needed to be in a large software product before any of it was up and running? Or would it be easier to describe your vision to the team if you could react to functional software? Many software developers have learned the answer to that question the hard way: At the end of a project, a team might have built the software it was asked to build, but, in the time it took to create, business realities have changed so dramatically that the product is irrelevant, or perhaps the client did not foresee certain features that would be required and can only now understand those being needed once they’ve got a working model to play with.
Agile development provides opportunities to assess the direction throughout the development lifecycle. This is achieved through regular cadences of work, known as iterations (and sometimes sprints), at the end of which teams must present a potentially shippable product increment. By focusing on the repetition of abbreviated work cycles as well as the functional product they yield, agile methodology is described as “iterative” and “incremental.” In traditional approaches, development teams only have one chance to get each aspect of a project right. In an agile, every aspect of development — requirements, design, etc. — is continually revisited. When a team stops and re-evaluates the direction of a project every two weeks, there’s time to steer it in another direction.
This “inspect-and-adapt” approach to development greatly reduces development costs and time to market. Because teams can develop software at the same time they’re gathering requirements, “analysis paralysis” is less likely to impede a team from making progress. And because a team’s work cycle is limited to two weeks, stakeholders have recurring opportunities to calibrate releases for success in the real world. Agile development helps companies build the right product. Instead of committing to market a piece of software that hasn’t been written yet, agile empowers teams to continuously replan their release to optimise its value throughout development, allowing them to be as competitive as possible in the marketplace. Agile development preserves a product’s critical market relevance and ensures a team’s work doesn’t wind up on a shelf, never released.
Is Agile Right For You?
Agile development isn’t right for everyone. There’s times where it wont work or be the best approach, and Newpath WEB recommends you speak to our team before embarking on an Agile approach to confirm the best method to deliver the best outcomes for your needs.