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.
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.
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)
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.
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.
Something a little more simple and Kanban focused you could use would be Trello
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?!?!)
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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!
That’s an interesting thought. Has anyone written books or otherwise published formal management method material for dealing with volunteer situations and unreliable teams? Most of the theory is of course oriented toward business situations where people have a relatively stable team and predictable outputs.
This is pretty much how our team starts the season too.
The day after kickoff, a mandatory all-day brain-storming meeting with lunch provided. We encourage everyone to watch the game release animation and review the rules ahead of time (which only half do) and go over them again at the beginning of the meeting.
And as you mention, start discussing what we want to do, what we need to do, etc. Small teams create sketches and prototypes and we reconvene. And so on, then by the end of the meeting we have action items for week one. By the end of week 1, we have a drive base (and a practice drive base hopefully) and a direction the robot is to be built, works most of the time.
If I could introduce the notion of the task board to my team, I would. You could have tasks assigned to subteams, or groups of people, not so much individuals, so in case Joe doesn’t show up, Jane can see what tasks remain on the board and progress them, and Joe can take over again next time he’s in.
But the other issue with FRC teams, at least mine, is that the mentors come from a variety of backgrounds and companies and experiences. Some may love agile as they saw it done at their workplace, others may hate it and want nothing to do with it. Trying to get buy-in from all of the mentors would be difficult, let alone then getting the students into it.
On a recent project at work we used a tool called Redmine. Overall I liked it. There was a lot of data entry involved to set up the sprints, stories, and tasks, and a lot of clicking around to assign tasks, progress them, track time, etc. I felt it was quite a lot of overhead (literally half my time as a scrum master was tracking everyone’s tasks, adding new ones, planning the next sprints, managing daily standups, status meetings, …) But a “lite” version could work for FRC teams. Just don’t track to quite as much detail.
I have been deeply committed to and done a lot of work for about 8-9 different volunteer organizations, including 2 flavours of FIRST. The management and motivational methods have always had significant differences from the management and motivational methods used in the 10-11 jobs I have had. That does not mean that many of the management and motivational methods used in the workplace are not useful in volunteer organizations.
I am really perplexed by the notion that whether you commit to a task as an employee/manager or volunteer it has anything to do with agile.
I do agile workflows and waterfall workflows (often pretending to be agile) for a massive International corporation currently, owned and ran companies with agile workflows (servicing the ultimate waterfall workflow the U.S. Military :)) and I would encourage the thought exercise of the process for anyone - even a volunteer organization (much like GeeTwo suggested take what works and abandon what doesn’t).
I can’t count how many times I’ve sat in a room with a project manager used to waterfall and they tell me about how they don’t understand how agile leads to timely execution or doesn’t lead to mayhem. I personally don’t understand why waterfall advocates don’t understand that waterfall’s success is based entirely on heroism which leads to burn out and drives up the cost of the work because the World we live in is moving too fast.
One needs to understand the difference between an innovation and execution workflow. One needs to understand the scope of the work involved and the nature of the commitments. One needs that regardless of the reliability of the people doing the work. If one doesn’t have time for an innovation workflow then be aware that you are crossing agile and waterfall together because execution is judged entirely on the triangle: time, cost, quality and with only 6 weeks (assuming no prior time to build season) you may find you must make that compromise.
In fairness if you don’t know the reliability of the people executing work - say because you don’t know each other at all or they have external critical paths no one can control (jobs, sick relatives, personal issues) - you can’t really rely on any planning because it is out of control. In those cases you plan on minimum deliverable in the maximum available time and set those standards rock hard with extra resources to insure they must be done. Worst case you KOP as the final target as much as possible tossing what would be money into the critical path to insure that time and at least some quality is there even if nobody can keep it on track.
I really think that agile teaches very important skills: break tasks into parts you think you can do, plan to shift delivery when things do not work as expected, understand when a workload is so critical path it drives execution waterfall and direct resources accordingly. It is a shame that the build season is so short because it doesn’t leave adequate time to really see the difference. If you create epic goals that span build seasons you can see where the differences are. Keeping in mind that by necessity creating an epic that exceeds a build season puts you into the summer where most people are unreliable ;).
Where agile becomes a major time commitment is where a business decides that sprints mean tasks always to be hard delivered at sprint end - done & done - never be opened again. This defies the total point. Yes you should divide a larger task into parts. Yes large tasks have deadlines. However if you find yourself constantly racing from sprint end to sprint end under threat someone is not doing it correctly. Now that said: if you run a business and you can use agile as an excuse to beat productivity out of your employees week after week, and your employees let you get away with that as I often see, then you actually have a problem where a company is doing something for questionable reasons. Agile should make innovation easier to understand for the business - because you don’t just pay some smart person to disappear for a 1 year and come back with great ideas: you see how they are arriving at the destination and if they are not arriving there at all.