Most of the time we never pay much attention to how something is made. Sure, we might wonder if it’s recyclable or BPA free. Maybe we dig a bit deeper and find out if it was made in an environmentally-friendly manner, or the workers were paid a fair wage.
But how often do you think about how software you subscribe to is developed? If you aren’t a developer or have your finger on the pulse of the software industry, then chances are you’re probably thinking, ‘who cares?’
The truth of the matter is when we subscribe to software it ABSOLUTELY matters how it’s developed. After all, when you subscribe to a SaaS product (software-as-a-service) we generally assume it’s going to continually evolve and improve over time. The real question is, how rapidly will it improve and what is the likelihood that those changes are going to have a significant impact on how it improves our usage of the product?
An Introduction to Agile Methodology
The traditional definition of agile is “the ability to move quickly and easily.” That is essentially how it relates to software development as well. The Agile Methodology “promotes adaptive planning, evolutionary development, early delivers, continuous improvement, and encourages rapid and flexible response to change.” This is accomplished by the division of tasks into short phases of work known as “sprints” and frequent reassessment and adaptation of plans.
The Agile Manifesto emphasizes:
The main guiding principle behind the Agile Manifesto is “…to satisfy the customer through early and continuous delivery of valuable software.” The key phrases here being early and continuous.
In the Agile Methodology tasks are broken down into much smaller pieces that can go through discovery, design, development and testing in short time frames usually between two and three weeks. This allows for each cycle or “sprint” to be extremely focused in nature and puts new features in front of end users for testing and feedback much quicker. The user feedback can then be used to make immediate adjustments to the software and quite possibly change the direction of the next feature release.
Why Should You Care?
Agile relies heavily on customer feedback and involvement on a continuous basis which ensures that the new releases of the product match the needs and desires of current and potential customers. With the traditional Waterfall development approach, there is limited visibility into new releases until the release is complete.
The Agile process can have the same risks associated with Waterfall methodology, but they happen much quicker and at much smaller scale so adjustments can be made along the way. We often don’t know what we don’t know. Sometimes we need the feedback from how users might interact with a certain feature of the product before we can find the best way to build out another area of the product that might rely on certain dependencies previously built out.
By performing small iterations and reviewing with customers or stakeholders more frequently, it puts new features in front of users quickly, to validate the purpose and effectiveness of those features before extensive development time is devoted to what might amount to poorly adopted features. This allows development teams to prioritize time spent on the most useful and potentially more widely adopted features that will resonate with users and have the biggest overall impact on the product at large.
According to internal benchmarks at PricewaterhouseCoopers, Agile Development teams release about 20% more often than competitors using other development processes such as Waterfall.
Kyle Burnett, CTO for Allbound, recommends bringing some of the key principles of the Agile methodology into your own planning. “All clients have a wish list. Break that list out into what is best for your user now, and what can be best for your users later. You, like us, have a solid assumption of your users’ needs, but will not know until you try. So be agile in your own approach, implementation and growth.”
When you choose a software platform it is important to take into consideration not only the benefits of that platform today but the potential future benefits that software may provide. While Agile certainly isn’t the only methodology for building software, if you value the frequent delivery of software releases based on on-going user input and testing, then it just might be a valuable consideration when choosing a potential software platform.
At Allbound we embrace the Agile methodology for all of the reasons outlined above. We see ourselves more as partners with our clients than we do as a vendor.