Advice For Agile/Scrum Robot Development

[Sid323]

As a returning member of a team which is made up of many students new to FRC this year, I had a few questions about how my team could approach the build season.

This year, we are planning on using portions of the Agile/Scrum development process, which I have limited experience with, but most of the members have never heard of it before. Has anyone used this method before, and what advice would you have for a team new to it? I searched for this on CD before, but the answers weren't very clear (most of them suggested that Agile doesn't work that well for FRC on the whole).

Also, considering that our approximately 35 member team is over 50% rookie, do you have any advice for how to approach a situation in which most of the team has never built a robot before? We do have more than a few experienced members and mentors returning, but our team is currently going through a transformation period.

[tsetse fly]

What portions of the Agile/Scrum development process are you looking at implementing ? We have experimented with Agile and the way the team works before, but have not had a great deal of commitment on everyone's part to keep to a defined process. We have had students take the lead on some of these processes and manage the team. Maybe avoid the sprints and estimation focus of Agile. You could work with the product owner concept (assign someone who has the vision for the robot design). Here are a few Agile concepts you could focus on.

1) Daily Stand Up has advantages in that all the students (and mentors) are aware of what is being worked on and who needs help.
- These are short (set a time limit of 10-15 min)
- Team members are talking to each other on what they have done
- Allows for others to volunteer to help out those that are having issues
- NOT design discussions which risks keeping this short
- These are short (set a time limit of 10-15 min)

2) Make the work visible
You can use a physical board with sticky notes with categories such as Backlog, Work in Progress, Blocked, Completed (work off this in your daily stand up)
You can duplicate that board with an electronic version for viewing outside the working sessions / remotely.
By making the work visible you allow people keep the status of the work up to date, the team has awareness of what others are working on they might not otherwise have visibility to and allows those who have an interest in an on-going task to offer to help out.

3) Continuous Improvement
Meet once a week to discuss what is working and what is not working as far as your robot design and development "process" (not the robot design itself, but the way your team is working). These are called retrospectives and there are hundreds of different games and tools that you can use to have some fun and improve the way the team works. Get feedback from everyone. Define an action plan to change the way the team works to improve and become more efficient.
http://www.plans-for-retrospectives.com

Some tools:
JIRA is an Agile tool we have used in the past, Atlassian provides a free license for community/non-profit orgs.
https://www.atlassian.com/software/jira
Something a little more simple and Kanban focused you could use would be Trello
https://trello.com/

[jds2001]

See this thread, starting at the post that I've linked (and maybe some above) for my thoughts on the topic.

TL;DR - I don't think full-on agile is appropriate for a FRC project. It's quite well suited when there are distinct iterations that you can "deliver". Another poster in that thread made the point that the requirements change very little once they're delivered (in 12 days now, can you believe it?!?!)

[alecmuller]

Agile was made for software development, but most of the 12 points translate pretty well for robotics.

The biggest challenge is estimating what level of design complexity your team can squeeze into each system integration cycle (i.e. combining the software, the electrical hardware, and the mechanical hardware, then testing and debugging them as a system).

At a minimum you want to be able to do one design iteration (with time for testing!) in the 45-day build season, but I'd argue it's not really Agile with 1 iteration. Ideally you'd shoot for 2 or 3 design iterations in that time. The key is keeping the design simple enough that your team can execute it (design, fab, assemble, test) in 2 weeks, but still sophisticated enough to play the game. Off-the-shelf components go a long way toward keeping it simple.

My team (~40-50 students last year, nearly 50% of them 1st-year) did a good job of keeping it simple last year. We had a robot that drove - and only drove - by day 4 (it really helps to have old robots you can take apart & rebuild), a wood/metal robot that could drive and lift totes by day 17, and our real competition robot started testing on day 31. [We did the driving-only robot because it was our first time with mecanum - this year we'll probably skip that iteration unless we think we really need a weird new drivetrain.]

It's also worth noting that building a 2nd robot helps A LOT. Last year was our first year doing this, and we saw a number of benefits: Less down-time during the build season because software & mechanical weren't competing for time with the same robot (as much). More student engagement in fabrication and assembly. More driver practice with a clone of the competition bot. We think the marginal cost for the 2nd robot was about $2k - nothing to sneeze at for a team with a tight budget, but still small compared to entry fees.

[Sid323]

Originally Posted by tsetse fly

What portions of the Agile/Scrum development process are you looking at implementing ? We have experimented with Agile and the way the team works before, but have not had a great deal of commitment on everyone's part to keep to a defined process. We have had students take the lead on some of these processes and manage the team. Maybe avoid the sprints and estimation focus of Agile. You could work with the product owner concept (assign someone who has the vision for the robot design). Here are a few Agile concepts you could focus on.

1) Daily Stand Up has advantages in that all the students (and mentors) are aware of what is being worked on and who needs help.
- These are short (set a time limit of 10-15 min)
- Team members are talking to each other on what they have done
- Allows for others to volunteer to help out those that are having issues
- NOT design discussions which risks keeping this short
- These are short (set a time limit of 10-15 min)

2) Make the work visible
You can use a physical board with sticky notes with categories such as Backlog, Work in Progress, Blocked, Completed (work off this in your daily stand up)
You can duplicate that board with an electronic version for viewing outside the working sessions / remotely.
By making the work visible you allow people keep the status of the work up to date, the team has awareness of what others are working on they might not otherwise have visibility to and allows those who have an interest in an on-going task to offer to help out.

3) Continuous Improvement
Meet once a week to discuss what is working and what is not working as far as your robot design and development "process" (not the robot design itself, but the way your team is working). These are called retrospectives and there are hundreds of different games and tools that you can use to have some fun and improve the way the team works. Get feedback from everyone. Define an action plan to change the way the team works to improve and become more efficient.
http://www.plans-for-retrospectives.com

Some tools:
JIRA is an Agile tool we have used in the past, Atlassian provides a free license for community/non-profit orgs.
https://www.atlassian.com/software/jira
Something a little more simple and Kanban focused you could use would be Trello
https://trello.com/

Some of the aspects that we were planning on using include the sprint time management approach in which small groups set a short timeline in which to complete a small project, a task-based project management system (I had suggested Trello), and rapid iterations of basic existing systems. I really like your suggestions on retrospectives and the stand-ups, especially due to their focus on communication between sub-teams.

However, I'm not sure why you advised against sprints. Our team is currently in a situation where we won't have any flexibility beyond our scheduled meeting times due to non-cooperation from the school administration, and our president thought that sprints would be a great way to keep students focused on their short term project goals.

[Sid323]

Originally Posted by jds2001

See this thread, starting at the post that I've linked (and maybe some above) for my thoughts on the topic.

TL;DR - I don't think full-on agile is appropriate for a FRC project. It's quite well suited when there are distinct iterations that you can "deliver". Another poster in that thread made the point that the requirements change very little once they're delivered (in 12 days now, can you believe it?!?!)

I agree completely that full-on agile development wouldn't work that well for FRC, primarily due to the time concerns, but I do think that a modified version would be perfect for subteams who are adding more complex iterations to their basic prototypes. It would set clear deadlines to follow for sub-systems of the robot without creating an "all or nothing" approach to the system's functionality.

Some of the posts on the thread you linked mentioned a stand-up meeting in which all the teams gather to report on progress. I really like the idea of having these both at the beginning and end of meetings; it could really keep everyone focused on the end goal.

[Sid323]

Originally Posted by alecmuller

Agile was made for software development, but most of the 12 points translate pretty well for robotics.

The biggest challenge is estimating what level of design complexity your team can squeeze into each system integration cycle (i.e. combining the software, the electrical hardware, and the mechanical hardware, then testing and debugging them as a system).

At a minimum you want to be able to do one design iteration (with time for testing!) in the 45-day build season, but I'd argue it's not really Agile with 1 iteration. Ideally you'd shoot for 2 or 3 design iterations in that time. The key is keeping the design simple enough that your team can execute it (design, fab, assemble, test) in 2 weeks, but still sophisticated enough to play the game. Off-the-shelf components go a long way toward keeping it simple.

My team (~40-50 students last year, nearly 50% of them 1st-year) did a good job of keeping it simple last year. We had a robot that drove - and only drove - by day 4 (it really helps to have old robots you can take apart & rebuild), a wood/metal robot that could drive and lift totes by day 17, and our real competition robot started testing on day 31. [We did the driving-only robot because it was our first time with mecanum - this year we'll probably skip that iteration unless we think we really need a weird new drivetrain.]

It's also worth noting that building a 2nd robot helps A LOT. Last year was our first year doing this, and we saw a number of benefits: Less down-time during the build season because software & mechanical weren't competing for time with the same robot (as much). More student engagement in fabrication and assembly. More driver practice with a clone of the competition bot. We think the marginal cost for the 2nd robot was about $2k - nothing to sneeze at for a team with a tight budget, but still small compared to entry fees.

Definitely agree about the second robot; our team built a second base last season for the first time, and although it came around a little late, it really helped with allowing everyone to work.

As for design complexity, our team's complex situation might keep us from accessing some of our usual machining capabilities, but not so much as to prevent us from building altogether, although we might have to use more off-the-shelf parts than usual.

You mentioned having a working robot in two weeks; how did you decide the design by then, especially considering your large number of rookies? Did you get a large number of members just building by then? Our team usually has had tedious design meetings that can extend into the second or even third week which involve everyone sitting and debating different design ideas (which is part of the reason why we are looking at agile).

[jds2001]

Originally Posted by Sid323

You mentioned having a working robot in two weeks; how did you decide the design by then, especially considering your large number of rookies? Did you get a large number of members just building by then? Our team usually has had tedious design meetings that can extend into the second or even third week which involve everyone sitting and debating different design ideas (which is part of the reason why we are looking at agile).

One of the things that I found REALLY helps is that immediately after kickoff, we go to the offices of our sponsor (my former employer, I've moved on but I'm still involved with the team, almost the only mentor on the team NOT employed by them) and brainstorm designs. The output of that meeting is a shortlist of 2-3 designs that we think will work well. Then we start prototyping with wood, and figuring out what does and doesn't actually work. Occasionally we'll have to go back to the drawing board, but not that often I've found.

Keep in mind that this is a team that is based in NYC, lacks pretty much any mechanical engineering mentors, and has the stupid restrictions that the NYC public school system places on us. Are we the most competitive robot out there? No. But do we field something that at least I'm proud of every year? Yeah.

[philso]

Originally Posted by Sid323

As a returning member of a team which is made up of many students new to FRC this year, I had a few questions about how my team could approach the build season.

This year, we are planning on using portions of the Agile/Scrum development process, which I have limited experience with, but most of the members have never heard of it before. Has anyone used this method before, and what advice would you have for a team new to it? I searched for this on CD before, but the answers weren't very clear (most of them suggested that Agile doesn't work that well for FRC on the whole).

Also, considering that our approximately 35 member team is over 50% rookie, do you have any advice for how to approach a situation in which most of the team has never built a robot before? We do have more than a few experienced members and mentors returning, but our team is currently going through a transformation period.

From what I have read of SCRUM and similar development processes, an underlying assumption is that all participants are committed to "doing what it takes" to achieve the same goal. The whole team must also be trained in that management technique ahead of time and accept being managed in that way. A typical FRC team may have a small core of committed team members but the remainder usually come and go in an unpredictable way. The team members who are assigned a task and don't show up cannot be managed, making everybody frustrated.

I am not against such development processes. Two jobs ago, we used a "concurrent design" process to put out a very complex product involving electrical hardware, mechanical and software design in a relatively short time with everything coming together very smoothly even though the development work was done in three different countries.

[alecmuller]

Originally Posted by Sid323

You mentioned having a working robot in two weeks; how did you decide the design by then, especially considering your large number of rookies? Did you get a large number of members just building by then? Our team usually has had tedious design meetings that can extend into the second or even third week which involve everyone sitting and debating different design ideas (which is part of the reason why we are looking at agile).

Our typical method is to spend the 1st day of kickoff weekend reading the rules and then brainstorming game Strategy (i.e. what the robot needs to do, not what it looks like). For all brainstorming we break up the team into groups of 6-10 people (we found 50 students + 12 mentors was too many to get anything done) that are a mix of new & returning students & mentors, and also cross-functional (i.e. no groups of all-mech or all-coding). We pick Strategy as a team, then brainstorm for "robot elements" (i.e. a drivetrain style might be one element while a loader concept might be another), then a 3rd time for fully-integrated robots that have all the elements needed to execute the strategy.

Usually at the end of all that we're torn between 2 or 3 concepts, so we use what I think of as "sudden-death" prototyping. We split into groups that work separately on prototyping the leading concepts, and then as soon as 1 or more prototypes is ready, we meet as a whole team, review the prototypes (including whatever they have even if it's not finished) and vote to pick a concept or continue prototyping. Here's a video of the concept we picked last year on day 3 or so (without motors or software). Here's what we built for the day-17 robot. The final robot.

While prototypes can be time consuming, we find they usually settle design arguments MUCH faster than sketches and talking.

[Sid323]

Originally Posted by jds2001

One of the things that I found REALLY helps is that immediately after kickoff, we go to the offices of our sponsor (my former employer, I've moved on but I'm still involved with the team, almost the only mentor on the team NOT employed by them) and brainstorm designs. The output of that meeting is a shortlist of 2-3 designs that we think will work well. Then we start prototyping with wood, and figuring out what does and doesn't actually work. Occasionally we'll have to go back to the drawing board, but not that often I've found.

Keep in mind that this is a team that is based in NYC, lacks pretty much any mechanical engineering mentors, and has the stupid restrictions that the NYC public school system places on us. Are we the most competitive robot out there? No. But do we field something that at least I'm proud of every year? Yeah.

Interestingly enough, our teams seem to share a lot of characteristics, such as going to a sponsor's office for a brainstorming session on day one and having to deal with school restrictions. However, we do tend to jump straight into more complicated prototypes rather than sticking to simple initial steps, and that's where I think we can draw some inspiration from your team. We'll definitely have to go with the more simple wooden prototypes that you mentioned, so thanks for that advice.

[Sid323]

Originally Posted by alecmuller

Our typical method is to spend the 1st day of kickoff weekend reading the rules and then brainstorming game Strategy (i.e. what the robot needs to do, not what it looks like). For all brainstorming we break up the team into groups of 6-10 people (we found 50 students + 12 mentors was too many to get anything done) that are a mix of new & returning students & mentors, and also cross-functional (i.e. no groups of all-mech or all-coding). We pick Strategy as a team, then brainstorm for "robot elements" (i.e. a drivetrain style might be one element while a loader concept might be another), then a 3rd time for fully-integrated robots that have all the elements needed to execute the strategy.

Usually at the end of all that we're torn between 2 or 3 concepts, so we use what I think of as "sudden-death" prototyping. We split into groups that work separately on prototyping the leading concepts, and then as soon as 1 or more prototypes is ready, we meet as a whole team, review the prototypes (including whatever they have even if it's not finished) and vote to pick a concept or continue prototyping. Here's a video of the concept we picked last year on day 3 or so (without motors or software). Here's what we built for the day-17 robot. The final robot.

While prototypes can be time consuming, we find they usually settle design arguments MUCH faster than sketches and talking.

We have a rather similar process where we also brainstorm on day one, followed by subteams working on separate prototypes. However, this is where we ran into trouble last season; we got stuck debating which design to pursue, and it caused some serious division in the team. I really like your idea of "sudden-death" prototyping; we might have to consider something similar this year.

As for the agile implementation, I think it would be best served by small groups adding layers of complexity to the system that they're working on. This would start during initial prototyping, and progress past the sudden-death stage where everyone agrees on an overall design to follow.

[Sid323]

Originally Posted by philso

From what I have read of SCRUM and similar development processes, an underlying assumption is that all participants are committed to "doing what it takes" to achieve the same goal. The whole team must also be trained in that management technique ahead of time and accept being managed in that way. A typical FRC team may have a small core of committed team members but the remainder usually come and go in an unpredictable way. The team members who are assigned a task and don't show up cannot be managed, making everybody frustrated.

I am not against such development processes. Two jobs ago, we used a "concurrent design" process to put out a very complex product involving electrical hardware, mechanical and software design in a relatively short time with everything coming together very smoothly even though the development work was done in three different countries.

I am worried about the same commitment issues that you mentioned. While we have a core of members who have both experience and commitment, quite a bit of our team is new, and not many of them have shown true commitment so far. Whether it was slacking off during previous meetings or not showing up at all, I think the main problem was that they were not engaged. Essentially, they weren't sure what to do, so they didn't do much at all.

I think this can be solved by having everyone involved from the very start, but how much can completely new members contribute at the very start of the season? While I'm sure they will have crucial contributions, I think that they will need their sub-team leaders and mentors to keep a close eye on them and hold them accountable for the sprints they choose to pursue.

[philso]

Originally Posted by Sid323

I am worried about the same commitment issues that you mentioned. While we have a core of members who have both experience and commitment, quite a bit of our team is new, and not many of them have shown true commitment so far. Whether it was slacking off during previous meetings or not showing up at all, I think the main problem was that they were not engaged. Essentially, they weren't sure what to do, so they didn't do much at all.

I think this can be solved by having everyone involved from the very start, but how much can completely new members contribute at the very start of the season? While I'm sure they will have crucial contributions, I think that they will need their sub-team leaders and mentors to keep a close eye on them and hold them accountable for the sprints they choose to pursue.

I suspect that most teams have an issue with commitment, especially beyond the core group of students and mentors. We have had team members that we thought we could count on who stop showing up for one reason or another. I doubt that it will ever be possible to "make" all of the uncommitted become committed.

Unlike in a job situation, all the team members and most of the mentors are volunteers and there is no paycheck to keep them committed. It seems that it is mainly the passion that keeps people committed. Thus, one would probably have greater success applying management techniques appropriate to the environment we are in rather than trying to fit the people into a management technique from another environment that sounds attractive.

[GeeTwo]

Trying to put together what everyone is saying, both here and on the other recently-necro'd scrum thread:

Treat scrum (or any other development management process) as you would treat a great drive train or manipulator design or reveal video you find on Chief Delphi:

• Consider what problems you have that it might solve.
• Consider whether you have the resources (time, talent, training, treasury) to accomplish it.
• Consider whether there are pieces of it that you can adopt or adapt into your development.
• You may decide to use it all, use none of it, or use a few bits and pieces.
• After you give it a try, figure out what worked and what didn't. Iterate and make it better!