Agile is a word that has many connotations outside of the tech industry, but in software development it only invokes one thing, the Agile Manifesto. Written in February of 2001 by seventeen independent-minded software practitioners, it describes a set of values (4) and principles (12) that generally promote a project management process encouraging frequent inspection and adaptation; a leadership philosophy focused on cross-functional teamwork, self-organization and accountability; a set of engineering best practices intended to allow for rapid delivery of high-quality software; and a business approach that aligns development with customer needs and company goals.
As an umbrella term, Agile Development also serves to describe a set of software development methodologies that subscribe to the above notions. The most popular agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean Development, and Feature-Driven Development (FDD). While each of them unique in their approach to fulfilling the promise of Agile Development, they all share the core values and principles of the Agile Manifesto. They all emphasize continuous planning, iteration, testing, and other forms of continuous evolution of software and project (even at later stages of development). They are all lightweight, especially compared to traditional waterfall-style processes, and inherently adaptable. Most importantly, they all focus on teamwork, collaboration and making decisions together.
Out of the known agile methodologies available, here at Megsoft we employ Scrum.
Scrum, first and foremost, relies on a self-organizing, cross-functional team. By “self-organizing” we mean there is no overall team leader deciding which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole. The other part of that is cross-functionality, meaning, everyone is encouraged to take a feature from idea to implementation.
It may sound chaotic from an outsider’s point of view, but a team working in a Scrum environment is not without direction. Scrum teams are supported by two specific roles that help anchor the workflow into the most important tasks at any given development phase, and facilitate conditions that allow for a very efficient environment. The latter is the role of the ScrumMaster, who can be thought of as a coach for the team, helping team members use the Scrum process to work at peak performance levels. Ensuring the team adheres to Scrum theory, practices, and rules is where the “mastery” part of it comes into play.
The second role belongs to the Product Owner (PO), representing the business, customers or users for whom a solution is being provided– usually one person that serves as the spokesman for the customer.The Product Owner conveys the overall mission and vision of the product the team is building, and it is ultimately responsible for for prioritizing the backlog during Scrum development. This is of utmost importance, as it ensures the team always works on the most valuable features first and the backlog is kept up to speed as more is learned about the system being built, its users, the team and so on.
As far as the overall structure of a Scrum environment goes, the single most distinctive feature is the implementation of Sprints to measure progress. In keeping with an agile methodology, sprints are constrained to periods of less than a month in duration, most commonly two weeks. There is a planning meeting at the start of the sprint (“Sprint planning” comes from this), where team members figure out how many items they can commit to, and then create a sprint backlog – a list of the tasks to perform during the sprint.
During an agile Scrum sprint, the Scrum team takes a small set of features from idea to coded and tested functionality. At the end, these features are completed, meaning coded, tested and integrated into the evolving product or system.
At the core of things, this represents one of the biggest values we offer to our customers. Sprints allow us to continuously deliver results in a relatively short amount of time, ensuring there is always progress being made and that projects never stall. The transparency and continuous delivery this enables is beneficial to both the customer, who is always in the loop of every step of the process, and the team, which remains motivated throughout the project thanks to the many short-term milestones the sprints represent (great for team morale!).
The product backlog is another artifact of Scrum. Mentioned before as the main responsibility of the Product Owner, this is the complete list of the functionality that remains to be added to the product. Not to be confused with the sprint backlog. The sprint backlog can be thought of as the team’s to-do list for the sprint, whereas a product backlog is a list of features to be built.
The way that has brought us the most success to create a product backlog is through the employment of User Stories. These are short descriptions of functionality described from the perspective of a user or customer. This is especially effective at contextualizing every decision we make through the eyes of the target audience, helping us determine the features users will value the most.
Lastly, we wouldn’t want to overlook the possibility of things going wrong, or areas of improvement to be left ignored. That’s why at the end of every sprint, we hold a sprint retrospective to review what did and didn’t go well with actions to make the next sprint better.
Over the course of 20+ years of experience in the industry we have tried many methodologies, all with their pros and cons, but Agile Development—and Scrum in particular—stand a cut above the rest. Not only has it been the one to bring us the most success, it is also the one that makes our workplace an environment where our team can thrive with plenty of room to grow. With the best teams working with the best process to bring you the best value, we feel confident saying no matter your hurdle, we got your back.