How to? Getting things done...

[Pault]

Originally Posted by Team 4264

What proven tools has your team used that help insure everyone has a job, and keeps the "benches from getting warm." We are looking into using SCRUM, and will probably go with a physical scrum board setup, yet I can only speculate at the sheer mass of post it notes involved. If any of you have experience with this, do tell. If not tell us about your proven getting things done tools, or methods. Links, if you got 'em.

The team I was on last year tried using SCRUM, and it did not end well. It essentially just ended up using a ton of precious meeting time with little benefit. Essentially, what it comes down to is that SCRUM has a lot of quirks that work really well in a normal, professional environment, but not so well in FRC. For example, you really only get one shot at making a robot (kind of 2 if you build a practice bot, but lets ignore that scenario). That means you cant have a "potentially shippable product increment" after every "sprint." Also, for coding, you generally cant reliably test a lot of code until late in the build season. Essentially, the whole idea of a "sprint" only works for projects where there are going to be many exact, functional prototypes of whatever is being built (meaning they match the CAD rather than are made of wood, and are properly wired to a control system so that code for them can be tested). FRC teams just dont have the time and resources to do that.

Now, there are a lot of good principles that can be taken from SCRUM. Both the daily scrum and the scrum of scrums are useful for keeping the team on the same page and making sure everybody knows what needs to be done. The whole notion of iterative design is great for FRC; prototypes are your friend. And TO-DO lists are awesome for keeping track of what needs to get done and making sure everybody has work to do, although I personally prefer online TO-DO lists such as Trello.com which my team is using this year.

Finally, if you have the privilege of having some devoted engineers mentoring your team, use them to lead projects. They are much more efficient at distributing tasks than students are, partly because of experience and partly because mentors generally aren't occupied doing their own thing during meetings. The student leader of the wiring team is going to want to be involved in wiring the robot themselves, not spending all their time telling other students what to wire and teaching them if they dont know how. An electrical engineer, on the other hand, would be more inclined to oversee the work students are doing and put someone on a new task when they are done.

[CindiCC]

any updates on how scrum worked for your team? We have a new mentor who wants to teach it to our team.

[jds2001]

Wow, quite the necro

But as mentioned above (I'm a software architect at $DAYJOB, lead mentor/doer of nothing, director of everything in FRC - pretty much the same thing!), I've found that Scrum works very well in a professional environment when you actually have an iterable piece of software. In robotics, those iterations are a lot different - you're building a physical machine. You can't really have a "shippable increment". Of course there's software that needs to run on it, but that's but a small piece.

Another important part of making Scrum work in a professional setting is that only those directly involved in deliverables for the day are invited to the Scrum meetings. I'm not invited to our $DAYJOB daily Scrum meetings, nor should I be. The team is self-organizing for a reason. I really don't think that such a model would work with a robotics team.

Now what do I think might work? A simple Kanban board (think Trello) that contains small, separable things to do that could be moved into the done column as appropriate. I've tried this with my team, due to the unique dynamics of the team (look into some of my other posts for details), it really didn't work well, but I don't think that's universal and I think it would work great for many teams.

Interested to hear other's experiences as well....

[GeeTwo]

Originally Posted by jds2001

Interested to hear other's experiences [with scrum] as well....

I'm not a software developer anymore, and my first experience with scrum was in the past year, as a subject matter expert and minor stakeholder. I agree that scrum seems best linked to "unstructured" problems, either because your customer (or customer base) doesn't know what the best solution is, or there is more time available to experiment and develop a "final" solution provided that interim functionality is developed. From my "stakeholder" view, scrum appears to be a way to keep stakeholders/customers "in the loop" at the sprint level (a few weeks) while insulating them from the (usually daily) scrums. These sorts of problems were more commonly managed with "spiral" development until recently. In a lot of ways, scrum is a formalization and acceleration of spiral where each 6-18 month spiral is replaced by a number of 3-12 week sprints, each of which is much smaller scope. There is just not enough time in an FRC build season for scrum as I have experienced to work properly; you really do need to develop more solid requirements and build all of your base functionality in parallel. Besides, there is very little interaction with "the customer" resulting in less drift in the functional requirements. The GDC publishes a set of rules at the beginning, and only interacts with development teams through the Q&A process. The requirements only change a few percent during the course of build season, and the GDC customer/stakeholder really doesn't care how you solve the problem/meet the challenge. That stated, the derived requirements and technical requirements are subject to a lot of drift as competition progresses.

[Bluejackets]

Interesting topic. Rookie question.... What does "SCRUM" stand for?

[z_beeblebrox]

Originally Posted by Bluejackets

Interesting topic. Rookie question.... What does "SCRUM" stand for?

https://en.m.wikipedia.org/wiki/Scru...e_development)

[DaveL]

+1 that Scrum or an Agile software design methodology does not exactly match up with an FRC project.

I've been on a number of Agile software projects where the project manager used VersionOne to assign tasks, review task progress and to record task completion. You could run your build as a 6 week sprint and add redesign activities as needed.

The software team would hold brief daily meetings and weekly meetings to insure each professional was focused on accomplishing their task so the parts could be combined into the finished product at a defined point in time.

On my team not every student can attend every meeting and sometimes we have to train another student to work on a task to keep it moving.

If you have enough students and mentors, I would suggest planning out the next meetings activities and kitting the needed parts. By this I mean if you need to install a pneumatic cylinder, find all the needed parts and bag them together. Then at the next build meeting, you can hand the bag and the task to a student. If they need some training, have them stop and ask.

I've done this time permitting and it works great. It allows me to engage a far larger number of students at the same time. If your students already know how to find the parts and how to install them, that is great and you can skip the kitting!

To make these parts easy to find, I like to tape the bags to a glass window. Tape works great and its a visual reminder of what we have to get done.

It doesn't help with documenting project status, that would have to be a separate manual activity.

If you want to try the software approach, here are some options:
https://www.versionone.com/

Gantt Charts to visually map project activities
https://www.google.com/search?q=gant...utf-8&oe=utf-8

http://agilescout.com/best-agile-scrum-tools/

Dave

[GeeTwo]

Originally Posted by Bluejackets

Interesting topic. Rookie question.... What does "SCRUM" stand for?

As far as I am aware (and confirmed by some superficial Google searches, scrum doesn't "stand for" anything, which is why I didn't capitalize it in my post. A "scrum" is a daily cycle in the "Agile" development process (plenty on the web for you to search for info past what I am providing!). Agile is used mostly for software development, and as far as I can tell, the term derives solely from the rugby term. Never having played rugby (but knowing a number of rugby players through the years), a scrum is the analog of a "face off" in hockey or a "tip off" in basketball, but it is more commonly resolved by force/strength than height or speed. As I understand it, each team typically links arms-over-shoulders to form a chain, with the heaviest/strongest members in the center, lightest towards the ends. The ball is tossed to the turf by an official, and it's up to the two teams' feet to get control of the ball. My understanding as to how this applies to agile is that each scrum (usually a 1 day cycle) is violently attacked by a team working closely together on a short time schedule. How they pull this off day after day is a mystery to me, as I have not been part of the scrum process, only the coarser sprint process, which typically involves about twenty or thirty scrums, and results in a deliverable product (often in the form of a patch, release, or other incremental upgrade).

[Daniel_LaFleur]

Originally Posted by Bluejackets

Interesting topic. Rookie question.... What does "SCRUM" stand for?

As others have said, SCRUM is not an acronym.

What SCRUM is, is a structured periodic (daily) meeting to assess issues and find iterative improvements. This structure includes most stakeholders and people have defined roles for this meeting (customer advocate, Technical team, SCRUM master, etc.)

SCRUM is part of the Agile development cycle. The Agile development cycle is a development process whereby unaccounted for issues are expected to happen and that structured iterative releases (think software revisions) can be applied to correct for these issues.

Agile fits into the LEAN (Toyota model) development process at gates 2 and 3 (and sometimes 4).

SCRUM (and Agile/LEAN) could be applied to FRC, but would have to be setup prior to a season, as the development cycle is very short.

[Foster]

A common characteristic in Agile is the daily "stand-up", also known as the daily scrum. In a brief session, team members report to each other what they did the previous day toward their team's sprint goal, what they intend to do today toward their team's sprint goal, and any roadblocks or impediments they can see to their team's sprint goal.

A few key point. The sprint would be a set of goals to reach in a short period of time (in FRC 4 to 7 days) Like working drive base mockup (mechanical and code) in the next 5 days.

So the morning stand up would be a discussion of what needs to happen today. Cover what got done in the prior build period, what needs to happen today including process and parts. Discussing blockers is important so people can be aware of what they are and resources can be assigned to work on knocking them down.

Because of the short cycle in FRC and that people change from day to day, a standup meeting at the end of the day would be good. This gives a better continuity between sessions. It's also a chance to get a list of parts needed so they can be ordered.

The use of the scrum would give most teams the best benefits and quickest return on efforts. There is lots more to Agile, but it you would need to plan in Sept/Oct how to do a full Agile cycle.

You don't need a Scrum Master (I'm certified) to run the meetings. Keeping records of the what, when, how, who of the meeting and keeping the meeting on track (and SHORT) is the primary job.

I like a dedicated whiteboard to track the day to day stuff, YMMV.

[runneals]

Originally Posted by Pault

The team I was on last year tried using SCRUM, and it did not end well. It essentially just ended up using a ton of precious meeting time with little benefit. Essentially, what it comes down to is that SCRUM has a lot of quirks that work really well in a normal, professional environment, but not so well in FRC. For example, you really only get one shot at making a robot (kind of 2 if you build a practice bot, but lets ignore that scenario). That means you cant have a "potentially shippable product increment" after every "sprint." Also, for coding, you generally cant reliably test a lot of code until late in the build season. Essentially, the whole idea of a "sprint" only works for projects where there are going to be many exact, functional prototypes of whatever is being built (meaning they match the CAD rather than are made of wood, and are properly wired to a control system so that code for them can be tested). FRC teams just dont have the time and resources to do that.

Now, there are a lot of good principles that can be taken from SCRUM. Both the daily scrum and the scrum of scrums are useful for keeping the team on the same page and making sure everybody knows what needs to be done. The whole notion of iterative design is great for FRC; prototypes are your friend. And TO-DO lists are awesome for keeping track of what needs to get done and making sure everybody has work to do, although I personally prefer online TO-DO lists such as Trello.com which my team is using this year.

Finally, if you have the privilege of having some devoted engineers mentoring your team, use them to lead projects. They are much more efficient at distributing tasks than students are, partly because of experience and partly because mentors generally aren't occupied doing their own thing during meetings. The student leader of the wiring team is going to want to be involved in wiring the robot themselves, not spending all their time telling other students what to wire and teaching them if they dont know how. An electrical engineer, on the other hand, would be more inclined to oversee the work students are doing and put someone on a new task when they are done.

Don't forget to hire that Certified SCRUM Master In all seriousness, I could see where a modified version of SCRUM or an agile type process could potentially work. We tried to use bits and pieces of it (primarily the project scope document) on projects where I have been the only developer and it seemed pointless to use it (besides the project scope document) where I was the one doing all the development work.