How could Agile methodologies be used with a middle school Lego Robotics team?

Question

I'm a coach of a middle school Lego Robotics team, competing in our local FIRST Lego League competition. I'm interested in bringing Agile methodologies to our team. From what I've been seeing, it seems like a good fit, and would really help teach the students how things work in real world software engineering. The problem is that I'm a bit shaky on some aspects of adapting Agile to a software+hardware problem.

Here's what I have so far:

• In the competition, the robot is set up on a table with many Lego structures. These make up missions worth varying number of points. The robot leaves a Base area, does something (ideally one or more missions) and returns. This sounds a lot like a "user story", and I'm already planning to get the students to write what they want the robot to do that way. All the missions basically become the backlog!
• I'm also going to use Planning Poker to estimate how hard they'll be to build and program for. Our team only meets for 1 hour per week, though. What would be the best way to set up the time estimates? I'm thinking that the smallest unit should be 1/2 an hour, and would go up from there.
• These missions tend to be pretty complex sometimes, and benefit from being broken down into simpler tasks. Should we worry about that when writing up user stories? (Doesn't seem so...)
• As coach, should I act as project owner? Or should a student on the team be tasked with determining which missions or combination of missions is most important?
• Given that our team is small (8 students), would one Scrum Master be best? Should that be me, or a student?
• Given that our team is small, is it fine for students to be testers and developers as needed? (I'd like to avoid giving them excuses for downtime.)
• Since we only meet 1 hour per week, would a sprint length of 1 month be best?
• I've also been looking at the concept of test-first design, and while it seems great, I don't understand the terminology. How would I get my students to design the robot and its programs test first? Would it even be appropriate? What kinds of tests (unit? acceptance?) would work well?

I know these are a lot of questions. Any help you all could give me would be greatly appreciated. Thanks!

(Also, if you'd like to read about this teaching experiment, I'm blogging about it at gettingteachingdone.net.)

Answer 1

I agree with you that agile methods can be applied in your scenario. However, for the hardware part, this is only possible because of the special nature of your hardware: You can easily apply changes (add/remove/change parts) to it. Something that's oftentimes not possible.

Regarding your thoughts:

• Making a Story from each challenge is a good idea. That some challenges are bigger, while others are smaller is no problem here. After you decided on the priority of the stories (effectively creating the backlog) you should start to estimate their complexity, from the top. If you find that the complexity is too big, break them down. Usually you should break stories down when the developers are uncertain about the real complexity or the estimates are high. I found that it pays of to break stories down to pieces until multiple stories fit into one sprint. To get there, estimate, break down, estimate again, split again, ... until all stories are small enough. It will probably take some time until you find the right size, however.

• Regarding your estimation strategy: Estimating required time may be hard for a team new to the field. Have a look at the relative scale used in planning poker. That too has its drawbacks, however. In any case, you should chose a value distribution like to the one in planning poker, because it makes no sense to discuss whether a task needs 8 or 9 hours. If you're not sure you can make in 8, chose 13. You will probably need them.

• Regarding the Product Owner (PO) and Scrum Master (SM) roles: Keep in mind that the Scrum Master should be someone really familiar with the Scrum process, since it's his responsibility to make the team adhere to it. The PO and SM should not be the same person. Consider also that the Scrum Master has a full-time job. Keeping the team running is a lot of work. I personally would recommend you to take on that role and chose a PO from the students. I could even imagine the students together deciding about the importance of stories. However, there should be a clear responsibility for the product backlog (writing/maintaining stories).

• Scrum is intended for teams with 7 ±2 developers, so one SM should be sufficient in your case. In any case you can start like that, and if the SM should drown in work, you can still think about an assistant SM.

• One of the most important things about Scrum is that the team manages itself. Don't assign roles to the team members. If there are some more into testing and some more into developing, this distribution will likely evolve on its own. Along the same lines, they should not have to justify their individual work in front of you, but in front of the team. They are working together. They know best who's doing a lot of work and who isn't. And they know the reasons. If you take on the SM role, you may assist them. But you are not the one to punish lacking commitment.

• Regarding meeting only once per week: That's likely to be not enough. There should be at least one working meeting of the team. I once participated in a project with a similar setup and in my experience it's really hard to get things together when everybody is working at their own time. If I work on Mondays and I need something from a colleague who is working on Fridays, I may have to stop working for the week. Scrum is intended for teams that work in the same office/on the same floor. If you want to get it working in a part-time, distributed environment you are hard pressed. Get them to spend as much as possible of their working time together.

• Regarding sprint length: In my experience, it's not good to choose sprints too long, only because you work part-time. Just pack fewer stories into your sprints, for the sake of keeping an eye on the project's progress. Note that with fewer stories in each sprint your planning time decreases, since you need only to break down and estimate as much as you need for the next sprint. To keep your long-term roadmap up-to-date (I guess there is a deadline in the end) you can go through the complete backlog every, say, 3-4 sprints. High level.

• Test-first usually relates to unit tests. These tests really reflect what you are doing, as you make them pass fast. Acceptance tests can be written up-front, but they stay red for a long time and you have no easy way of telling to what extent they are done. The idea of test-first is to iteratively implement software along with tests. Don't write code unless there is a failing test, but also don't write new tests as long as there is a failing one (btw. a test that doesn't compile is a failing test). I don't really know how the FIRST Lego World functions, so I cannot give you specific advice about how to proceed here. However, building the robot itself test-first is probably nigh-on impossible. What would be the test? Can the hardware do anything without the software? Checking whether the robot does the right thing, given that the software is tested, is a system-level/integration test.

Hope this helps!

Answer 2

Wow. Sounds like these kids have a great coach and some really fun Lego activities.

I have recently done Scrum City Lego training and would highly recommend it as a way of teaching Agile practices. Especially the role of the product owner and how a team should interact.

The are some nice resources on this Lego4Scrum.org, including a PDF guide for running Scrum training.

I am sure there will be elements you can use and learn from in this approach. You might want to try out the exercise to build a robot space station or something similar. You will need two people to run the exercise, a mean Product Owner and a Scrum Master to control the process. But you can combine the roles.

Scrum as a framework is great for building complex projects. It helps you to use emergent design to build a better product and collaborate together as a team.

You might also want to look at Lean practices, such as Kanban, which are born out manufacturing process improvements that focus on eliminating waste and focus on continual improvement. Great principles to be teaching kids. I understand there are ways of teaching this using Lego.