A close associate, David Parker, has written a great little article about the use of agile methods in volunteer management.
Posts Tagged ‘Learning’
Agile for Social Innovation and Volunteer Organizations
Sunday, March 14th, 2010Case Study: OpenAgile for Charity Volunteer Management
Friday, March 12th, 2010Cross-posted from my personal blog: A Changemaker in the Making
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.
Great Article on Shu-Ha-Ri
Thursday, March 4th, 2010Christian Gruber, a Googler, an agile guru and an Aikido practitioner clears up some important mis-understandings about Shu-Ha-Ri as applied to both learning Agile and learning Aikido: http://bit.ly/bqgvZS . Strongly Recommended!
ANN: June Agile Software Engineering Practices
Monday, May 25th, 2009Isráfíl Consulting Services is pleased to announce our upcoming:
Agile Software Engineering Practices Courses (2 day)
Software Developers, Technical Architects and Lead Developers for teams that currently use or are intending to use Agile methods such as Scrum, Extreme Programming or OpenAgile will benefit from attending this course.
After completing this course you will:
- increase your development productivity
- be familiar with basic disciplines to create well-tested, defect-free code
- be able to integrate successfully into Agile teams
- understand what makes healthy, maintainable code
- receive a Certificate of Attendance
- receive $100.00 discount on a 3-day Scrum training and certification course by our partners
Available Classes:
- 2009-06-22: 2-day Agile Software Engineering Practices – Ottawa, ON $1450.00 CAD [16 spaces]
-
- Register by June 1 and get the early-bird price of $1,250.00.
- 2009-06-25: 2-day Agile Software Engineering Practices – Markham, ON $1450.00 CAD [16 spaces]
-
- Register by June 1 and get the early-bird price of $1,250.00.
Register!: http://www.israfil.net/publictraining/registerCourse Details: http://www.israfil.net/publictraining/coursesClass Schedules: http://www.israfil.net/publictraining/scheduleFor more information, please e-mail us at: training@israfil.net
The Definition of “Done” is Badly Named!
Thursday, January 22nd, 2009In Scrum, there is a concept of the “Definition of ‘Done’” that is used to understand what teams produce every Sprint. Unfortunately, it is not well understood, nor is it consistently applied. Part of the problem is that the name of the concept is misleading. Every time we do coaching or training in organizations, we spend an inordinate amount of time getting this concept across clearly. Recently, one of our coaches, Travis Birch, had an insight about the name of the concept. The word “definition” makes us think of something static and permanent. Definitions don’t normally change. However, in Scrum, the definition of “done” is always changing. Doneness is not something that we get perfect at the start, rather, teams develop their capacity to deliver more and more each Sprint… and not just in terms of features. As I explained in another article called Four Methods of Perfecting Agile, the definition of “done” is something that can and should grow over time.
So what can we do? Can we rename the concept? The concept is really a snapshot description of the activities and attributes that a team puts into a Sprint’s worth of work. For example, at first a team might not be writing automated unit tests. Therefore, automated unit tests are not part of the definition of “done” – a snapshot of their work at the end of the Sprint does not include automated unit tests. Then in a retrospective the team decides that they need to create automated unit tests. They do so in the next Sprint. Now, automated unit tests are a part of the definition of “done”. Finally, a few Sprints later, one of the members of the team attends Agile Software Engineering Practices training [shameless plug] and decides that they should start doing test-driven development. The team learns how to do this and from now on the definition of “done” includes test-driving all production code.
<strong>A New Name</strong>
Let’s try another name for this concept: the “Expanding Benchmark”. I think this term much more accurately conveys the sense of the concept. It is expected that this concept is not static, rather, as the team overcomes obstacles, automates things, learns new skills, and gains new trust and authority, that their work will expand. And specifically, we are expanding the benchmark of what activities and attributes of software are delivered at the end of each Sprint.
So – let’s get rid of the Definition of “Done” and start talking about a team’s Expanding Benchmark. What sayest you?
The Importance of Questions
Tuesday, October 28th, 2008I’m currently doing some coaching work with Regina, a new project manager working with a small team of web developers at a community development organization in Toronto. We had our first session last week. Regina was having trouble getting started on a particular project and I shared with her some of the Agile methods of creating a prioritized Cycle Plan, breaking it down into small tasks, etc.
Regina seems to be finding Agile methods helpful in general, but there was a special kind of interaction that we had around removing an obstacle that was particularly interesting for me. It had to do with an email she received from Peter, a developer working on one of the websites she’s managing. Regina shared a concern that she didn’t know some of the technical terms Peter was using. So I had her read through the email and form questions around the points she wasn’t clear about – i.e., “what are buttons?” and I wrote them down as she was speaking.
I then suggested that she compose a reply email containing the same set of questions. Regina’s eyes opened wide and she exclaimed, “Oh yeah – that’s so obvious!” I went on to mention that another option would be to go and do some research on her own but that there were some valuable advantages in asking Peter directly, particularly in terms of team-building, that may not be as immediately apparent as asking the questions solely for the purpose of having them answered. Here are a few:
First, it’s a way forRegina to remind Peter that she does not have a technical background and that he should not assume that she is familiar with web-lingo. Second, it also reminds him that she is a different person from the last manager he was working with and subtly reinforces that it’s important that they get to know each other as two individual human beings and learn to work together effectively. Third, and perhaps most importantly, it gives Peter an opportunity to help someone else on the team learn something new, and by doing so, contribute to the culture of learning on the team. Fourth, and perhaps most obviously, it promotes open lines of clear communication on the team.
(Of course, if the team was colocated, which it is not, lack of communication would be much less of an obstacle!)
Asking questions in the interest of learning makes it visible to others that you don’t know everything. For some people, this presents a dilemma. What makes it a dilemma is that asking meaningful questions is something that many people aren’t able to do well. The ability to ask meaningful questions is a learnable skill requiring the capabilities of truthfulness, humility and courage. Such capabilities – let’s call them moral capabilities – can themselves be developed through conscious, focused effort.
Someone in the position of a newly hired manager, or a veteran manager with a new team, who lacks these capabilities may feel that it is important to present to a team a persona of all-knowingness. But, of course, this is false and the truth of one’s degree of knowledge and capability, or lack thereof, soon becomes apparent anyway. Clearly, this person needs to do some honest hard work to develop some humility, but truthfulness and courage are still often major factors.
Or maybe you’re the kind of person (like Regina) who just doesn’t want to bother anyone. In this case, humility is not necessarily lacking, but truthfulness – and perhaps most of all courage – may need some attention. Concepts around moral capabilities deserve much more elaboration, but for the sake of brevity, I’ll leave it at that.
To sum it up, if you are open and clear in the way you ask questions, people will tend to appreciate it and will trust you more in the end. Moreover, it can have a transformative effect on the environment of the team. When your team members realize that you are not afraid to ask questions and be truthful about your lack of knowledge in a certain area, it will encourage them to be more truthful about their own capabilities. Not to mention that most people feel good when they are able to help others. When your team members feel safe to ask for help and free to help each other, it is empowering for everyone.
Asking meaningful questions, therefore, is an essential aspect of learning together, and nothing is a more powerful contributor to the success of an organization than a team that learns as a team.
Agile Benefits: Five Essential Reasons to Try Agile
Monday, September 24th, 2007Although there many other benefits of agile, and although those provide us with other reasons to try agile, the five essential benefits of agile are:
Rapid Learning – disciplined application of the scientific method to explore the best ways to deliver valuable results.
Early Return on Investment – opportunity to use the results of work starting with the work delivered at the end of the first iteration.
Satisfied Stakeholders – engagement in the process in a way that allows meaningful contributions from all stakeholders.
Increased Control – mechanisms to track/measure and therefore steer the direction that work is going so that it meets goals.
Responsiveness to Change – processes, tools, roles and principles that allow a team and an organization to embrace change rather than reject, control or suffer from change.
These reasons are sufficient and apply to operations work, project work and open-ended research work, whenever humans are involved. The above links take you to more detailed descriptions of each of these benefits.
What are some of the other benefits of agile?
Agile Retrospectives and the Plan of Action
Thursday, August 30th, 2007Bas Vodde has published a good article about making goal oriented action plans for agile projects. It is a nice piece of the puzzle on how to do effective retrospectives. It also nicely ties into the “Learning Circle” Reflection/Learning/Planning/Action steps.
Strategic Plan
Thursday, February 22nd, 2007Okay, this is only marginally related to agile, but I thought it was interesting nevertheless: How to Write a Detailed Strategic Plan. The main connection to Agile Work, is that you need to have a clear performance goal in mind towards which you are working. This may be a great way to clarify your thoughts about such a goal.
Learning Vocabularies
Tuesday, February 20th, 2007Last April I wrote a brief article showing the relationship between five different learning models. I’ve discovered two more for your edification:
The Shewhart (Deming) Cycle of Plan, Do, Check, Act
and the Six Sigma DMAIC cycle: Define, Measure, Analyze, Improve, Control
I find it so interesting that the same basic ideas have circulated (no pun intended) in so many different disciplines for so many years. Does anyone know if there is a good description of a universal / abstract cycle of which all the others could reasonably be considered instances?
Cancelled Iteration
Monday, January 22nd, 2007First Interation Ending
Monday, January 8th, 2007My first iteration using Agile Work for my business development has come to a close. Here is what I did for a “demo” and retrospective.
Coaching and Agile Work
Thursday, January 4th, 2007Someone recently said to me that I should offer individual coaching assistance to people based on Agile Work. This would be completely non-technical life/profession style coaching. It’s an interesting idea. I don’t think I’m quite ready for it, but here are a few links to coaching, life improvement, and related things.
My First Challenge
Wednesday, January 3rd, 2007Wednesday is nearly done and I’m looking at my list of tasks and cringing! I’ve only done a few out of the forty for this week. What’s going on?!
How to Avoid Context Switching
Friday, November 24th, 2006Given the huge interest in the article by Dmitri Zimine about context switching, and despite a couple of good articles about how to determine iteration length, there has been no empirical method described, only reasoning processes. This article describes a simple method to quickly determine iteration length by experimental means.