|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Advice For Agile/Scrum Robot Development
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. |
|
#2
|
|||
|
|||
|
Re: Advice For Agile/Scrum Robot Development
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/ |
|
#3
|
|||
|
|||
|
Re: Advice For Agile/Scrum Robot Development
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?!?!) |
|
#4
|
||||
|
||||
|
Re: Advice For Agile/Scrum Robot Development
Quote:
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. |
|
#5
|
||||
|
||||
|
Re: Advice For Agile/Scrum Robot Development
Quote:
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. |
|
#6
|
|||
|
|||
|
Re: Advice For Agile/Scrum Robot Development
Quote:
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 |
|
#7
|
|||
|
|||
|
Re: Advice For Agile/Scrum Robot Development
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 |
|
#8
|
|||
|
|||
|
Re: Advice For Agile/Scrum Robot Development
Quote:
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. |
|
#9
|
||||
|
||||
|
Re: Advice For Agile/Scrum Robot Development
Quote:
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. |
|
#10
|
|||
|
|||
|
Re: Advice For Agile/Scrum Robot Development
Quote:
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. |
|
#11
|
|||||
|
|||||
|
Re: Advice For Agile/Scrum Robot Development
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:
|
|
#12
|
|||
|
|||
|
Re: Advice For Agile/Scrum Robot Development
Quote:
(Hmmm....off to google.....) |
|
#13
|
|||
|
|||
|
Re: Advice For Agile/Scrum Robot Development
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. |
|
#14
|
|||
|
|||
|
Re: Advice For Agile/Scrum Robot Development
Quote:
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. |
|
#15
|
||||
|
||||
|
Re: Advice For Agile/Scrum Robot Development
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. Last edited by techhelpbb : 30-12-2015 at 12:14. |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|