Agile Development
Agile is an approach to project management that centers around incremental and iterative steps to completing projects. The incremental parts of a project are carried out in short-term development cycles. Agile software development is an umbrella term for a set of frameworks and practices based on the values and principles expressed in the Manifesto for Agile Software Development and the 12 Principles behind it. When you approach software development in a particular manner, it’s generally good to live by these values and principles and use them to help figure out the right things to do given your particular context.
One thing that separates Agile from other approaches to software development is the focus on the people doing the work and how they work together. Solutions evolve through collaboration between self-organizing cross-functional teams utilizing the appropriate practices for their context.
There’s a big focus in the Agile software development community on collaboration and the self-organizing team. That doesn’t mean that there aren’t managers. It means that teams have the ability to figure out how they’re going to approach things on their own.
It means that those teams are cross-functional. Those teams don’t have to have specific roles involved so much as that when you get the team together, you make sure that you have all the right skill sets on the team.
There still is a place for managers. Managers make sure team members have, or obtain, the right skill sets. Managers provide the environment that allows the team to be successful. Managers mostly step back and let their team figure out how they are going to deliver products, but they step in when the teams try but are unable to resolve issues.
When most teams and organizations start doing Agile development, they focus on the practices that help with collaboration and organizing the work, which is great. However, another key set of practices that are not as frequently followed but should be are specific technical practices that directly deal with developing software in a way that helps your team deal with uncertainty. Those technical practices are essential and something you shouldn’t overlook.
Note in the AGILE image below, that design, develop, test, deploy, and review are happening repeatedly in a cycle after planning and until launch, rather than all one time one after the other, as it does in traditional project planning styles. By working in small iterations and constantly accepting feedback and reviewing the needs of the end user, Agile teams remain adaptable and responsive to changing needs.
AGILE
Scrum
Scrum is an agile project management framework that helps teams structure and manage their work through a set of values, principles, and practices. Much like a rugby team (where it gets its name) training for the big game, scrum encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve.
The Scrum Roles
Product Owner
The product owner represents the stakeholders, e.g, the players/end users, investors, etc. It’s their job to make sure the software is valuable to the people who will use it. They will meet with these stakeholders or gather information in other ways (esp if there are too many end users to meet with, like in game development), such as deploying surveys or play-test sessions. Using this information, the product owner will prioritize items in the product backlog, a list of tasks/items for the scrum team to work on.
Scrum Master
As the title implies, the scrum master is the master of scrum, who ensures the scrum framework is followed. Scrum has a clearly defined set of roles and rituals that should be followed and the scrum master works with each member of the scrum team to guide and coach the team through the scrum framework. Polls show that only about 8% of teams follow scrum precisely, so it’s rare that everything will just happen the way this scrum guide will lay out. It’s up to the team and the scrum master to try to figure out what works best for the team, and the scrum master will help them follow that implementation and adjust it as needed.
Scrum Team
The scrum team is the team of developers that will work on a product. The entire development team doesn’t have to be on one scrum team; usually each scrum team is 3-9 developers working together on the same aspect of the product. If there are multiple teams, it’s usually best to have multiple scrum masters and have the teams have their daily standups separately.
The Scrum Artifacts
There are three “objects” that the scrum team deals with. These items help generate the final product. These are called the artifacts.
The Product Backlog
The product backlog is a list of items the product needs to be valuable or useful to the customer. The items in the backlog can be added by anyone, but they are only prioritized by the Product Owner. These items are typically written in a format called user stories.
User stories are written from the viewpoint of a user, not usually a developer, although they sometimes can be if some form of development task needs to be added to the backlog for visualization purposes, such as technical debt. A user story may look like the following:
Example: An MMORPG user story
As a player, I want to be able to see what my target’s target is so I know what they’re doing.
The story should be written in a format similar to this: As a <role> I want <capability>, so that <receive benefit>. We want these stories to tell us what the user wants and why, so we can understand what we’re building. We don’t want the stories to be too technical or explain how the feature should be built; that’s up to the team to decide when they start working on the feature.
Example: A badly-written MMORPG user story
As a developer, I want the player’s target to pass their target’s class by reference to the player so we can populate a UI item on their screen to show them what their target is targetting.
This is from the dev’s point of view so we don’t get an idea in the user story if this is valuable to the player and may be difficult for the product owner to explain to an end user and therefore prioritize. The technical information is also unnecessary as it can be fleshed out in the sprint backlog when it’s ready to be worked on. SCRUM | SCRUM ROLES
The Sprint Backlog
The sprint backlog is a subset of the product backlog. This log is created at the beginning of each sprint during a meeting called the sprint planning meeting. This contains the upcoming sprint’s to-do list. The scrum team will use the sprint backlog to pull their tasks from during the sprint and to see how many items of work they have left. These items may show effort estimations or other metrics as well as the person that decided to work on the task. Sometimes, teams won’t have their members assign one person a task as this may inhibit cooperative development on that task. The sprint backlog will be updated throughout the sprint and should be much more detailed about each task than the product backlog will be, as the sprint backlog is for the scrum team rather than the stakeholders.
The Increment
At the end of the sprint, ideally there will be some usable software or demonstrable progress made on the software. This is called the increment. At the end of every sprint, if your team decides on doing a demo for each sprint, this will be shown to the product owner and sometimes stakeholders to show what’s been done and receive feedback. Without the increment, the customers can’t see if they like what we’re doing so far. This is why such emphasis is put on creating usable software by the end of the sprint.
The Scrum Events
There are five events in the standard Scrum framework. These happen each cycle, or sprint. Each event has different participants and a different purpose.
The Sprint
The sprint is an interval of planning, working, and analysis. These typically last the same amount of time every time. Within each sprint, the other four scrum events occur.
Sprint Planning
During the sprint planning meeting, work is selected from the product backlog. The scrum team, the scrum master, and the product owner are all involved in this meeting. Stakeholders and necessary consultants may attend as well.
Daily Scrum / Standup
Every day (ideally), there should be what are called daily scrums, often called standups as they should be short enough where sitting isn’t necessary (sometimes standing can encourage people to be quick as well).
Sprint Review
Sprint Retrospective
In this final meeting, the SCRUM | SCRUM EVENTS