Tag Archive: agile


Hello Reader,

I would like your insight on something. I’d like to start a Meetup.com group centered on OpenAgile, but I’m hung up on what it should be called and what the main aim would be. One reason I want to start a new group rather than tack onto another group is to try to attract people from other fields. There are already lots of agile and project management groups in the Bay Area, but there might be another audience for OpenAgile that we haven’t thought of. Also, beyond it’s popularity, a benefit of using Meetup.com is that the group can get sponsors and find some small means of funding itself.

I would welcome your feedback on these ideas or any others that you may have.

1) Bay Area OpenAgile Champions

Essentially, people who are working on developing OpenAgile would come together regularly to talk about the work in the current Cycle. This idea is more focused on keeping us in tune and engaged. Think community building as much as getting stuff done. Hmmm, we could probably do this without Meetup.com…

2) Agile Service Project (or “OpenAgile” Service Project?)

I tried to do something like this in Toronto, but it was hard to get off the ground. https://davidparker9.wordpress.com/2010/03/23/agile-service-project-toronto-2010/ I could see it working here. The audience that this would attract is project oriented, volunteer people. It would also give people who want certification in OpenAgile a way to get some hands on experience and be mentored through several Cycles.

3) New Economy Innovators (or Innovative Methodologies meetup)

Partly an attempt to move away from the word “agile” because it carries certain contexts – software, project management, technology – all very popular in the Bay Area. The focus would be on bringing people together who are coming up with new approaches to solving complex challenges. I spoke at a symposium in Toronto about this and got a very warm reception: https://davidparker9.wordpress.com/2010/04/14/the-story-behind-the-innovative-methodologies-session-april-28-in-toronto/ Truth is there are a lot of these kinds of meetups in the Bay Area as well.

So what do you think?

Advertisements

Last night I gave an Introduction to OpenAgile presentation to a warm and receptive audience in San Mateo, CA. The good folks at Agile Learning Labs sponsored the event by promoting it and feeding us delicious pizza. I can’t thank them enough for helping make last night possible. I also want to express my deep appreciation to everyone who attended and gave me their feedback and insights on the presentation itself.

We started the evening by dividing the audience into three groups who each discussed one of the foundations of OpenAgile – Truthfulness, Consultative Decision-Making, and the Learning Circle. It wasn’t required that each person read the OpenAgile Primer first. I wanted to see what insights would come from a discussion about what people understood about the concept in general rather than specifically what is stated in the Primer. This led to my biggest “aha” moment of the night. Even without reading the Primer, the groups were able to describe the essential characteristics of each foundation. They actually expressed several profound insights that aren’t covered in the text of the Primer itself but certainly could be. It’s like they just knew what the foundations mean. That says something to me about the intuitiveness of the OpenAgile framework. It also says to me that conversations about the foundations of OpenAgile can take place among people in many different environments.

After that exercise, I asked each person to write one burning question they have about OpenAgile on a sticky note. I would then try to answer as many of them as I could in the time remaining. Reading through the feedback forms I received, I recognize why some people found this to be a fairly unorthodox approach to a presentation. The questions they asked indicate that the audience members varied in their levels of experience with Agile methods. I found the range of questions and the ways the questions were phrased to be quite telling:

  • Does OpenAgile resonate with open source?
  • What are the advantages/disadvantages of OpenAgile?
  • Why would teams be more successful with OpenAgile than with Scrum?
  • Who invented OpenAgile and why?
  • Why another “Agile”?
  • What does the “Open” in OpenAgile stand for?
  • Who is currently developing OpenAgile?
  • How does OpenAgile relate to Agile?
  • How is OpenAgile different than other methodologies?
  • Why Open Agile? (I took this to mean why is OpenAgile open source.)
  • Why the “open” in OpenAgile? Is there a ClosedAgile?
  • About the Growth Facilitator role: When is it possible not to have one in a team/project?
  • What differentiates OpenAgile from Agile AND What, if any, are its advantages (and potential drawbacks)?
  • Is OpenAgile evolutionary or static?
  • Is OpenAgile a methodology or simply a philosophy that can be used by any methodology?
  • What types of projects can it be applied to?
  • What is the advantage of OpenAgile?
  • Creating Interest: How can you get adoption in naturally resistive cultures? Are their easy hooks or high value propositions?
  • Who is using OpenAgile right now (i.e. big companies, teams, etc.)?
  • What industries can use it?
  • About Growth Facilitator role: What is the difference between this role and the product owner role?
  • What type of projects would be benefited with OpenAgile? For example, product development, application development, customization?
  • Is “organic growth” analogous to “emergent design“?
  • Compare OpenAgile in a continuum of other Agile methods/frameworks like XP, Scrum, Kanban
  • How does OpenAgile compare with the other Agile methodologies?
  • Differentiate the different forms of Agile development
  • Is OpenAgile directed towards quality or just timeliness?
  • How can I apply OpenAgile?
  • What works best to establish OpenAgile in an existing workforce?
  • What is the role of leadership?
  • Describe its use outside software: manufacturing, hardware, non-high tech

The feedback form asked for a one or two sentence anonymous recommendation for others considering taking a similar presentation. I hope you enjoy reading them as much as I did getting them:

  • A new view on Agile in practice
  • Sharing thoughts with David and other attendees helped me better formulate my understanding of OpenAgile specifically and Agile in general. Thanks.
  • David modeled the simplicity, humility, honesty, and openness which the OpenAgile model represents.
  • Good intro to a brand new topic.  Made me want to learn more.
  • provides understanding of a variant of the Agile methodology which can be used outside of software development
  • Good initiation for OpenAgile
  • Useful for teams that have adopted agile and feel that it has not worked well.
  • Framework different approach
  • It takes the “there is no silver bullet” statement to a deeper level
  • Good to see the questions about how OpenAgile applies, sometimes better than, for example, Scrum.
  • David was patient and a very good listener. This helped answer many questions that came up.
  • David was able to instigate a lot of very interesting discussions and debates.
  • Thanks for the Pizza!

I have been studying the OpenAgile Primer. Even though I helped publish it and am actively working to improve the Primer and OpenAgile itself, there are lessons that can be gained from revisiting the concepts, terms, and insights over and over again. The OpenAgile Primer is a dynamic document that improves as OpenAgile grows and develops. Take that to heart as you read the outline below. I encourage you to study the Primer yourself and create your own summary. And when you do, let’s have a meaningful conversation about your own insights.

OpenAgile Primer Conceptual Outline

CHAPTER 1 – Foundations of OpenAgile

1) Truthfulness

“Truthfulness is the foundation of all human virtues” – Baha’u’llah
  • basic human capacity that everyone can develop
  • aspect of truthfulness
  • implications of truthfulness
  • how to develop truthfulness
  • benefit “truthfulness builds trust and leads to reducing excessive bureaucracy and chaos”
  • be aware of our own limitations (uses example of Six Blind Men and the Elephant)

2) Consultative Decision-Making

“We never undertook to do any thing of any importance which was likely to affect each other, without mutual consultation. We were generally a unit, and moved together.” – Frederick Douglass
  • a system for teams to take coherent action based on a unified vision
  • mindset for consultative decision-making
  • Rules of consultative decision-making
  • Unified Action

3) The Learning Circle

“Learning is like rowing upstream: not to advance is to drop back” – Chinese Proverb
  • a model of effective learning
  • Four steps: Reflection, Learning, Planning, Action
  • Four capacities: Detachment, Search, Love, Courage
  • Guidance

CHAPTER 2 – OpenAgile Process

systematic application of the Learning Circle

Goals

  • work is done to accomplish a goal
  • nature and importance of goals

Work in Cycles

  • Cycle is a step towards a goal with the purpose of producing value
  • Three rules of working in Cycles
  • 1) apply the Learning Circle to every Cycle
  • 2) work in Cycles of equal length
  • 3) work in short Cycles

Cycle Input: Value Drivers

  • definition of “value”
  • tip for articulating a Value Driver
  • work on Value Drivers in priority order
  • explanation of traditional value delivery (Project Management)
  • difference between Organic and Mechanical systems
  • application of the Learning Circle ensures that we continue to do valuable work

Engagement Meeting

  • start of every Cycle
  • review our Goal and the list of prioritized Value Drivers
  • break down Value Drivers into tasks
  • duration of the Engagement Meeting
  • Reflection during the Engagement Meeting
  • Learning during the Engagement Meeting

Cycle Plan

  • collection of tasks derived from the Value Drivers that we intend to do during the Cycle
  • awareness of our capacity to complete the tasks
  • a note about perfection
  • volunteering for tasks
  • commitment to the Cycle Plan

Core Types of Tasks

  • Calender Events
  • Repetitive Activities
  • Quality Problems
  • Obstacles
  • New Artifacts
  • commitment to the Cycle Plan

Inside a Cycle

  • completing tasks in the Cycle Plan
  • importance of maintaining a positive attitude
  • volunteering for tasks
  • tracking progress and Progress Meetings

CHAPTER 3 – The Participants in OpenAgile

  • only one role: the “Team Member” who does work as part of the Cycle Plan
  • there are “Paths of Service” – engaged participants who serve a team or organization

Paths of Service

Process Facilitator

  • help us follow rules
  • help us develop capacity to apply the principles

Growth Facilitator

  • grow capacity and value of the team
  • valuable input and output from every Cycle
  • prioritize Value Drivers
  • engage with Stakeholders

Advanced Capacities

  • Mentor, Tutor, Catalyst work outside a Team and provide Guidance
  • (Personal Reflection: Should this be reworded to “Advanced Paths of Service”?)

OpenAgile Teams

Self-Organizing Behaviour

  • volunteer for tasks
  • be open to following Guidance

Success Factors for Productive OpenAgile Teams

  • small number of people (less than 12 team members)
  • complementary skills
  • common purpose; commitment to the overall Goal as well as the Cycle Plan
  • have specific performance goals; be able to measure our results
  • agree how you’re going to work together
  • make and keep commitments; adjust our behaviour as we learn

Large Groups

  • communities and organizations can use OpenAgile to achieve goals that are beyond the ability of small teams
  • use longer Cycles
  • have Teams within the group that use shorter Cycles

Stakeholders

  • recipients of the value being delivered
  • (Reflection: Should this be reworded to “co-creators” of value? Get feedback from the OpenAgile Champions)

Chapter 4 – How to Start?

  • get some people together, read the Primer, have an Engagement Meeting
  • but if you desire more preparation…

Before Your First Cycle

  • decide who will participate (strive to have people complimentary skills)
  • generate and prioritize a list of Value Drivers
  • give thought to the work space and tools for collaboration
  • what is your Goal?
  • Cycle duration and start of first Cycle?
  • do you need help from a Tutor, Mentor, or catalyst?
  • get Team Member training

Your First Cycle

  • be realistic
  • at first, you won’t know your capacity to make and keep commitments
  • it’s okay to feel awkward
  • get help from someone who can accompany you

The Most Important Advice

  • Just start!
  • systematic, incremental improvements are inherent in the system
  • you will get better as you go
Cross-posted from www.openagile.com, this is an interview I conducted with Mishkin Berteig, Co-Founder of Berteig Consulting, about the world’s need for an open source agile methodology. Along with Mishkin and myself, there are 20 other dedicated people who have arisen to serve the OpenAgile Community as champions. They’re applying OpenAgile to many different environments and sharing what they’re learning so we can improve the methodology.  For example, Barry Turner of Turner Agile Project Solutions is implementing this approach at a small town museum, and Jim Heidema of Professional Sales Plus has been active in using OpenAgile in the financial services industry. Everyone is welcome to get involved and contribute.

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.

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.

Another article in a series intended to briefly explain how to apply different agile practices to work in social purpose organizations, today’s topic is: The Agile Workspace

Agility requires that we create an environment that is conducive to fruitful interaction. The most efficient and effective method of conveying information to and within a value delivery team is face-to-face conversation. Team effectiveness increases as barriers to communication decrease.

An agile workspace is anti-cubicle farm. It provides a mixture of collaborative, social, and private space. The collaborative space at the hub of activity is the “team room”. The ideal team room can be easily reconfigured based on the team’s needs. Team members face each other, usually at tables in the center of the room. Walls are used for posting notes, displaying charts, graphs, and the results of brainstorms. There should also be space for writing or drawing, such as a white board or chalk board, so that team members can creatively express and capture their ideas and progress. Social space in an agile work environment should include things to make the team members comfortable, such as a kitchen with snacks and a good coffee machine. Finally, it is helpful to have a nearby room for private conversations or to allow team members to “check out” if they need to focus or clear their head.

The folks at Sustainability Studio in Toronto have a beautiful agile workspace. The architects used modular walls that can be reconfigured as needs change. There is also a ton of natural light and the freedom to open a window for some fresh air. Take a look at the pictures. Just throw some sticky notes on the wall, and you would have what I’m talking about.

One question that inevitably arises is “what do we do if we can’t get everyone together?” Remember that learning is the means by which you achieve agility and deliver value to your stakeholders.  It is okay to accommodate distributed team members as long as you do your best to adhere to the principles of collaboration and consciously learn from the process.  For instance, if you usually have a weekly team meeting by phone, try getting a webcam and do a video Skype chat instead. This way the distributed team members of your team can have that extra visual connection. After trying this tool, reflect on its use and see what you learned from the experience. If you find something that works well, don’t change a thing. And if something didn’t work, try something different.

For more reading on agile workspaces, and plenty of pictures to inspire you, I recommend:

MIT School of Architecture + Planning The Agile Workplace: Transforming Work and the Workplace

The Ideal Agile Workspace | Mike Cohn’s Blog – Succeeding With Agile

The “Best Agile Work Space” Contest | Analytical-Mind

Would you like help becoming more agile?

If you would like help transforming your space to an Agile Workspace, or assistance with adopting any other agile practice, 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.

Part of a series intended to briefly explain how to apply different agile practices to the work of social innovators, today’s topic is Using Self-Organizing Teams instead of Groups:

In a traditional work setting, there is a manager who oversees a group of people with specific role definitions. There is a one way reporting relationship. If you can imagine a pyramid-shaped org. chart, you’ve got the basics.

Agile works on the principle of self-organizing teams.  In an agile work setting, the members of the team organize the work tasks among themselves.  They volunteer for tasks and hold each other accountable for completing the work. The manager, who is not necessarily on the team, is responsible for giving the team the support they need to do the work. The trust invested in the team has a huge payoff for the individual team members and the organization in terms of productivity and satisfaction.

There are two primary reasons I believe social innovators would be attracted towards self-organizing teams: efficient use of people resources and creating a culture of empowerment.  It is more efficient to have a team of equals who have a unified vision and who produce valuable results for their stakeholders instead of a group of individuals with a singular view defined by their job description that produce results for their manager.  An organization with a culture of empowerment draws on the capacities, experiences, and motivations of impassioned individuals and gives them the tools required to produce valuable results and change the world for the better.

I wrote about my experiences applying this approach to the work of a volunteer-driven charity in the article Agile Approach to Volunteer Management

Would you like help becoming more agile?

If you would like help building Self-Organizing Teams in your organization, or adopting any other agile practice, 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.

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

%d bloggers like this: