| title | tags | desc | checklist |
|---|---|---|---|
Agile development process |
agile software development process teams evolve self organizing project management |
A quick overview of the agile software development process and the ideas we can apply to school team projects. |
sprint-checklist |
Agile is a fairly popular system for planning software. It can be very strict in following a rigorous rhythm but for our projects we’re going to keep it a little loose and look at only some important aspects with the whole Agile Manifesto.
The major ideas behind the Agile Manifesto are evolution and collaboration. Responding as a team to changing software requirements and allowing different team members to lead in the situations they are best suited for.
-
Early & continuous development — release the software early, getting new features out as soon as they’re ready, constantly updating and maintaining the software.
-
Continuously working with customers — favour communication with customers & clients on a near-daily basis, solve problems together and adapt the project as requirements change.
-
Evolving requirements & welcome to changes — accept that the software requirements are not fixed and will change while development continues, evolve and adapt to the constantly changing requirements.
-
Efficient communication — favour face-to-face communication when possible, especially when brainstorming features and organizing work terms.
-
Self-organization & reflection — teams should self organize, appointing the best to lead and after each work session should reflect on their accomplishments & failures.
-
Simplicity, excellence, sustainable — try to keep the project simple & excellently crafted, but at a rate that is sustainable and continuous, small, well-done changes on a regular basis.
It’s helpful to break your software down into the smallest chunks possible—the smallest features possible. If we break it into smaller manageable chunks we can release those chunks as soon as they’re completed so the software is continuously evolving and improving.
- Plan the software by each of it’s individual features.
- Develop each feature independently if possible.
- Complete reviews & testing (even automated testing) for each feature to confirm compliance.
Slowly build software feature by feature—in small chunks—that can ideally be accomplished by single team members.
Many teams like combing two different practices: Scrum & Kanban together that’s like a best features of both methodologies. We take the organization, deadlines and feature-oriented approach from Scrum and the visualization, backlog approach from Kanban.
One of the major ideas in Scrum is the “Sprint”: a sprint is a chunk of work to be done in a set timeline. After the work is complete we reflect and move to the next Sprint.
Every Sprint teams will follow these steps:
-
Determine a work time frame: many teams like to work on 1 or 2 week time periods for feature completion.
-
Plan the Sprint: together, look at the project backlog of tasks and features, and determine what can/should be done in this Sprint.
-
Assign team members: create the Sprint task list and assign team members to the tasks—usually we want one team member per task and each task should be completable within the Sprint timeframe.
-
Get to work: everybody goes off and does the work, but remains in constant communication; some teams like to have daily meetings to discuss progress.
-
Reflect: after the sprint finishes the whole team reflects on their accomplishments, they check off tasks, and move tasks to other sprints if they became too large to complete.
Kanban is often used as a way to group tasks and watch their progress through to completion. One of the major additions Kanban gives us is the Board: a visualization of backlogs, tasks & sprints.
➔ Tasks move across the Board as they change state—always moving towards done. ➔
A simple Board design to follow has the following groupings:
-
To do: holds a list of all the tasks to be completed, each a small chunk, assigned to a single team member.
-
In progress: shows what tasks are actively being worked on, team members move their task to the in progress column when they start working.
-
In review: holds the almost completed tasks—specifically tasks that team members have deemed complete themselves, but still need to be reviewed by other team members—could be a holding zone until after Sprint reflection.
-
Done: shows all the tasks that were completed for the timeframe—and of course—keeps track of who completed and approved those tasks.
By combining Scrum Sprints with Kanban Boards we essentially have a visualization of everything to be completed in our Sprint’s timeframe within the Board. We can track who is doing what, what’s completed and what hasn’t been started yet.
We can use GitHub as a tool to help organize our Agile development:
- GitHub Projects for Kanban boards
- GitHub Issues for tasks & backlogs
- Milestones for deadlines
- Labels for organization
- Assign talented people to tasks
☛ Explore GitHub for project management in depth