Advice For Agile/Scrum Robot Development

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

[TedG]

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

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

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.

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

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

The point was when someone your organization has been depending on to do a particular task stops showing up and no longer responds to attempts to contact them, what workflow management technique you have chosen no longer matters.

[techhelpbb]

Originally Posted by philso

The point was when someone your organization has been depending on to do a particular task stops showing up and no longer responds to attempts to contact them, what workflow management technique you have chosen no longer matters.

Isn't that the same issue as an employee rapidly quitting after tasking out on a sprint?

You still know what the work is - you just need to reduce the scope if you can't absorb the tasks or fill the missing role.

[Ian Curtis]

Originally Posted by Sid323

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.

We tried using scrum in 2014 with mostly rookie team members. Our head mentor and another mentor had experience using it in their day jobs as software engineers.

It was definitely an interesting experiment. There were some things I liked, and some that I didn't. I don't think we had enough folks experienced with it. The software team did a great job using it successfully, but I think our mechanical mentors (myself included) had a hard time translating it into our world.

Some of the concepts though, I think work wonders even if you don't follow the strict scrum process. A stand-up at the beginning of the meeting is really important to keep everyone on the same page, especially when not everyone comes to every meeting. Some sort of WIP board is also really helpful. It gives kids accountability for completing tasks, and it lets everyone keep tabs on what is being worked. I also really liked the sprint reviews. It gave students the opportunity to speak in front of their friends (we don't do enough to teach public speaking!), and the demos let everyone see where everyone else was an offer suggestions that would help their team (sensor suggestions on mechanisms, for example).