Building software is hard. It’s been true since the first programmer flicked the first switch on a computer the size of a boardroom.
Like software, roads and bridges are complex systems and they are regularly completed on time and on budget. But software and its development has continuously resisted being predictable and reliable.
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 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 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.
So it goes – 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 XXXX , I want to YYYY, so that ZZZZ “.
Examples of 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. Out of the discussion the developers devise a strategy to deliver the features that support the user story within a sprint.
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 implement 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 continually 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.
Hold up! Agile is more than User Stories and chit-chat
“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 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 a miraculous acceleration of software development.
That responsiveness requires experienced developers. Developers not just with a certification in Agile, but 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 looking to out-source your development or bring on a team extension, an Agile partner like SoftwareSeni can help you decide if this methodology 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.
The 12 principles of Agile to keep in mind as you build your dream product.
- Satisfy the Customer
- Welcome Change
- Deliver Frequently
- Work Together
- Build Projects
- Face-To-Face Time
- Measure of Progress
- Sustainable Development
- Continuous Attention
- Keep It Simple
- Organised Teams
- Reflect for Effectiveness