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?!?!)

[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 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.

[tsetse fly]

Originally Posted by Sid323

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.

Just to reply to the question on sprints, you can definitely identify and define a set of work for the week (call that a sprint, making that a week?) and focus on that. In Agile/Scrum once that next sprint is set, you don't adjust or change it. Or to be a little more flexible as in FRC there are lots of different types of activities going on, you can use that Trello board and operate more of a Kanban approach than Scrum. Moving and managing all those different elements of work of the team through phases of completion.

However you approach it, you can't go wrong with spending more time than you probably already are - planning the work to be done, making it visible to your team and keeping everyone aware of the progress of all those things going on.

"In preparing for battle I have always found that plans are useless, but planning is indispensable."
Dwight D. Eisenhower

[GreyingJay]

I see the benefits mostly in breaking down the big tasks into smaller, manageable sprints each with smaller stories, broken further into tasks. At work, a task should be something that one developer could do in a day or two. A sprint would be about two weeks.

For FRC, perhaps a sprint is a week, maybe two. A task could be a chunk of work that one student could do in one build meeting, whether that's a 3-hour evening or an 8-hour day or however your team works.

For example, your first sprint could have three stories and look something like:

Sprint 1:
- Assemble the KOP chassis
--- Cut the frame pieces to size
--- Assemble the frame and cross pieces
--- Assemble motors and gearboxes

- Wire up the control system
--- Build battery cable and circuit breaker connector
--- Connect the PCM, VRM, PDP
--- Wire the RoboRio power and CAN
--- Connect the bridge
--- Connect the motor controllers

- Prototype mechanism idea
--- Build plywood frame
--- Build wheel and axle driven by drill motor
--- Experiments to determine best placement

[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.

[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!

[David Lame]

Originally Posted by philso

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.

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.

(Hmmm....off to google.....)

[GreyingJay]

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.

[philso]

Originally Posted by David Lame

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.

(Hmmm....off to google.....)

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.

[techhelpbb]

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.