CIRCA:Wiki Model


Jump to: navigation, search


Agile Management by Meetings and Wiki

I tend to manage smaller projects through meetings and using a wiki. This approach works for teams that are small enough to be able to meet regularly. Once there are more than 10 people the meetings get awkward and you need to break into smaller teams.

How it works

This model is fairly simple. The idea is that you meet every week. At those meetings you do the following:

  • Planning the Meeting: First discuss what has to be discussed at the meeting. Try to avoid actually discussing the issues while polling folk as to what needs to be discussed. Once you have the list of things to be discussed you (the manager) should prioritize them. Some issues will be inherited from the previous meeting and those should go first.
  • Round-Robin Alternative: An alternative is to just work around the room giving everyone a chance to report and using the reports as a way to get at the issues.
  • Someone should call up the wiki and create a new Meeting Notes for <Date> page where an outline of what has to be done is recorded. This can be projected to make sure everyone is on board. This meeting notes page can be managed by you (the manager) or one of the team.
  • As you work through the issues or individual reports you (the manager) should identify the next steps to be done. These should go into the wiki meeting page.
  • As you work through the issues and reports you should compare what was on the last meeting notes to do list to what is being reported. Ask team members if they have completed things or how a task is going. Give them a chance to talk about it even if it is not due that week or going well.
  • While the reporting and planning is at the heart of the meetings, it is a good idea to devote time to different activities in order to vary the meetings. You can ask team members to give prepared and longer summary reports at a meeting when they have completed a milestone. Members can be asked to propose conference papers or to run through slides for a paper. Anything activity in a meeting which communicates research rather than only communicating the management of research will make the meeting more interesting. Ideally these meetings can turn into a form of seminar where members teach each other.
  • Once or twice a year you should hold a celebratory meeting somewhere where you can recognize the work done by the team.

The Wiki

The wiki is where all the documents for the project go, starting with the Meeting Notes. The wiki can be open (which I prefer) or private (behind a password.) The wiki should be where team members go to find out what is happening, to get information and to put reports. This means that you need to habituate team members to writing to the wiki regularly.

The wiki can include the following types of documents:

  • A brief description of the project, its research goals, and so on.
  • A project charter if you have created one together.
  • A list of participants and stakeholders (including recognition of funders if the site is open.)
  • Links to any other online resources related to the project like the GitHub site, the public project blog, the web site being built and so on. Keep these links up to date - that way everyone can find things by going to the wiki.
  • Literature reviews and environmental scans.
  • Reports from team members on different subjects.
  • Abstracts for papers and other documents.
  • Interface designs and related information. Keeping all the stuff in one place helps when you have to report or prepare a paper.
  • Meeting Notes in reverse chronological order.
  • To do lists, bug lists, idea lists and so on.

Advantages and Issues

  • This model doesn't introduce complex management practices or technologies. Everyone knows how to do meetings and they can learn to edit a wiki.
  • Team members will, however, have to get in habit of documenting what they do in the wiki. If someone has to write an abstract for a conference it should go into the wiki.
  • Try to avoid having team members writing things in something else (MS Word), sending it around by email, and then putting it in the wiki afterwards - instead I encourage students to just write to the wiki and save us all time. This also keeps the amount of documents down and centralized.
  • This model allows the team to self-document efficiently. If you write meeting notes during or right after the meeting
  • This model is about habits - habits of work, habits of reporting, and habits of communication. If you habitually record what people agree to do and then check that they have done it (or are working on it) then the project stays on track, work gets done, there is regular communication, and people feel recognized for what they are doing.
  • Weekly meetings that go over what has been done and should be done mean that people who work hard can be recognized and those that are struggling have to explain themselves to the rest of the team. This puts team members in a position of reporting not just to you, but to the larger team. If things aren't going well you will get hints early on (within a week) and the team can discuss how to help.

When to Not Use Such a Model

As mentioned at the beginning, this will not work if the project team is too large to have weekly meetings together. The moment you can't all meet then you need to break down the team into subprojects (each of which could operate using this model.) Some other reasons not to use this model:

  • A wiki isn't the best way to track bugs in software development. For larger software projects you should use software development tools like GitHub that can allow you to track bug tickets.
  • If the team is distributed it can be harder to run efficient meetings. You can Skype people in, but that slows down the communication. I suggest that the distance partners be brought in every other week or as needed and that they be brought in for specific sections of the meeting.
  • If members of the team are working on very different tasks it can be a waste of people's time to listen to detailed discussions of subtasks. For example you may need to sit down with a programmer for an hour testing an interface, something the others will find tedious. Don't waste their time - schedule a separate meeting for that and have the programmer simply provide a summary report at the main meeting.

Return to Entry Page

Personal tools