A close associate, David Parker, has written a great little article about the use of agile methods in volunteer management.
Posts Tagged ‘agile’
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!
Agile 2010 Session Proposal: TDD for iPhone Development
Monday, February 8th, 2010I’ve just submitted a proposed session to the Agile 2010 web site:
Test-Driven Development for the iPhone, iPod and iPad
Please go to the site and let me know in the comments there if you have any suggestions about the proposal!
Comparison of OpenAgile with Scrum
Monday, February 1st, 2010OpenAgile is similar to Scrum in many respects. Both are systems for delivering value to stakeholders. Both are agile methods. Both are frameworks that deliberately avoid giving all the answers. So why would we choose OpenAgile over Scrum?
The most important difference is in applicability: Scrum is designed to help organizations optimize new software product development, whereas OpenAgile is designed to help anyone learn to deliver value effectively.
OpenAgile is an improvement over Scrum in the following ways:
-
More effective teamwork and team practices, in particular the Consultative Method of Decision Making, and
applicability over a larger range of team sizes from a single individual on up. -
Recognition of the individual capacities required for effective learning, namely Truthfulness, Detachment,
Search, Love and Courage. Scrum acknowledges a separate set of qualities, but does not show how they systematically connect with the requirements of a Scrum environment. -
Systematic handling of more types of work beyond just “new artifacts” and “obstacles”. In particular, OpenAgile includes calendar items, repetitive items and quality items and acknowledges their unique qualities in a work
environment. OpenAgile also provides a framework to include additional types of work beyond these five. -
Improved role definitions based on extensive experience.
-
There is only one role defined in OpenAgile (Team Member) vs. three defined in Scrum (Team Member, ScrumMaster, Product Owner).
-
There are multiple paths of service that allow Team Members and Stakeholders to engage with an OpenAgile team or community in different ways. There are five paths of service: Process Facilitation, Growth Facilitation, Tutoring, Mentoring, and Catalyst.
-
The Process Facilitator path of service is similar to the ScrumMaster role with the following major differences:
- is not responsible for team development
- is not necessarily a single person, nor is it a required role
-
The Growth Facilitator path of service is similar to the Product Owner role with the following major differences:
- is responsible for all aspects of growth including value (like the Product Owner), and individual and team capacity building.
- is not necessarily a single person, nor is it a required role
-
-
Integration of principles and practices from other methods. Two examples suffice:
-
From Crystal: creating a safe work/learning environment.
-
From Lean: build quality in, value stream mapping, root cause analysis, standard work.
-
-
OpenAgile allows interruptions during the Cycle. Scrum has the concept of Sprint Safety. This makes Scrum
unsuitable for operational work and general management. -
The distinction between Commitment Velocity and other uses of the term “velocity” used in Scrum. Commitment Velocity is the historical minimum slope of a team’s Cycle burndown charts and determines how much work a team plans in its Engagement Meeting.
-
Flexibility in the length a Cycle. Scrum requires that Sprints (Cycles) be one month in duration or less.
OpenAgile allows a Cycle to be longer than that and instead provides a guideline that there should be a minimum number of Cycles planned in the time expected to reach the overall goal. -
The Progress Meeting in OpenAgile does not require people to take turns or directly answer specific questions.
-
Avoiding conflict-oriented models of staff and management (Chickens and Pigs in Scrum).
-
Terminology changes to be more clear in meaning and applicable beyond software. A comparative glossary is
included below.
Another major difference between OpenAgile and Scrum is how the community operates. OpenAgile is an open-source
method that has a specific structure for community involvement that allows for continuous improvement of the system. Scrum is closed. It is closely managed by it’s founders and this has led to challenges with the method becoming dogmatic. OpenAgile is meant to constantly evolve and grow.
Comparative Glossary between OpenAgile and Scrum
| OpenAgile | Scrum |
|---|---|
| Cycle | Sprint |
| Cycle Planning | Sprint Planning and Sprint Review |
| Team Member | Team Member or “Pigs” |
| Process Facilitator | ScrumMaster |
| Growth Facilitator | Product Owner |
| Work Queue | Product Backlog |
| Work Queue Item | Product Backlog Item |
| Cycle Plan | Sprint Backlog |
| Task | Task |
| Work Period | Day |
| Progress Meeting | Daily Scrum |
| Learning Circle w/ steps | “Inspect and Adapt” |
| Delivered Value | Potentially Shippable Software |
| Stakeholders | “Chickens” |
| Five Types of Work:
New, Repetitive, Obstacles, Calendar, |
- no equivalents -
User Stories, N/A, Impediments, N/A, N/A |
| Consultative Decision Making | - no equivalents - |
| Sector / Community | - no equivalents - |
References on OpenAgile:
References on Scrum:
http://www.scrumalliance.org/
http://www.scrum.org/
“Agile Software Development with Scrum” - Schwaber and Beedle
“Agile Project Management with Scrum” - Schwaber
“Scrum and the Enterprise” – Schwaber
Agile/Pervagile on Slashdot
Monday, November 16th, 2009There is a book review of “Becoming Agile” by Smith and Sidky on Slashdot. I haven’t read the book (yet) so I can’t comment on the book nor on the review. However, I did want to comment on the comments of Slashdot users. Their experience with agile methods seems to be terrible. Either that or they are incredibly ignorant and have pre-judged agile. Since I know that (most) Slashdot users are pretty intelligent, I’m going to assume that they have mostly just had really terrible experiences with agile.
The Agile Manifesto values “Individuals and Interactions” over “Processes and Tools”. Many of the comments were about agile being used as a cudgel to beat teams into submission. No matter what anyone says, this is not agile. This is perverted agile or “Pervagile”. Pervagile is common. Scrumbutt is one form of Pervagile. Waterscrum is another form of Pervagile. Scrummerfall is yet another. But there are many other forms as well: the Pervagile Sweatshop where teams are forced to meet arbitrary scope in one week deadlines, the Pervagile Common Room where people on many different projects are forced to work in an open space, and the Pervagile Silo Team where only developers are doing agile and everyone else is in their normal functional silos.
On Slashdot we see some interesting comments like this one:
So we’ve gone from over-designing systems to under-designing systems.
How about right-designing a system based on the complexity of the scope and the key personnel involved?
Is that crazy?
No, it’s not crazy, and that’s what agile is trying to help us to do. Pair programming, test driven development, potentially shippable software, continuous integration, agile modeling are all agile practices that help us “right-design” a system. So this person must have experienced a team doing Pervagile Minimum Discipline where all good practices are not just done in small bits along the way, but actually ignored. I’m not sure why they ignored doing good incremental design – perhaps someone told them that agile doesn’t require good design skills on the team!
Here’s another interesting comment:
The attempt to write a Python implementation in Python, PyPy [codespeak.net], turned into a death march. The project has been underway since at least 2003 (when they had their first “sprint”), never produced a usable system, and the European Union pulled the plug on funding. But the project limps on. There’s a released version. It’s slower than CPython. There’s supposed to be a “just in time” compiler Real Soon Now. (This is try #2 at a JIT, not counting the schemes for outputting Java bytecode and Javascript.) Six years in on a compiler project, and no product.
The PyPy project is very “agile”. They have “sprints”. They have “flexibility”. They have nightly builds. They have mailing lists and trackers. They support multiple output back-ends. They have about 50 contributors. What they don’t have is a usable product.
Hmm. Sounds like they’re trying to do Scrum. But they’ve missed a pretty critical piece: potentially shippable software at the end of _every_ Sprint. I have no idea why they aren’t able to do that, but I imagine that if they really understood Scrum, they would be in a much different place at this time. This is a clear case of Pervagile Valueless Deliveries where the team does stuff every iteration, but they don’t worry about delivering valuable results.
So. Pervagile is pervasive. That’s clear.
Why is it so pervasive? There are two parts to this: one, agile is hard and two, agile is mistaken for a silver bullet.
Agile is Hard
Okay, I’m actually being a little dis-honest. The real truth is that doing agile is extremely, exceptionally, agonizingly difficult (for most people in most organizations). Why? Because agile is not just another process to roll out. It is, as has been mentioned in numerous places, a deep cultural change. Agile is actually a liberation movement for people involved in software development. Like most movements, however, it has been subject to corruptive forces.
Agile is Mistaken for a Silver Bullet
Agile is Hard, and therefore it cannot possibly be a silver bullet. Many executives and managers hear about agile and want to do it in their organization because they have heard the amazing success stories (yes, they do exist – scroll to the bottom to learn about Wildcard Systems). But what often is not effectively communicated is how much crisis, how much effort, how much radical change went into these success stories. Here’s a hint: if you think a large organization can become agile in less than five years, you’re fooling yourself. Even a very small organization should expect at least two years of solid effort before the changes really take hold. Of course, if you are lucky enough to be starting from scratch, then you might do better than this.
I’m pretty tired of people mis-understanding agile methods. But unfortunately this is the reality of our work landscape. I would love to work with a client where the CEO has said something to the effect of “I’ve budgeted 10% of our operations and ten years to do our agile transformation.” Of course, that’s pretty much a laughable wish. Unfortunately it’s the reality of the effort involved for most organizations.
New Certified Scrum Product Owner training in Toronto added to calendar
Wednesday, November 4th, 2009Due to popular demand, we have added another Certified Scrum Product Owner (CSPO) training to our listing of courses. There is an overwhelming need for well trained Product Owners, and we’re happy to take up the challenge. The next CSPO will happen on January 14 & 15 at our office in Newmarket, just north of Toronto.
During this seminar, our Certified Scrum Trainer will teach participants how to do the fundamental tasks of the Product Owner in the Scrum environment. The attendees will learn:
- how to develop a comprehensive Product Backlog
- competently add value to the Scrum team during the Sprint
- fully understand how Scrum works and their role within the agile environment
With a maximum class size of five people, this seminar is designed to allow participants to dig deep into the role of the Certified Scrum Product Owner. After completing this course, attendees of this seminar will be able to create and manage a Product Backlog, work with a Scrum Team to create high-quality software, and use the Scrum framework to build and deliver the right software. Please refer to our website for a course description and to reserve space for yourself or others on your team. http://www.berteigconsulting.com/CSPOCourseDescription
We look forward to adding value to your team!
If you would like more information contact us at sales@berteigconsulting.com
Excellent little article – Technical Debt on your Balance Sheet
Friday, October 2nd, 2009Quick Note on Scrum Training
Wednesday, September 23rd, 2009We have wrapped up our Summer Special. There are still a few classes scheduled this year that have the discount price, but others have reverted to our normal price. I encourage you to take a look at our course schedule at http://www.berteigconsulting.com/ to see what is still available.
Also, all our future Certified ScrumMaster courses will have a knowledge test as part of the certification process. Please see the Scrum Alliance website for more information at http://www.scrumalliance.org/.
Project Defibrillation
Wednesday, September 23rd, 2009Imagine your father is in surgery for a routine tonsillectomy. Something goes wrong with the anesthesia and his heart goes nuts. The defibrillator is brought out, the paddles applied to your father’s chest and the surgeon yells “CLEAR!”. He triggers the defibrillator, but nothing happens, just a small clicking noise. He quickly checks the machine, and everything looks okay. He tries again. “CLEAR!” There’s a small buzzing noise and your father’s body trembles slightly. The surgeon puts the paddles down, and, getting frantic, yells at the nurses to find another defib machine, “NOW!!!”. Thirty agonizing seconds pass. One of the nurses rushes into O.R. with a cart with another defibrillator machine on it. It gets set up. Another fifteen seconds pass. It charges and the surgeon applies it again. “CLEAR!” There’s a huge shock and your father is killed instantly. It takes a few more minutes for him to be officially pronounced dead.
Is this how projects are run in your organization?
If this had been a description of a real event, you would be furious. You would demand that the defibrillators work better – one hundred percent of the time would be about right! You would sue the hospital for buying shoddy defibrillators. You would sue the company that made them. You would sue the surgeon.
Let’s stop running projects this way. Agile is a reliable defibrillator for your organization’s heart.
Agile Tour 2009 – Toronto
Tuesday, September 15th, 2009Berteig Consulting is a silver sponsor for the 2009 Toronto leg of the Agile Tour conference. The date for Toronto is October 20th. You can find more information at the Toronto Agile Community web site – http://www.torontoagilecommunity.org/.
50% Discount on ScrumMaster Training – Only 59 Spots Left
Tuesday, July 14th, 2009Our summer special is proving to be very popular! We started with 100 spots at our 50% discount price of CAD 995.00. We’re down to 59 spots. Check out our course listing page – every CSM course we have scheduled in Canada is available at this fantastic price (Toronto, Waterloo, Edmonton, Ottawa).
Even without the discount, our course is a better value than many out there. It’s a three day course instead of the normal two. This gives you a chance to really dig into the concepts and practices of Scrum and Agile Project Management. Our course is really designed for project managers, team leads and other managers, instead of being for anyone interested in Scrum. Of course, if you are interested in a leadership role, but aren’t there yet, you are still welcome to come!
Not only that, we don’t run courses in locations where it is not easy for use to support you after you take the course. We run our business in Canada, and our consulting and coaching work is there to help you if you want further assistance with doing agile in your organization. Even if you aren’t in Canada, maybe your organization has a group in Canada or you have professional contacts in Canada – if so, let them know about this fantastic opportunity.
Find our list of scheduled courses here.
Aspects of Truthfulness
Monday, June 29th, 2009I had a fantastic discussion this weekend while on a road trip with my colleague David Parker. We talked about the different aspects of Truthfulness. This is what we came up with.
Honesty
Are you perfectly honest? Is every statement you make factually correct to the best of your knowledge?
Behaviors that are not honest include: hyperbole and exaggeration, sarcasm, falsehoods, omissions.
Honesty is the quality most obviously associated with Truthfulness.
Integrity
When you make a commitment, do you keep it? Are your deeds an accurate reflection of your words and thoughts?
Behaviors that erode integrity include hypocrisy, unreliability, lateness.
Transparency
When someone wants to know something can they find it out from you? Can you provide simple proof of your words and deeds?
Behaviors that prevent transparency include stonewalling, passing the buck, verbal diarrhea, and the use of esoteric or inappropriate jargon.
Serenity
Do you accept that the unexpected is natural? Have you given up trying to control your environment?
Things that block serenity are anxiety and worry, reactionary anger, backstabbing, and manipulation.
Humility
Do you accept that others have wisdom, knowledge and experience that you don’t? Can you admit both the possibility of being wrong, and the fact of being wrong?
There are many things that prevent the development of humility: taking offense from comments about yourself, your ideas or your actions, insisting on your way, vanity, boasting, and even ostentatious self-deprecation.
Mentoring, Coaching and Training – What is the Difference?
Wednesday, June 24th, 2009Over the years working with clients, I’ve discovered that there is often confusion about what are the differences between mentoring, coaching and training. We all know that these are ways for an expert or experienced individual to help people do something more effectively. That’s the similarity. But the differences…
Mentoring
Mentoring is generally an informal relationship between two people. A mentor will do many of the same things as a coach or even someone who is a trainer, but there is no formal obligation on the part of either party. A mentoring relationship often develops gradually from a friendship or a professional association, intensifies as the mentor discovers he has valuable insight and experience to share, and as the person being mentored discovers his desire to learn from the mentor. The two people will at some point recognize the special nature of their relationship, but may not name it. And as life circumstances change, the relationship will gradually de-intensify. It will often turn into a friendship of peers.
Coaching
In working on this article, I read a number of other articles about the differences between coaching and mentoring. All of them talk about how a coach does not provide solutions or answers. I beg to differ. Think of an athletic coach. An athletic coach definitely does not simply ask the athlete questions and help them bring out their own solutions to problems. An athletic coach helps point out problems, makes very definite suggestions, and sometimes even intervenes physically to help the athlete do the right thing. So what is coaching? The main difference is in terms of formality.
A coach is a coach from the start of the relationship with the person being coached. The person being coached has a specific goal to achieve. It can be long term or short term, but it is specific. The coach is there to help that person meet their goal. Once the goal is met, the relationship is re-evaluated.
Here are some of the ways that coaching can happen (actually, mentors do these things too):
- The Socratic Coach – asks lots of probing questions.
- The Hands-On Coach – shows people a way to solve a problem, but leaves it to the individual to mimic or do something different.
- The Intervention Coach – mostly observes and at key moments intervenes to help an individual choose a specific path of action.
- The Guiding Coach – provides constant (usually gentle) reminders to help an individual keep withing a specific path of action (guide rails).
Training
Classroom training is the type of training we most often think of, but it is not the only kind. There is also on-the-job training and of course all sorts of e-learning methods of training. Training is very formal, should have well-defined learning objectives, and is often relatively brief as compared to coaching or mentoring.
Training can also include many of the types of interaction that are found in a coaching environment, but there is a very strong focus on the trainer being a subject matter expert. The trainer has extensive experience or knowledge in the subject that is being delivered in the training. It is expected that the participants in the training learn from the trainer – there is knowledge transfer. How this happens can be very flexible, of course, and good training is never just a speaker standing at the front of the room and lecturing for the whole time. Discussion, simulations, case studies, and other forms of interaction are critical for an effective training experience.
Some other links:
Workplace Coaching and Mentoring – Some Key Differences to Maximize Personal Development
Coaching is Not Mentoring, Training or Counselling
What are the Similarities and Differences Between Coaching and Other Things?
Are You Coaching Mentoring or Training Your New Employees? Distinctions New Managers Need to Know.
50% Discount on ScrumMaster Training – Only 76 Spots Left
Wednesday, June 24th, 2009Our summer special is proving to be very popular! We started with 100 spots at our 50% discount price of CAD995.00. We’re down to 76 spots. Check out our course listing page – every CSM course we have scheduled in Canada is available at this fantastic price (Toronto, Waterloo, Edmonton, Ottawa).
Even without the discount, our course is a better value than many out there. It’s a three day course instead of the normal two. This gives you a chance to really dig into the concepts and practices of Scrum and Agile Project Management. Our course is really designed for project managers, team leads and other managers, instead of being for anyone interested in Scrum. Of course, if you are interested in a leadership role, but aren’t there yet, you are still welcome to come!
Not only that, we don’t run courses in locations where it is not easy for use to support you after you take the course. We run our business in Canada, and our consulting and coaching work is there to help you if you want further assistance with doing agile in your organization. Even if you aren’t in Canada, maybe your organization has a group in Canada or you have professional contacts in Canada – if so, let them know about this fantastic opportunity.
Find our list of scheduled courses here.