Tag Archive: Volunteer


Another in a series of articles intended to briefly explain how to apply different agile practices to the work of social innovators, today’s topic is Progress Meetings:

Over the past few days, I have had some great conversations about Progress Meetings, also known as Daily Standups. While there is much more that can be said about these short meetings, I wanted to give a quick recap of the three questions along with a bit of guidance about how to make these meetings effective.

Progress Meetings take place in the context of a Cycle Plan. Members of the Team start their day with a short meeting that intended to keep the team aligned, focused, and constantly adapting. Generally, Progress Meetings cover three basic questions:

  1. What did I do yesterday (or in the last work period)? – the length of the work period depends on the length of time that might elapse until the Team can get together to update their status again, such as a team of volunteers
  2. What am I going to do today? – this question orients the Team member to the tasks of the next work period; consider it mini-planning
  3. What did I learn/observe in the last work period that might be helpful for others on the team? (Alternatively, you can ask “Were there any obstacles preventing me from getting work done?”) – this is intended to carve out a moment of daily reflection, sharing, & learning that will aid the Team to become high performing

Some Guidance about Progress Meetings

Remember that the Progress Meeting should be short. That’s why it is useful to have everyone standing up. Once people start to fidget, you know the meeting has gone on long enough. Keep the meeting simple and focused on answering only the three questions. Most importantly, avoid having discussions about any particular points that come up. If more discussion is needed, you should schedule a separate meeting for discussing that specific issue.

Would you like help becoming more agile?

If you would like help implementing Progress Meetings or any of the agile practices in your organization, please post a comment on the blog. I am certified to provide OpenAgile training, coaching, and consulting, and I would be happy to aid your enterprise to realize the full benefits of being agile.

Advertisements
I am engaged in a learning process with a charity that has undertaken to implement a new model of volunteer coordination based on OpenAgile, an open source agile method.  We recently held an orientation with our new volunteers.  In the hopes that this information will be useful to others who are trying to innovate on their  model of volunteer coordination, here are the instructions I shared with the volunteers.  In summary, they cover our process for sharing tasks, the tools we use to communicate with each other, and our use of what we are calling “60/40 time” a twist on Google’s “20 percent time“.

ORIENTATION INSTRUCTIONS:

I. Agile Volunteer Team Process

We are all here to support the charity. We are inspired by its mission and goals, and we want to help in a way that draws on all of our abilities, knowledge, skills, and creativity.
Our team uses a specific system for producing valuable results. We work in Cycles of 5 weeks. The charity’s staff talk with the stakeholders and decide what steps are necessary for accomplishing the organization’s goals. Each one of these steps, called Value Drivers, add up to providing value for the stakeholders once they’re delivered. The staff also decide the priority order for completing the Value Drivers.
In week 1 of the Cycle, there is a planning meeting with all the volunteers who are committed to doing work during the 5 week Cycle. All volunteers are urged to attend and participate.
  1. The meeting begins with reflecting on the results of the previous Cycle. These observations and lessons are an important part of the planning process.
  2. Next, the team of volunteers works together to create a Cycle Plan by taking the highest priority Value Driver and breaking it down into tasks. Tasks are represented by sticky notes on the wall.
  3. Third, the volunteer team counts the number of tasks needed to complete the highest priority Value Driver. If the past Cycle showed that the team can complete more tasks, then the team takes the next Value Driver in the list and breaks it down into tasks. This process continues until the team makes a unified decision that it has taken on the amount of work it can actually accomplish.
  4. The last part of the meeting is commitment. Everyone shares the responsibility for completing the Value Driver (represented by multiple tasks) by the end of the Cycle of work. Therefore each volunteer must truthfully commit to completing the work. If a volunteer is not comfortable committing to all the work on the task wall, then some tasks must be removed until everyone is able to commit.
In week 2, 3, 4, and 5 of the Cycle, the team of volunteers complete the tasks in the Cycle Plan (aka “doing work”).
  1. Volunteers are free to take whatever task is of interest to them. If they need more information about the task, they ask the other volunteers or the staff for details.
  2. When a volunteer begins a task, they sign their name on the bottom of the sticky and move the task into the “in progress” column.
  3. When a volunteer completes a task, they move the task into the “done” column.
  4. There are weekly conference calls where all the volunteers check in. They answer 4 simple questions
    1. What did I do last week?
    2. What will I do this week?
    3. What did I learn/observe?
    4. What obstacles, if any, are affecting my ability to do work?
  5. New tasks can be added to the wall based on any of the volunteers’ observations, obstacles, clarifications, questions, urgent new tasks, etc. If you add a new task to the wall, add your name to the bottom of the task, so that other volunteers can know who to go to for questions. Note that these new tasks must also be completed by the end of the 5 week Cycle.
At the end of the 5 week Cycle, the team presents the valuable results it has produced to the charity staff/stakeholders. Any insights, observations, corrections, etc. are factored into the next Cycle Plan.

II. Communication Tools

Over the time we have worked together, the volunteer team has decided to use a few tools to help us communicate. The main tool is the task wall and sticky notes. The secondary tool is a shared Gmail account.
NOTE: This list of instructions is a working, evolving document; it is not set in stone. Volunteers are encouraged to work together and adapt the way we do things to create a system that works well for all of us.
ACCOUNT INSTRUCTIONS:
  1. Login and read new messages
  2. Emails in the Inbox means there is work to be done (if the task is complete, archive the email to remove from the Inbox aka the To Do List)
  3. Apply Labels – Gmail doesn’t use folders; it uses labels instead. Apply labels to emails to assist other volunteers with how to treat the content of that message.
  4. Write up volunteer tasks for the task wall (Note: Label as “Task Written & Posted”)
  5. Get work done:
  6. Move the task on the wall to in progress
  7. If the task came from an email, label the task with your name
  8. When the task is complete, label as “Task Complete” and archive the email so it doesn’t appear in the Inbox
CURRENT LABELS:
  • ??? – this means more information or context is required to understand the request –> ASK QUESTIONS, or get help, to complete the task
  • By Volunteer Name –> This means the task/email is in progress; A volunteer labels the email with their name when they accept responsibility for a particular task
  • FYI (For Your Information) – these are emails that contain information that is relevant to volunteers, but does not necessarily require action be taken. If action is required, write up a task and post it on the wall)
  • Task Complete – Use this to label When a task is complete; archive the email so it doesn’t appear in the Inbox
  • Task Written & Posted – apply this label after you write up the task and post it on the wall
  • Social Media – these are emails that apply specifically to social media like Twitter, Facebook, etc.
  • Website – these emails are relevant to website updates

III. What is 60/40 Time?

There are many reasons why people volunteer.  Here is a short list that comes from Molly Schar’s article Making the Most of Nonprofit Volunteers:
  • Belief in the mission of the charity
  • Desire to “give back”
  • Meet new people
  • Make new business contacts
  • Invited or inspired by another volunteer or staff member
  • Improve resume
  • Learn new skills
  • Benefits such as free events
We want all of our volunteers to get the most out of their experience here. Rather than insisting that every moment of a volunteer’s time be spent on completing tasks on the wall, we ask you to split your time 60/40. We want to give our volunteers freedom to spend a large portion of time doing things that satisfy their motivations while still providing value to the organization. For example, if someone has an interest in building skills in using social media, but there aren’t currently any tasks on the wall related to social media. The volunteer would be encouraged to use 40% of their time using social media to benefit the charity. The remaining 60% of the time is essential for delivering other important results to the organization. We aspire to having a trusting environment, so it is up to you to monitor how you’re spending your time. During progress updates, all volunteers are encouraged to share what they’ve accomplished during their 40% time. This will help other volunteers to learn what motivates their teammates and will give the team information that can be integrated into future Cycle Plans.

Are you interested in exploring ways Agile methods can be applied to all types of work, not just software development? Then I invite you to join me in contributing to the Agile Service Project in Toronto.

I’m looking for people who would join me in volunteering a specific, short period of time (aka. weekend, iteration, sprint, cycle) to a good cause in Toronto sometime in summer 2010.  We will work together as a team to deliver something of value to the cause, and in the process, we’ll gain experience applying Agile beyond software.

Here are some ideas for service projects that we can deliver with Agile methods:

  • host a fundraiser
  • do a community clean-up
  • canvas a neighborhood to raise awareness
  • fix a run-down playground
  • do a native tree planting
  • spruce up a local senior’s residence

While this is just a short list, the web is full of ideas for community service projects. Check out this list: 366 Community Service Ideas

The project we take on depends on the committed participants. Drop me a line and let’s use our Agile experience and skills to do something meaningful for our community.

There are numerous resources on the web that cover traditional ways of looking at volunteer management. However, there is very little written about how one might create a job description for a volunteer at an Agile non-profit organization. Here’s a little comparison of the two perspectives:

The traditional human resource approach puts volunteer job descriptions in the context of the organization’s strategic plan. Proponents essentially say:

  1. develop a strategic plan
  2. decide and document the tasks needed to carry out the plan
  3. decide if you need volunteers to do those tasks given your constraints
  4. create a job description of those tasks
  5. recruit the volunteer to fit the job description
  6. train the volunteer so they’re clear on your expectations
  7. monitor to see if the volunteer is meeting your expectations

The traditional human resource approach says everyone should have a job description that lays out the organization’s expectations and the person’s specific duties. The underlying idea is that people are more likely to give their time when they know what they will be doing. People also want assurance that their work is important and contributes to the goals of the organization. Without this comfort and confidence, they will be unsatisfied with the volunteer opportunity and will do a poor job, leave the organization, or worse, do some damage to the organization’s reputation.

An Agile Approach

Thanks to OpenAgile, Agile is not just for software development anymore, and many of the practices seem to be a strong fit for maximizing resources at a non-profit organization, especially when it comes to managing volunteers. Some of the principles underlying an Agile approach are to avoid excessive bureaucracy, long-term planning, and static role definitions. Proponents of Agile think of job descriptions as guidelines rather than requirements. An Agile process to managing volunteers could look something like this:

  1. the organization starts with a goal
  2. begin working toward the goal with anyone who is committed to doing the work (the “team”)
  3. as the team works through successive iterations (cycles of action, reflection, learning, and planning), the team learns what they need to be more efficient and effective
  4. if the team learns that they need specific skills, the team makes obtaining those skills a priority and they learn the skill themselves or seek someone with those skills to contribute to the work
  5. if a volunteer is interested in contributing to the work, the team can decide if the skills that person offers matches what the team needs to do their work
  6. welcome the skills and interests of the new team member and continue working towards the goal

Agile encourages organizations to use cross-functional teams composed of people who are committed to doing the work and willing to experiment by trying and learning. In an Agile environment, the team focuses on the goal, not their personal job descriptions. Team members are free to complete any task they want. For example, imagine a task for doing some work on a website. I may not have experience to complete the task easily, but if I’m free to try. It’s possible that I’ll learn something new that will make it easier to complete the task the next time. As they work, volunteers develop competencies and skills that complement those of the other members of the team.

Template for creating a job description for an Agile volunteer:

Position: Team Member

Purpose: To provide value to the stakeholders of the organization (ex. staff, community members, constituents, frontline workers)

Primary Duty: To aggressively learn and experiment to improve the ways the organization does work. This applies to all aspects of our work, including: stakeholder relationships, organizational effectiveness, process and tool efficiency, skill and capacity building, and underlying conceptual framework.

Secondary Duties:
To work jointly with all team members to help achieve the organization’s goals
To engage with the team members to create and commit to a Cycle Plan
To use your knowledge, interests, and skills to help the team complete the work in the Cycle Plan
To participate in regularly scheduled progress meetings with the team
To help the team to keep its commitments to the organization and its stakeholders
To make sure that the work done holds to the organization’s standards

Interesting Resources for Further Reading:

Agile:

OpenAgile – The OpenAgile Primer

Scott Ambler, Agile Modeling – Generalizing Specialists: Improving Your IT Career Skills

Mishkin Berteig, AgileAdvice – The Wisdom of Teams and”generalizing specialists”

Susan M. Heathfield, About.com Guide – Are You Ready for an Agile Future? An Agile Organization Embraces Change

Traditional:

Community Services Council Newfoundland and Labrador – Volunteer Management Resources

Joanne Fritz, About.com Guide – Before You Recruit Volunteers

Mary V. Merrill, World Volunteer Web – Developing volunteer job descriptions

For the past several weeks, I have been helping a small charity solve a dilemma. Because the charity is well-recognized for their good work, they regularly attract volunteers who want to help. Unfortunately, the two overworked staff members are too busy to recruit, train, and manage them. My approach has been to use OpenAgile, an open source system for delivering value to stakeholders, to implement a few simple techniques to help them.

There are several aspects of OpenAgile that fit very well for managing volunteers:

1. Self-Organizing Behavior

This means people “volunteer” for tasks instead of doing them based on a tightly defined role or having someone tell them what to do. This frees the staff from having to assign work. Instead, they identify priorities and rely on the volunteer’s creativity and personal motivation to do the task in their own way.

2. Shared Responsibility for the Workload

When there is more than one volunteer, they work in a team and share the responsibility for the workload. The team of volunteers discuss the priorities of the organization, and decide among themselves what tasks need to be completed. Then, they create and commit to a 1-2 week short-term plan that will deliver those results. Finally, they come back after the 1-2 week period and reflect on what they accomplished.  This pattern of action, reflection, learning, and planning is one of the Foundations of OpenAgile.

3. Visible Tasks

This means that all people doing the work should be able to see what tasks needs to get done, what is in progress, and what tasks are done. One technique that co-located teams often use is simply posting tasks on a wall using sticky notes. (Check out my OpenAgile Task Wall Prezi) Another cool idea is Card Meeting which works on the same principle, but it can be useful for distributed teams.

4. Learning Manifesto

The emphasis on learning is perhaps the most important aspect of OpenAgile that aligns with the needs of volunteer management.  The Learning Manifesto states that “Learning is the key that unlocks human capacity.”  Volunteers are drawn to an organization because of its vision but can get pushed away when they feel they’re underutilized or not able to contribute in a meaningful way.  By making it explicit that the volunteer is primarily accountable for learning, the organization creates a safe space for experimentation and innovation.

%d bloggers like this: