To understand Agile you need to understand where it came from. Building software is hard. You’re building a complex system. Bridges are complex systems, too, but they are regularly completed on time and on budget. So why does software development have a reputation unpredictable and unreliable?
The big reason is this: If you start on a bridge over a river, short of an earthquake, the other bank is still going to be there two years later when you reach it.
But in software and business, two years, even one year, is enough time for the ground to move underneath you. In two years your app might be obsolete or facing dozens of competitors. Or the underlying market has changed, your vision is outdated, and half of the software being built needs to be thrown out, another chunk needs to be updated, and your deadline is suddenly far behind the advancing market and user taste.
You end up chasing change, so busy keeping up that you never reach the finish line.
This is when Agile becomes an advantage.
Agile is not about building software as quickly as possible, it’s about releasing software as quickly as possible.
Agile and the MVP
Agile is where the Minimal Viable Product (MVP) meets Lean Business practices.
Following the MVP philosophy, your product might not be feature complete for years, but when it is developed with the Agile methodology, it will be delivering value to customers within weeks. That value will increase as the Agile team continues to incorporate feedback from users, build new features, and release them to the user base on a regular schedule with a shortened cadence.
Two weeks after launch, the search bar appears. Two weeks later users have a dedicated view of their favourite items and the search bar now has autocomplete.
By structuring development to deliver a new release every few weeks the MVP increases in value to its users, but continues to be an MVP. Because priority is given to value instead of features.
To find that value, Agile relies on User Stories.
What is a User Story?
A User Story is a high level description of what an app or web site needs to do written from the perspective of a user.
The classic format for a user story is “As an X , I want to Y, so that Z“.
Here are examples of two user stories:
“As a first time home buyer, I want to keep track of houses I’m interested in, so that I can buy my dream home.”
“As a real estate investor, I want to know average house prices, so that I can spot a bargain.”
User stories aren’t technical. They are meant to be discussion points between product owners/managers and developers. Separate to the discussion the developers devise a strategy to deliver the features that support the user story within a series of sprints.
What is a sprint?
A sprint is not a period of frantic typing and programming. It’s Agile terminology for the short block of time allocated to implementing features in an app or site.
Sprints tend to be 2 or 3 weeks long. This duration is a compromise between the challenges of software development and the drive to regularly add value to the users’ experience.
If a user story cannot be fulfilled within a single sprint it becomes an Epic. Epics take multiple sprints to complete. The challenge with Epics is maintaining that continuous addition of value to the users at the end of each sprint. It can be done. It just takes planning.
Hold up! Agile is more than User Stories and stand up meetings
“Working software over comprehensive documentation” is one of the four declarations from the original Agile Manifesto. It is not a rejection of documentation. The writers of the manifesto were all experienced programmers. They knew documentation was important.
But they created Agile at a time when the Waterfall Model was the leading methodology. In Waterfall, you plan and document everything up front. As if you were building a bridge and knew where the other side of the river is. And then your team worked methodically, step-by-step, over months and years, to implement the plan, complete the software, and release it to a market that no longer cared.
It was a methodology that sometimes saw projects spend months producing hundreds, even thousands, of pages of documentation before the first line of code was written.
Under Agile, the developers still need to know how the app is going to work, how it is meant to integrate with your business, and how your vision is to be supported.
Business rules still need to be provided, in all their detail. Wireframes need to be drawn and refined. Colours need to be specified.
Developers are in charge of implementation. You need documentation to provide the necessary details about the “what” they are implementing so they can focus on the “how”. It is one of the keys to being Agile.
Agile isn’t the solution to everything
Don’t make the mistake of looking at Agile and thinking it is a way of building software faster than normal. Agile brings responsiveness, not acceleration of software development.
That responsiveness requires experienced developers. Developers not just with a certification in Agile, but also years of experience with the technology and in delivering working software. It took years for the developers at SoftwareSeni to reach the level where they can deliver consistently. Learning Agile was a tiny part of that skill.
Responsiveness might also be what rules Agile out for you. If you’re not building software for a new market, or a market that is continually changing, traditional development models may work better and have a tighter fit with your company’s culture.
Your company’s culture might also be the thing that makes Agile the wrong solution for you. A top-down management style where decisions have to pass through multiple levels of stakeholders for sign-off is the opposite of Agile. Agile is about trusting the developers, trusting the conversations with product managers, and allowing a team to execute with minimal interruption.
If you’re already crafting the email chain in your head for feature sign-off, trying to implement an Agile process will be an exercise in frustration.
The last word on Agile
This article has given you the concepts you need to know when considering adopting an Agile methodology yourself. You hopefully have an insight into whether or not you can (or should) take advantage of it.
If you’re outsourcing your development, an Agile partner like SoftwareSeni can help you decide if Agile is appropriate. We’ll be happy to work with you, help integrate you into your own Agile team of developers, and apply this very effective development strategy to your competitive advantage. Get in touch.
