I know this topic seems like a departure from our typical subject material—because it is. I’m writing this because GOLDPoint Systems has begun the process of transitioning not just our development teams, but our entire organization to Agile. If that doesn’t make any sense, it’s ok, it will. When I first heard about our migration to Agile, I barely had an idea what that meant. Since then, I’ve learned a lot about Agile from people much smarter than I.
There’s an uneasy consensus on what the definition of Agile is. After hours of research, the best I could come up with is that Agile is made up of certain protocols and methods that are based on a solid set of values and principles. Think of it as a philosophy, rather than a methodology or framework. Implementing Agile within an organization usually necessitates some serious and/or complete cultural change. One does not simply “turn Agile,” as it takes much more to change how you think, instead of how you do things. It’s a complete transformational change.
Agile works best with large, complex projects that require new changes to be continuously implemented throughout the development cycle. With Agile, you cut large projects into smaller ones, making it easier to focus on completing each task. These smaller projects are called sprints. Regular testing and frequent milestones that happen with sprints make projects more manageable and boost team morale. Breaking up bigger projects into a series of smaller ones facilitates risk reduction, quick feedback from users and increased speed to market. Agile teams are more flexible, adapt quickly to change and ship quality work faster and more often.
If you’re a rugby fan, you’ll already know what a scrum is. A Scrum with an Agile development team isn’t much different. Grouping together as a team to start the next play works whether you’re on the pitch or in an office. A Scrum framework in an Agile project is a regular team meeting that facilitates organization, iteration and continuous improvement. It encourages completing work and continuously shipping value to customers. Scrum is used as a tool to develop, deliver and sustain complicated projects. Despite the popular belief that Agile and Scrum are different names for the same thing, it’s not the case. The collaborative nature of Agile, along with the transparency and framework of Scrum, help overcome many common problems that teams experience with other projects.
Using a framework like Scrum can help you think in a more Agile way. Scrum can make it easier for you to integrate Agile principles into your work. Scrum works with all types of teams: marketing, design and HR, but software development teams seem to work especially well with it. If your projects are constantly changing, requirements and goals all need to pivot and change with it. Scrum embraces the change.
Scrum embodies continuous learning and adaptation. Scrum accounts for the fact that teams rarely (if ever) know everything at the start of a project. When a team begins a project, they usually have a list of features, requirements, enhancements and fixes to work on. This list is called the product backlog. It’s a to-do list that’s constantly evolving and being updated. The team will meet periodically to plan which of the tasks from the backlog they’ll work on during the next sprint. Sprints are usually a couple weeks long, but you decide what works best for your team. During the sprint, team members will consistently participate in a few rituals, or ceremonies. These rituals are the load-bearing pillars of the Scrum framework.
In future articles I’ll go further in depth about the four Scrum rituals: Sprint Planning, Daily Scrum/Standup, Sprint Reviews and Sprint Retrospectives.