Agile Student Project Team?

Question

I've been reading about the various forms and aspects of agile development, but all focused on the corporate environment. I am on a student project team at my university, and I'd like to see if some agile concepts could work in an environment other than 'everyone works full/part time'.

We do have our own project server, with Subversion for version control, and Sharepoint for documents, wiki, and action items.

Some challenges

• It's hard enough to arrange a weekly meeting, daily standups are infeasable

• We're our own customers for the most part (we're part of a competition, but we can't work closely with the organizers)

• Not just programmers, also mechanical/electrical team members

• Sharepoint's action items don't have the best interface. Are there any extensions available? Would it make sense to switch to something else (like Trac) at the expense of a unified interface for everything non-svn?

• Procrastination. As students, the most natural thing to do is wait to the last minute

• We have our own space, but often, it's easier to do work elsewhere, and there's no way to predict if anyone else will be there except by making explicit arrangements

• Other classes (still have to pass them, so total commitment to the team is limited)

Perhaps our team could benefit from more than just agile techniques, so all suggestions are welcome.

EDIT Thanks for all the great answers. I'm going to start asking my teammates how they feel about some of these ideas, and see what they buy into. Should I link them to this question? You can edit your answer or just leave a comment to answer this secondary question.

Answer 1

IMO, SharePoint and agile don't really mix well. Pick something that's more "throw-it-up-there". I'd go with something like Trac, which has great Subversion integration.

It sounds like communication and procrastination is going to be your biggest challenge. If you don't give yourself enough time to do the work and do good testing, you're not going to have a good result. This is only logical, and doesn't really have anything to do with whether you're agile or not.

Answer 2

If you ask me you're adding too much overhead to your student project. Methodologies are generally only used in corporate environments because of the need to monitor and control human resources (control isn't the right word - but I needed one stronger than co-ordinate). In a group of students, there's absolutely no need to bother with anything like that. Adhering to a methodology will only slow you down.

You have identified your challenges. Make your peers aware of them and talk about how best to deal with them. Use methodologies as a source of ideas, but don't bend to one in your situation.

Answer 3

I wouldn't try to force a full, corporate environment style Agile programming workflow onto your team, but I do think that some level of Agile methodology could be valuable. I actually think that some of your "challenges" would be mitigated somewhat by some of the Agile ideas, but would require some level of commitment from every one on the team.

For example - the daily standups/weekly meetings issue.

This doesn't have to be a large thing (and, especially in a student project case, I'd say making it smaller is better). Having a Trac site (which I'd recommend over sharepoint if you're using SVN already) with a single place (like a wiki page) to just track the standup info in one sentence can still be valuable, without taking more than 1-2 minutes per day / person.

If somebody misses a day or two here and there, it's not a big deal, but if the team agrees to doing this, it can actually help the procrastination issue (forcing people to just say "I did nothing. I'm doing nothing" has a benefit - it keeps people at least thinking about your project, which tends to reduce the amount of procrastination), as well as having people work in different locations but still stay in communication.

This is also easy enough for non-programmers to do, and can help keep the mechanical and electrical teams working together, and everybody moving forward.

That being said, I'd make sure to keep it short and sweet - Try to keep the burden to a minimum, but I still think there's value in some of the Agile programming ideas, even in a student setting.

Answer 4

You can do a weekly or bi-weekly meeting that simulate a daily. Start your meeting with the three questions:

• What did you accomplish since thelast time we met?
• What do you plan to do until next time?
• Is there anything blocking your progress?

Note that these can also be answered by your non-programmer teammate. In the company I work for, we have multidisciplinary team using scrum (programmer and artists) and it's working well.

If you don't want to do your meeting standing up, at least don't go for comfortable sofas. This should make your meeting shorter by making people more attentive.

You should use the method to your advantage and minimize procrastination by making interim milestones. Build your task list (excel, any other spreadsheet software is fine). Split them in milestone. When comes the time to review, sit with your team and look at your product like a client do, maybe involve your teacher.

Poker planning is fun, and a nice way to clarify your what you have to do, and how you plan on doing it. Breaking down objectives into tasks will involve people from all disciplines. But only people that can do the task should evaluate it.

Answer 5

In your situation, not all of the Principles behind the Agile Manifesto will be easy to apply You might be able to apply some ideas that come from the principles, specifically:

1. short iterations at the end of which you always have a "working" project, even if some desired features have not been implemented yet.
2. maximize the amount of work not done - rather than designing a grand framework that you hope will cover all the needs of the project, start small and do just what is needed as you go.
3. If you have milestones during your project, consider having a meeting (called a retrospective) after each milestone just to look back and see how your process worked / didn't work and how you might improve it.

On the software parts, you could consider TDD and pair programming

Answer 6

I would say go with SCRUM. Skip the daily meetings and instead make a private forum and require each member to check it at least once a day. Try to make your sprint retrospective and planning meetings an "in-person" event over drinks or coffee.

The whole who is doing (and has done) aspect of SCRUM is amazing once everyone gets used to doing it. The 'sprint release' concept also helps team members from 'going dark' for too long and keeps the project based in reality ("What can we do in two weeks" vs. "I have this idea I am going to start and who knows when I can finish it").

Also, if your team has more then 8 people, skip SCRUM =)

Lastly, if you have the talent and someone on your team has the means (and desire), consider TFS workgroup (I think it comes free with academic MSDNs). If you don't have someone on your team who REALLY wants to take on that burden, skip it tho.

Answer 7

When I was in college, I took several courses that encouraged the adoption and use of Agile practices. They were mostly a mess and although I learned a lot of from them they generally weren't the things the professor was expecting us to learn. I do agile development professionally now and love it, but here are the things I wish that I had known when I was doing agile in school:

• Getting things squared with your schedule is really, really hard, which makes daily standups more important, not less. If you can't sit in the same room (very hard) then use Twitter or Yammer or just email.

• A lot of Agile's benefit is simply in getting you into a rhythm. That doesn't just mean weekly meetings; it means set goals, commitment to points, and weekly deliverables. This is tough to pull off in an academic context but should go a way towards helping you with your procrastination problem.

• It's tough to get used to pairing; everyone has their own computer and style of development. Try to hook a second keyboard/monitor/mouse up to your existing laptops if possible, or use screen sharing software, and standardize on an IDE. Pairing also really, really helps with procrastination but trying to do it without good tools is an awful lot of trouble.

• Don't skimp on unit testing, even if you think of it as a silly, academic, one-off project. I've done projects before that I figured were too small to bother with testing and it's never failed to come back and bite me on the ass.

• Sharepoint might be a bit heavyweight. Believe it or not, we still do an awful lot of things on whiteboards or with index cards. You may be your own customer but that doesn't mean you can't have stories (discrete, estimable features, basically) and goals. It's helpful to be able to visualize it: these features are planned, these are in development, these are ready for testing. If you'd like software recommendations I can give you those but I do recommend simple paper for a lot of the planning process.