Agile Development

Agile development allows us to be 'agile' in how we design, build, and test our robot. It helps us to plan what we need to do, who is going to do it, and about how long it will take to do it. Agile allows us to accomplish more and be organized as a team.

Below is a brief explanation of the inner workings of our system. Not pictured below is the 'epic' tier.

Agile Development Explanation.png

Epic

Epics are season-long goals that define everything we want to do in a year.  For example some of our current epics include “Everyone has something to show at end of year” and “Weld & CAD robot”.  Epics serve as guideposts for your season. The team should be working on achieving the Epics at all times and if there is a project they are spending significant time on that is not an Epic, it should be either scrapped or added to the Epics.

 Story

A story can mean different things to different people. The way that #3409 uses it is to group tasks in a sprint together under a theme. For example, in one sprint where we wanted to focus on completing our robot M1ttens we named the sprint “Once the Mittens go on, they never come off,” and this was our story for the sprint.

Task

A task is one of the short-term goals your team plans to complete over the course of one sprint. For example, some goals you may have would be “finish physical robot,” “fix Autonomous problems,” or “write Team Section in Notebook.” If a task is not finished in time, the team can push it to the next sprint or drop it entirely.

Spike

If you need to experiment or take some time strictly to learn, this is where a spike comes in handy. Similar to a task, a spike is completed during a sprint. However, unlike a task there is no concrete end goal and the end result is always scrapped. For example a spike might consist of “figure out how color sensors work” or “prototype arm designs.”

Sprint Planning

This is a meeting where the team comes together to decide what they will be doing for the next sprint. They write all the tasks that they want to complete over the course of the sprint, usually taking ideas from the retrospective and review into account.

Scrum

This is a daily meeting wherein the team updates one another on their progress. This is so that no sub-team gets lost and forgets about the big picture. For example, if someone working on an arm mentions they’ve moved it to a new spot on the robot, the person working on the phone mount now knows they can’t put it there. This isn’t the only time the team works together, but it helps keep everyone in sync.

Sprint Review

This is the time to go down the list of sprint tasks and demo everything there. Even if the task is not finished, the people who worked on it show off what they have and talk about their proposal for finishing it.

Sprint Retrospective

Just after the sprint review, the team comes together to talk about what they did well, and what they did poorly in the previous sprint. For example, the team may decide that they did well in documenting their work but did poorly in communicating with one another. They then will talk about how they will work to be less affected by the bad things - for example, the team may decide that they need to share more in scrum or update one another in GroupMe more often. 

Thus, a single cycle might look something like this:

  1. Meeting 1

    1. Sprint Planning

    2. Work on tasks & spikes

  2. Meeting 2-? (on our team, this is meeting 2 & 3)

    1. Scrum

    2. Work on tasks & spikes

  3. Meeting 4

    1. Scrum

    2. Work on tasks & spikes

    3. Sprint Review

    4. Sprint Retrospective

Though this page describes Agile Development as we, the Astromechs, use it, its main feature is that it is inherently flexible. Anything can be adjusted. For example, on our team we use Stories in a very different way than most people do because it is what works for us. We ignore a lot of minutae of our original use of Agile, such as Story Points. We have switched to a paper-only tracking system instead of the online system we used to use. If you stick rigidly to Agile when it’s not working, you’ve missed the point of Agile!