Since you’re reading this, you may not be up to speed on Agile. Simply put, agile methodology describes a set of principles for software development.
Less simply put, Manifesto for Agile Software Development was published in February 2001 by 17 software developers who held a meeting in Utah. They came up with its principles when discussing “development methods to allow requirements and solutions to evolve through the collaborative effort of self-organizing and cross-functional teams.”
Sounds complicated? Fear not! The good news is agile is just a common sense approach and a very simple concept at the core. There is a reason why the Manifesto’s 12 principles not only still stand strong today, but their application has also extended to a host of other industries. However, before you make the brave foray into Agile yourself, let’s clarify what it actually changes for you as a client or a software house.
What agile means for the client
Client involvement in the project is crucial
Client involvement is vital to the success of an agile project. Regular updates and reporting between the team and clients ensure that their needs are heard regularly and that changes can be implemented earlier than in traditional development.
For client collaboration, planning, tracking, releasing software and reporting we recommend using dedicated all-in-one agile tools like Jira.
Development focuses on the viewpoint of the client (user)
This is usually done with so-called “user stories”, short, simple descriptions of features told from the perspective of the person who is using the product (“As a [user type], I want so that ”).
Clear, exhaustive reporting
In agile client is a god, able to look into every nook and cranny of the development progress. Clients are regularly updated on the development of new features throughout the project. Product backlogs allow them to stay on top of the project (and almost treat it as their own). It allows clients to make accurate forecasts and give very detailed updates to their stakeholders in a timely manner.
Requirements may evolve but the timescale is fixed
In agile development, requirements are expected to evolve, but timescales are fixed. You are welcome to change your mind about the features or even completely re-invent the product during development provided that you pay for the sprint (or iteration).
This principle of agile development is contrary to some more traditional methods of project development, where users are usually told that it’s much more expensive to change or add requirements during implementation, and are severely charged for any alterations in the original concept.
Agile development values “working software over comprehensive documentation”. This requires the client and developer to carefully consider if, how much, and what kind of documentation is actually necessary.
Documentation in agile should fulfil just three criteria, it should be essential (just as detailed as it is absolutely necessary), valuable (when needed) and timely (delivered just-in-time).
A dedicated project team
In agile development, you can expect the team to work almost like your own. Developers are dedicated to your project, report to you regularly and are ready to listen to your every whim. Gooooood.
You get charged every sprint
Bad news… You will normally get billed every 2-4 weeks for a product that’s not even final. This is because agile billing is based on “sprints”. The good news is you always pay for a set of implemented (and working!) features, even though the product may not be ready for launch.
What agile means for the software house
Here is what’s in it for you as a software developer. These rules stem from actual agile principles but are presented in a more digestible form.
Active user involvement is imperative
The rule is equally important for the client and for the software house. User involvement is not only accepted, but encouraged and necessary! From the software house perspective, agile helps you to remember that you are not creating software for yourself, you are always doing it for the client and (more importantly) for the end users of the product (not necessarily your client).
The team must be empowered to make decisions
Agile involves fast decisions. Fast decisions involve good communication. To make scrum projects possible, frequent user (or a representative of the client) collaboration is necessary.
You get paid for every sprint
This is really good news if you are a small software house and do not have the budget to pay your developers up front. In agile development, billing is based on “sprints” (normally 2-4 weeks). Essentially, the client pays for a set of implemented (and working!) features.
Simplicity is essential
Agile requirements are ideally visual and should be barely sufficient, i.e. the absolute minimum required to enable development and testing to proceed with reasonable efficiency. This also applies to documentation. The rationale behind this principle is to minimise the time lost on anything that doesn’t actually form part of the end product or be of any use to the client.
Develop small, incremental releases and iterate
If anyone wanted to explain agile in 3 words, they would probably be “step by step”. Technically it’s just two words because “step” is used two times. The actual agile term for it, is “iteration”.
But what is iteration? Consider this: in more traditional software development projects, the usual lifecycle is: analyse – develop – test. This means that first the budget is set and all requirements for the whole product are gathered. Then, software is developed, and finally, the product is tested before the release.
In agile software development, however, the cycle is a bit different: analyse – develop – test; analyse – develop – test, etc… Iterating for each feature, one feature at a time. Get it?
Working software is delivered within weeks rather than months
Agile development is a concept built all around frequent, not long delivery. Rather than plodding 12-month mammoth projects, agile bases on 3-6 month projects!
Complete each feature before moving on to the next
Simple as that: one at a time. A principle too often misunderstood in software development. The word “done” was abused so much it almost lost its meaning. It doesn’t mean tested, styled, nor accepted by the product owner. It just means developed.
Agile (or Scrum, more specifically) uses a different definition of done. In an ideal situation, each iteration (or “sprint” in Scrum) ends with a release of a “working” feature (although not a final product). The features are added incrementally.
Agile development is a novel but very rational approach. Although it is true that some projects are more fit for agile than others (agile is better suited for projects/industries with aggressive deadlines, unknown scope, and unique products), the methodology can bring plenty benefits when used and interpreted properly in software development.
What does agile mean to you? And what industries other than software development can you think of that are well suited for agile?