CIRCA:Wiki Model

From CIRCA

(Difference between revisions)
Jump to: navigation, search
(Created page with '== Management by Meetings and Wiki ==')
Line 1: Line 1:
-
== Management by Meetings and Wiki ==
+
= 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 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
 +
 
 +
== 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.
 +
* 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.
 +
 
 +
 
 +
 
 +
----
 +
[[CIRCA:RockwellGuide | Return to Entry Page]]

Revision as of 16:35, 18 May 2012

Contents

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 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

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.
  • 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.



Return to Entry Page

Personal tools