November 01, 2007
Learning Collaboration
How do we teach people to work in a collaborative manner? How do we help individuals, in our incredibly individualist and competitive society, to learn the skills needed for agile teamwork?
Start with the Kids
Our school system, here in the West, is strongly oriented to individual grading, work, and even competition. We throw our kids into age-limited classrooms where they are inevitably compared to one another and learn to make the comparisons themselves. There are private schools which don't do this: no grading, mixed-age classrooms, but they are the exception by far.
It seems reasonable to me that if we could help our kids learn collaborative skills, they would at least have a foundation to build upon and minds that were more open to the possibilities.
In my mind, the best way to do this consists of two aspects: collective efforts and human capacity development.
Collective Efforts
Kids are amazing at learning. If they have experiences, they naturally learn to cope with those experiences. It follows then, that even if children start out with little or no skill in collective, collaborative work, then simply by putting them into situations where that type of work is required, they will learn at least some of the necessary skills.
I had two experiences in my childhood that helped me learn those skills. In my faith community, as a Baha'i, we had children's classes (kinda like Sunday school) where we played many collaborative games and learned about the Baha'i concept of consultation. I didn't particularly like the games, but nevertheless, they made an impression on my young mind. I even remember at one point when I was a little older learning to help out with these games. The things I learned about group decision making through consultation made a big impact on me and have become more and more important as I progressed through school and professional life.
The second experience was in my public school where I was streamed into a program for academically talented children. I think the idea was that if you had an IQ of 120 or over you were eligible for the program. I remember doing an IQ test in grade four. Anyway, the program was excellent in many ways. In grades seven and eight we started to learn Edward deBono's CoRT thinking skills program. I'm not sure if it was intentional or not, but many of the exercises were small group exercises where two or three or four of us had to work together. Again, I learned a great deal about the value of working with people with different skills and ideas, and how to do this in a systematic way. Many of the exercises and techniques that I use as a coach and trainer are based on or inspired by these exercises I did as a child.
Human Capacity Development
I recently wrote here about truthfulness. Aside from the obvious implications for agile methods that I have written about, there is another level to this concept.
Truthfulness is the foundation of all human virtues - Baha'u'llah.
There is no doubt in my mind that some of the basic virtues or moral ideas that we are supposed to learn in childhood are critical to effective collaboration. For example, the "Golden Rule": "And if thine eyes be turned towards justice, choose thou for thy neighbour that which thou choosest for thyself." Epistle to the Son of the Wolf, p30.
The trouble is, you can't do the Golden Rule effectively without being truthful. How so? Well, if you can't be truthful about what you really want for yourself, deep, deep down, then chances are you aren't going to do to others what they truly want. Knowing your own self at the deepest level is a pre-condition to following the Golden Rule effectively. And knowing your own self deeply requires a level of truthfulness that most of us are not accustomed to.
The same could be said about almost any other virtue or capacity required for collaboration: courage, humility, assertiveness, compassion, etc.
Of course, developing these capacities is something that doesn't happen overnight. The starting point is to look at what we can be truthful about, and building on that. As we practice these capacities in our relationships with other people, they will strengthen and we will set out on a path of improvement. It is helpful to have other people working with us; to support us, encourage us, and to help us honestly face up to our failures and learn from them. It also helps to have guidance that can be trusted. Searching for these sources of guidance is an important part of developing professionally as well as personally, whether it is a mentor, an author or some other figure.
These capacities are essential to our ability to work well together. The root cause of most of our failures to work together can be traced back to a lack of or failure to exercise these human capacities. For example, a lack of courage can lead to a failure to experiment. A lack of humility can lead to a failure to ask for help.
Posted by Mishkin Berteig at 07:26 AM | |
January 17, 2007
The Inner Ring
Here's a slightly off-topic, but nevertheless excellent read: "The Inner Ring" by C S Lewis. This is a talk given by C S Lewis to what seems to be a group of university students. In it, he describes the notion of the inner ring and the desire to be "in". It is amazing how much our culture in North America and our corporate culture is driven by this desire. I'll leave it to you to decide if this is good or bad.
Posted by Mishkin Berteig at 04:23 PM | |
January 02, 2007
Top Ten Most Popular Entries from 2006
If you are new to Agile Advice, these are not just some of the most popular articles, they are also some of the best! Take a look around; you will find ideas to inspire you, challenge your thinking and maybe that one little thing that will make the difference in applying agile methods in your situation.
1. How Two Hours Can Waste Two Weeks - 25,617 unique views
This little hypothetical story by Dmitri Zimine was very popular on Reddit, and Joel on Software ranted a bit about it.
2. The Case for Context Switching - 2,936 unique views
My rebuttal to Joel's rant. Goes well with Dmitri's article. Emphasizes the idea of building trust in an organization.
3. The Qualities of an Ideal Test - 1,579 unique views
Six qualities that will help make your tests as valuable as can be. Similar to the ACID properties of databases or the INVEST properties of user stories.
4. The Pros and Cons of Short Iterations - 1,555 unique views
A few words that will help you decide how long to make your iteration length. This is an important decision, and most teams and organizations don't know the factors involved.
5. Five Signs of Trouble in an Iteration - 1,489 unique views
A good howto on using burndown charts to discover problems in an iteration.
6. Seventeen Tips for Iteration Planning - 1,427 unique views
A good list of hints and tips that can make the difference between struggling with iteration planning and having it go smoothly and effectively. This is a key part of the Agile Work process, so getting good at it is a high priority for any team new to Agile Work.
7. Change is Natural - "Embrace Change" - 1,397 unique views
A short riff on the universality of change. Also introduces the idea of the "horizon of predictability".
8. The Art of Obstacle Removal - 1,287 unique views
This is a good reference article on types of obstacles and methods for removing them... a critical practice for Process Facilitators.
9. The Seven Core Practices of Agile Work - 1,285 unique views
Agile Work is really quite simple. This is a concise list of the practices that make up this effective methodology.
10. Interview with Alistair Cockburn - Agile and House Renovations - 902 unique views
Applying agile methods to home and garden renovations! Learn a bit about how this luminary of the agile world has taken agile practices out of the software world and into the hardware world.
Posted by Mishkin Berteig at 06:32 PM | |
December 22, 2006
Technical Debt
Last night I was thinking more about the analogy of technical debt. In this analogy, design and quality flaws in a team's work become a "debt" that must eventually be paid back. This analogy is fantastic because it can be taken just a little bit further to understand just how bad defects are...
Debt is sometimes useful. Financial debt can be used for risk reduction, investment, and emergencies. But it can also cause problems. Too much debt becomes hard to manage. If debt maintenance costs more than revenue (minus other expenses), then you're going down!
Technical debt is a little different than financial debt.
Suppose I went into a boardroom full of high-power executives for some large company. (Never mind how I got there.) And I pitched this fabulous idea: I'll give them a bunch of money for them to use for operations, expansion, whatever. All they have to agree to is that I choose the interest rate when I ask for repayment... trust me!
I would be thrown out of that room so fast!
That is what we do when we encourage teams to take on technical debt.
There is no way to know the interest rate on a defect. Part of the cost of a defect is obvious: how much time and materials will it take to repair the immediate problem. (Although even that is often hard to measure.) But there are also lots of non-obvious and probably non-measurable costs. How much effort will it take to get to the root cause of the defect so that it doesn't occur a second time? How much will it affect our "goodwill" and thus reduce further and repeat sales? How much will the existence of one defect hide the existence of other defects (with their own costs)? How much will the defect demoralize the team and increase staff turnover or reduce productivity? How much of an opportunity will the defect create for competitors? How much will the defect increase maintenance and support costs?
In other words, every time someone asks a team to let quality slide, they are asking the team (and the organization) to take on debt with an unknown interest rate. Which is lunacy.
Read more about this:
Voluntary Technical Debt - James Shore talks about a situation where a conscious decision to take on technical debt led to positive results.
Technical Debt: The Threshold of Acceptable Pain - Steve Bate talks about skill and sensitivity to technical debt. Here's a great quote from this article:
What if someone has a very high threshold of pain? I’d expect to see lots of crud (technical debt) in their code.... The high threshold developer doesn’t mind spending weeks on new features that would otherwise require days or hours with clean code. And they don’t mind staying at work all night fixing bugs before a major release or spending countless hours babysitting the production system after it’s been released. It doesn’t seem to bother them to spend significant time away from family and friends or to have limited time or other interests and hobbies. ...they sometimes experience pleasure at being the “hero” who saved the company from the bugs they created.
An Incremental Technique to Pay Off Testing Technical Debt - Johanna Rothman talks about technical debt and describes a simple risk-oriented approach to reducing it.
Posted by Mishkin Berteig at 08:23 AM | |
September 05, 2006
The Seven Core Practices of Agile Work
Agile Work consists of seven core practices. These practices form a solid starting point for any person, team or community that wishes to follow the Middle Way to Excellence.
Self-Organizing Team
Any group of people that wish to be an Agile Team need to take the initiative to determine for themselves how they are going to work (process) and how they are going to do the work (product). The term "team" really applies quite broadly to any size group of people that are working together towards a common goal.
Teams go through stages of development as they perform their work. The most important result of team development is the team itself, and not the specific skills and abilities that the individuals learn.
If the team is part of a broader organization, that organization must give the team the authority, space and safety to learn to be self-organizing. The organization's leadership is responsible for determining the "why?", some constraints on "how?", and then letting the team respond to the need as best as it can.
Also Known As: Whole Team (Extreme Programming), Cross-Functional Team (business management).
Deliver Frequently
Agile Work uses short fixed periods of time to frame the process of delivering something of value. Each of these iterations or timeboxes is structured so that the team or group actually finishes a piece of work and delivers it to stakeholders. Then, the team builds on what has previously been delivered to do it again in the same short amount of time.
The sooner that valuable results can be delivered, the more value can be obtained from those results. This extra value is derived from opportunities such as earlier sales, competitive advantage, early feedback, and risk reduction.
There is an explicit tradeoff: the shorter the time to delivery, the smaller the piece of value will be. But, like investing in one's retirement account, the earlier you start, even with small amounts of money, the better off you are in the long run.
Also Known As: Sprint (Scrum), Iteration (Extreme Programming), Timeboxing (generic), Time Value of Money (accounting).
Plan to Learn
Every type of work is governed by a Horizon of Predictability. Any plan that extends beyond this horizon of predictability is bound to fail. Agile work uses an explicit learning cycle tied in with the planning of work to accomodate this inevitable change.
First, a goal is required. This goal can be long-term. Teams using Agile Work then create a queue of work items to be done in order to reach this goal. Each iteration, some of these items are selected, finished and then the queue is adjusted. The changes in the work queue are based on external factors, and learning that the team does as it goes.
One of the most effective methods for the team to learn about how it is doing its work is the retrospective. After each delivery of results, the team holds a retrospective to examine how it can improve.
Also Known As: Inspect and Adapt (Scrum), Kaizen (Lean), Adaptive Planning (generic).
Communicate Powerfully
A team needs to have effective means of communicating, both amongst team members and also to stakeholders. To Communicate Powerfully, a team needs to prefer in-person communication over distributed communication. Synchronous over asynchronous communication. High-bandwidth over low-bandwidth communication. Multi-mode communication over single-mode communication.
The results of failing to communicate powerfully include wasted time for waiting, misunderstandings leading to defects or re-work, slower development of trust, slower team-building, and ultimately a failure to align perceptions of reality.
The single most effective means to communicate powerfully, is to put all the team in a room together where they can do their work, every day for the majority of the work time.
Some types of work do not lend themselves to this approach (e.g. creating a documentary video), but every effort should be made to improve communication.
Also Known As: Visibility (Scrum), Whole Team and Team Room (Extreme Programming), War Room (business management).
Test Everything
Defects are one of the most critical types of waste to eliminate from a work process. By testing everything, by driving all the work of a team by creating test cases to check the work, a team can reach extremely high quality levels. This ability to prevent defects is so important that only an executive level decision should be considered sufficient to allow defects into a work process. Quality is not negotiable.
In Agile Work, removing a defect is the only type of work that takes priority over any new features/functionality/production. If the end result desired is to maximize value, then removing defects is an important means to that end.
A team has an ethical duty to discover new ways to effectively test their work. This can be through the use of tools, various feedback mechanisms, automation, and good old problem-solving abilities.
Also Known As: Canary in the Coal Mine (Scrum), Test-Driven Development (Extreme Programming), Defects per Opportunities (Six-Sigma).
Measure Value
Since Reality is Perceived, it is important for an agile team and organization to have a clear method of describing and perceiving what is important for the organization. Measuring value is a critical method for describing and perceiving what is important.
A single metric can be used to drive all the measurement and goal-setting and rewards in an organization. All other measurements are secondary and must be treated as such: limited in use and temporary.
There are many things which are easier to measure than value. It is often easy to measure cost, or hours worked, or defects found, or estimate vs. actual... etc. However, all of these other measurements either implicitly or explicitly drive sub-optimal behavior.
Also Known As: Measuring Results (Scrum), ROI (business management), Economic Driver (Good to Great), Running Tested Features (Extreme Programming).
Clear the Path
Everyone in an organization using Agile Work takes responsibility for clearing the path, removing the obstacles that prevent work from being done effectively. Clearing the Path doesn't just mean expedient, quick fixes to problems, but rather taking the time to look at an obstacle and do the best possible to remove it permanently so that it never blocks the path again.
In the Agile Work method, the Process Facilitator is the person who is responsible for tracking obstacles and ensuring that the path is cleared. To do this, the Process Facilitator maintains a Record of Obstacles.
Clearing the Path is sometimes painful work that exposes things we would rather not deal with. As a result, it is critical that people build their capacity for truthfulness and work to develop trust amongst each other. Building a capacity for truthfulness is not something that can be done by using an explicit process.
Also Known As: Removing Obstacles (Scrum), Stopping the Line (Lean).
Remember also, that these practices must always be viewed and implemented in the context of the Agile Axioms. These axioms provide a check to ensure that the practices are not being applied blindly, but rather applied appropriately to the given situation.
Posted by Mishkin Berteig at 09:09 AM | |
September 01, 2006
Developing Trust
Agile Work is a set of methods that are useful in working effectively and delivering value to stakeholders. There are many good business reasons to use Agile Work. There is also a very important human reason to use this method: developing trust and the capacity for truthfulness.
Everyone has struggled at some time or another with being truthful. At work, this may happen out of fear or embarrassment; if I've done something wrong or made a mistake, I don't want others to know about it. Many work environments push people to a CYA (Cover Your Ass) attitude.
Agile Work has a few practices that help move us away from this and towards greater visibility and truthfulness.
First, frequent delivery of value: this practice, using iterations with strict timeboxes allows us to make a commitment to get something done, and then do it, and then show everyone that we did it. Often this one thing alone is sufficient to start the process of removing distrust and replacing it with visibility and truthfulness.
Second, status meetings and retrospectives: these practices allow team members to regularly report on obstacles and things that need improvement. These obstacles and needs for improvement are often the things we hide out of fear or embarrassment. By using these practices on a regular basis, we become more and more comfortable with raising our concerns. As well, the fact that these practices are an explicit accepted part of the process helps to legitimize and provide a safe environment for people to raise obstacles and needs for improvement.
Third, powerful communication: by having the team use highly visible information radiators, and by having the team work together in an open team room, there is more physical visibility of what is happening. It is harder to hide the fact that I spend 5 hours a day surfing the net. It is harder to hide the fact that I spend 3 hours a day on the phone. It is harder to hide the fact that I come in late every single day. This can be uncomfortable for those who have something to hide! Powerful communication also includes working face-to-face jointly on many problems and their solutions. If you are insecure about your own skills or knowledge, this also can be challenging. Nevertheless, this practice also helps develop visibility, truthfulness and trust.
It is important for the team and management to realize that it does take time to develop trust. Depending on how many of these practices you use, and how sincerely you work on them, the development of trust may happen quickly or it may happen slowly. This has implications for deciding on trade-offs. If trust develops slowly, then it will take longer to get a team into the performing stage of its development and therefore it will take longer to get to a hyper-productive state. Just to be clear: for a business this means that value is delivered slower!
What other ways do agile methods help develop trust and the capacity for truthfulness?
Posted by Mishkin Berteig at 08:14 AM | |
April 12, 2006
Follow the Principles and Adjust the Practices
In "Built to Last : Successful Habits of Visionary Companies
Follow the Principles
What exactly are the principles? The foundation starts with Trust and Truthfulness. "Truthfulness is the foundation of all human virtues." Everything we do with agile should be about truthfulness (visibility, transparency) and building trust.
With this as a strong foundation, we can look at the Agile Axioms:
We are Creators
Reality is Perceived
Change is Natural
All of the other principles and practices associated with Agile Work flow from these basic assumptions about the world. We can't prove that the above three axioms are "true". But they either resonate with us or they don't. If they do, then it will be easy to use these axioms as a checkpoint for all the activities we engage in using Agile Work, wherever we apply it.
We are creators... therefore we derive our sense of value from our ability to create. If our creations are accepted by others, our team, our stakeholders or our community, all the better. But fundamentally, this is inherent to us as human beings. However, sometimes this natural drive is suppressed or repressed. In order to activate it, we need to work in empowered teams.
Have you ever experienced inspiration or "flow" or joy when working with someone else? Perhaps you were solving a problem. Perhaps you were playing a musical instrument - jamming - and got into a fertile groove. Perhaps you were teaching your children and created the light of understanding in them. Perhaps you built a beautiful set of bookshelves for your home. Or maybe you told a joke that created a brief moment of genuine levity in a group of friends. We are all constantly creating!
This basic principle then means that Agile Work methods and practices should not be imposed. Taught to us, perhaps... given to us as a template, perhaps... but once we understand the practices and are familiar with them, we should immediately be given the freedom to use the learning cycle to be creative with the process and practices of Agile Work itself. If we do not participate in creation, we become dis-empowered and that eventually leads to resentment or apathy.
Reality is perceived... therefore we need to work hard to build a common perception of reality if we are to work together effectively. We need to amplify our learning. We can't assume that our own understanding of a situation is going to be shared by others. At the very least we need to check: "do you see this?"
Let's recognize that in some way or another we are all blind:
Again, the learning cycle comes into play. The guidance, detachment, love, courage and search we go through all help us to build a common understanding of reality. This allows us to see new ways to apply the Agile Work principles and practices that make sense not only to our context, but also to everyone else participating in the work.
Change is natural... therefore instead of fighting change, we need to anticipate it, adjust to it, embrace it, and be gracious or even enthusiastic. Not only does change happen to us, but we also instigate change. If things get to boring, whatever the circumstance, we find ways to change things. We rebel at stasis and ennui.
Each practice and procedure done in the context of Agile Work must be explicity and implicitly accomodating of change. If a procedure can't tolerate change it will either lead to a dissonance or conflict... or if we are embracing change, then we will modify or discard the procedure. Our creative nature loves to create, but if we become too attached, too "in love" with our creations, we will support them past their point of relevance.
Our latest greatest idea will be good for a while. But eventually change will make it irrelevent.
So we see that all three Agile Axioms are also interrelated.
Our creations will be washed away through change and if we are lucky or wise we will perceive the change in reality - be truthful to ourselves and others - and allow a new creation to take the place of the old one.
When we perceive a certain truth, and try to share that with others, we will be asking those others to change their own perceptions. This change can be difficult and may even require the destruction of a mental model created with love and care over a lifetime. Sensitivity to this loss and encouragement to build a new creation will help build a shared perception... as long as we too are open to new perceptions!
Adjust the Practices
And of course, all this foundation of creation, perception and change must be connected to the practical day-to-day reality of our lives. Our family lives, our work lives, our social lives, our volunteer lives, our intellectual lives, our emotional lives, our spiritual lives... our whole lives.
The Agile Work practices are simple to state:
Manage Ourselves
Deliver Frequently
Adapt our Plans
Communicate Powerfully
Test Everything
Measure Value
Remove Obstacles
These practices provide a starting point. A basic set of activities that will assist you, your team or your organization to advance quickly towards whatever goal you have set for yourselves. The way these practices succeed is by making sure that the Agile Axioms are always remembered and their implications accepted. These practices will set up a virtuous circle by building trust and allowing truthfulness. More trust and truthfulness will allow a fuller and more nuanced expression of the practices...
But if these practices become canonized, if they become a rote process imposed and followed blindly, then it means that we have lost sight of the Axioms. We have forgotten to check our practices against the context of creation, perception and change.
The reason we follow these practices is because we believe that we are all creators, that we can learn from our diverse perception of reality and that change is a force of growth. We don't believe these Axioms because we blindly perform these practices.
This is all available as a nicely formatted pdf: Agile Axioms - a Brief Exposition.
Posted by Mishkin Berteig at 01:45 AM | |
March 30, 2006
Bombs and Agile
The coach's gathering last weekend also got me thinking about the ethics of Agile Work and coaching. Is it okay to use agile methods for destructive purposes?
Let's first look at the Agile Software Manifesto for guidance. We see four statements of values and a number of principles. None of them provide an ethical framework that helps us determine where to use agile methods. In fact, there are many types of work that we could ask an equivalent set of questions about:
Is it okay to use agile methods to assist research in bio-weapons?
Is it okay to use agile methods to build software systems for nuclear missiles?
Is it okay to use agile methods to run a hate campaign?
Is it okay to use agile methods to ... ?
The agile community lacks a statement of ethics equivalent to the Hippocratic Oath. Do we even need one? As coaches, should our Middle Way to Excellence be grounded in a strong moral sense or is the middle way adrift?
I feel like we need a moral grounding. I think that the basis of it should be the recognition of the Unity of Humanity. I believe that both justice and mercy are important. Trust and Truthfulness are part of the foundation as well.
Is there any way to state a professional creed for Agile coaches that we can all agree upon? Has anyone tried?
For what it's worth, the ICF has a code of ethics that might be a starting point.
Posted by Mishkin Berteig at 01:04 PM | |
March 14, 2006
Agile or Not Agile?
Every once in a while the del.icio.us tag for Agile turns up something really interesting. This evening, I found this article about the ongoing use of the term "Agile". The article is brief and a little weak, but it brings up a concern that is always niggling in the back of my mind. Interestingly enough, a good friend of mine, Christian Gruber, emailed me another web page of similar import...
In this registration page for Rules of Enterprise Agility, we read about something that really has nothing to do with the Agile Manifesto, nor the Agile Axioms.
Both of these examples are signs of two things:
1. The growing popularity of the term "Agile".
2. The growing dilution of the meaning of the term.
How can we fight this? Should we fight this?
I think it is very important to constantly call attention to the fact that Agile is about the minimum process and tools that can possibly work, and only in the context of valuing individuals, interactions and teams more than those tools and processes.
Trust is the Foundation of Agile Work
Technology, tools, process, even good ideas and good organizations do not create trust. People create trust by being trustworthy: honoring their commitments, striving for excellence, truthfulness, courage. One of the fundamental problems afflicting organizations is the lack of trust: between management and employees, between business and IT, between experts of various sorts, between coworkers.
This lack of trust is institutionalized in many ways including bureaucracy and legal frameworks.
The only way to change this state of affairs is to build trust. And the only way to build trust is to embody trustworthiness in yourself so that by example and by your words you can help others to become more trustworthy.
Agile methods put in place mechanisms that assist in building trust. But those mechanisms are merely a means to an end. Let us never forget that.
Posted by Mishkin Berteig at 12:27 AM | |
February 15, 2006
Something a Little Different: 19 Leadership Capabilities
This list of nineteen leadership capabilities, hosted on the web site of a private school in Ontario, Canada, is inspiring and in many ways closely related to the work one must do in an Agile context. The list is written in the language of a moral or ethical framework. The whole list is interesting food for thought so I have reproduced it here as well with a few additional comments.
1. Evaluating one's own strengths and weaknesses without involving ego.2. Transcending one's lower passions by focusing on higher purposes and capabilities.
3. Managing one's affairs and responsibilities with rectitude of conduct based on moral and ethical principles.
4. Learning from systematic reflection upon action within a consistent framework.
5. Perceiving and interpreting the significance of current events and trends in light of an appropriate historical perspective.
6. Thinking systematically and strategically in search for solutions.
7. Forming a common vision of a desirable future based on shared values and principles, and articulating this in a way that inspires us to work towards its realization.
8. Imbuing one's actions and thoughts with love.
9. Encouraging others and bringing happiness in their hearts.
10. Taking initiative in a creative and a disciplined way.
11. Sustaining effort, perservering, and overcoming obstacles.
12. Participating effectively in consultation.
13. Building unity in diversity.
14. Committing oneself to empowering educational activities as a student and as a teacher.
15. Recognizing relationships of domination and contributing to their transformation into relationships based on interconnectedness, reciprocity, and co-operation.
16. Contributing to the establishment of justice.
17. Serving in societal institutions so as to facilitate the expression of the talents of others that are affected by these institutions.
18. Being a responsible and loving family member as a child, spouse, or parent.
19. Cultivating and creating a sense of beauty in every endeavour.
Only one of these (#14.) is phrased awkwardly for us as participants in agile efforts since it refers specifically to the educational context these are written for. Other than that one, and with a little thought that one as well, these are all appropriate to us. We may be uncomfortable with the specific language from time to time, but we should be certain to take the time to consider how these apply... assume positive intent and look for the wisdom and truth in each item.
Number 4 is particularly apropos to our work:
Learning from systematic reflection upon action within a consistent framework.
In many ways, this is what we do with iterative delivery and adaptive planning. It is double-loop learning.
Posted by Mishkin Berteig at 01:01 PM | |
October 10, 2005
Agile, the Adult Educator and Ethical Considerations
A review of Tara J. Fenwick's “Limits of the Learning Organization: A Critical Look” (article found in Learning for life: Canadian readings in adult education
This article is a critique of learning organization literature (as presented in the works of Peters, Senge, Watkins, Marsick, Argyris, Schon and others). I chose to do a review of it because learning organization literature can and does inform the work of Agile practitioners. The writer, Tara Fenwick, offers a critique of this literature as an academic and practitioner in the field of adult education. Even though the language and tone of the article is judgmental and at times affronting to the corporate trainer audience, it is never-the-less challenging and valuable because she raises interesting ethical questions that can serve as cautions against potential trends that can distort agile practice. I will summarize her argument in the some of the areas most relevant to Agile practice.
Fenwick's summary of the model of learning organization found in the literature, is an organization that: “creates continuous learning opportunities, promotes inquiry and dialog, encourages collaboration and team learning, establishes systems to capture and share learning, empowers people toward collective vision and connects the organization to its environment.”
The following is a summary list of some of Fenwick's critiques:
Who's Interests are Served
Although the learning organization literature holds great promise for a more humanitarian and egalitarian workplace, it has the potential to distort learning “into a tool for competitive advantage” and in turn, exploit people as resources in the pursuit of profit. To explore this idea she asks a valuable question: “Who's interests are being served by the concept of learning organization, and what relations of power does it help to secure?” She argues that learning organization literature tends to serve the interests of educators working as trainers in organizations and managers interested in their own self preservation.
How Learning is Defined
Learning, in learning organization literature seems to be defined as that which benefits the organization, all other learning falls into the dysfunctional category. This perspective negates other ways that people create meaning and learn and potentially causes a person to become “alienated from their own meaning and block flourishing of this learning into something to benefit the community.”
Assumptions about Learners
The learning organization literature subordinates employees by seeing them as “undifferentiated learners-in-deficit”. Educators and managers are the architects of the learning organization while employees are busy “learning more, learning better and faster” trying to correct their knowledge deficit. In the learning organization workers become responsible for the health of the organization without the authority to determine alternative ways to reach that health. The fear of being left behind in a quickly changing market environment is used to create anxiety and fear as motivations for learning. All of these factors serve to put serious limits on the potential of people to learn in the work environment.
Diversity and Privilege Overlooked
Perspectives of race, class and gender -which research has shown affects the way people learn and collaborate- are lacking in the literature. Fenwick challenges the notion of achieving a democratically ideal situation for open dialog -that the learning organization literature calls for- when all people in the work place do not “have equal opportunity to participate, reflect, and refute one another” (for example because of the status of ones job, character, gender, class, age etc.)
Fenwick sheds a clear light on where the good philosophies of the learning organization are found wanting. The Agile community can benefit from asking some of the same ethical questions she asks in relation to our work. Her critique is a good challenge for Agile practitioners. It challenges us to:
- Continue to strive for higher levels of ethical excellence in our work
- To consider issues of power in our work
- To become conscious of how we use our own power
- To give thought to what voices are included / excluded in the creation of the learning organization
- Pay attention to how we motivate learners
- How to foster collaborative environments that are conscious of the privileging of some over others
- Think about who decides what is valuable knowledge and learning and how that affects the knowledge creation process
Reflecting on these issues will go a long way to contributing to the development of agile practice.
The full text of an old version of Fenwick's article can be found here.
Posted by Shabnam Tashakour at 09:35 PM | |
May 10, 2005
Empower the Team
Empowerment is the ability of a team to make decisions about how to do their work and execute on those decisions without outside interference. If a team is empowered, then it will be more capable of responding to change, and it will be able to focus on manifesting the members' creative potential. Empowerment comes from a combination of several factors:
1. members of the team have a deep sense of self-worth that includes nobility, and contribution to the progress of humanity
2. tacit or explicit authority and responsibility for results as a team and as individuals
3. a team environment which is honest, trusting and allows for mistakes
4. the absence of personal attacks against individuals on the team and in particular a total lack of gossip and backbiting
There are several ways that team members will demonstrate their empowerment. People will derive joy from their work. Team members will be dedicated to the work and the team. Individuals on the team will frequently take individual initiative to accomplish tasks, share insights, and develop improvements. Spontaneous leadership will become common. Individuals will step out of comfort zones or areas of specialization in order to assist the team.
Empowering a team is a process that can sometimes take a great deal of time and effort. In order to start on this process, the team members should carefully listen to each other and ask many questions. More mature individuals should lead and teach by example. And all the team members can start to question and challenge the rules and procedures of an environment that are preventing effective work. If the team is in an organizational environment where team members have management to report to, then management must be aware of this opportunity for empowerment and support it.
An empowered team can gradually understand and internalize the agile work principles (People are Creators, Change is Constant, Perception mediates Reality). By internalizing these principles, a team can move beyond specific agile work practices and become a high performing team setting their own work practices.
Jeff Sutherland has a very brief blurb about the progress of teams as they evolve in their use of Scrum.
Future entries here will discuss the methods of creating empowered teams.
Posted by Mishkin Berteig at 11:04 PM | |
May 04, 2005
Asymmetry of Knowledge and Abuse of Agile Practice
I read an article in Wired yesterday that was modified from a book "Freakonomics
Doctors have a similar motivation. Statistically, when times are tighter (fewer patients), the article pointed to the proportion of interventions going up (referring here to internists and surgeons). The article isn't crying conspiracy. Rather, it's talking about the natural incentives, and the consequences of the asymmetry of knowledge. The doctor knows more, so if they (consciously or subconsciously) recommend more intervention than is necessary, the patient has no way of knowing in order to assess bias and accomodate. Likewise with Real-estate agents.
With alternative practices or new sciences there is an even larger knowledge gap, because even popular wisdom hasn't filtered down to the masses in digestible CNN-sound-bite chunks. Also, there is a lot of "naive money" in new fields, as well as a lot of genuine people who are just trying to help. Unfortunately, this means that there are a lot of wolves among the sheep, and they're wearing the costume of a sheep-dog.
I think, in some ways, that was at the basis for Ken Schwaber's concern on the Scrum Developer's list about a scrum practitioner who was not really teaching scrum, but was (in Ken's paraphrased view) bilking the customer and ego-tripping. Scrum will have a similar dynamic as one finds in, say, alternative health and nutrition, or other early-stage professional arenas. There will be idealists and opportunists and then some who try to apply balance. One has to be very careful of both the idealists and the opportunists. Sometimes it is very hard to tell, and this has a high chance of painting the whole Agile community with the same brush. One of my associates had a very very bad experience with Scrum for that reason. An unscrupulous person who used the position of Scrum Master to aggrandize himself.
Posted by Christian Gruber at 01:07 PM | |
April 26, 2005
Truthfulness and the Three Agile Axioms
A few more words are in order about how Truthfulness is the foundation upon which the three Agile Axioms rest. Taking them one at a time:
1. We are Creators
Truthfulness operates at a very deep level for this agile principle. People typically are not aware of their own need to shape reality, to create things. Developing truthfulness helps a person to uncover this fundamental capacity and bring it to fruition. Truthfulness also helps a person reflect on the results of their creative work. This is essential for learning how to become a more effective creator. In an agile team, truthfulness is also essential in developing the interpersonal trust necessary to know when the process of creation is going aright or awry.
2. Reality is Perceived
This principle is the most obvious domain where Truthfulness plays a role. In this instance, being able to express one's perceptions and share them with others in a truthful manner allows others to develop empathy and formulate an honest response. If Truthfulness is missing, then perception will be based on something other than reality (well,... technically it will be based on the reality of an untruth). In an agile environment, where the value of communication and collaboration is extremely high, truthfulness helps to develop a shared perception for a team.
3. Change is Natural
Here the role of Truthfulness is simple: an agile team cannot function if it is not Truthful about change. Recognizing and communicating change so that a team can embrace it and adapt to it depends completely on people being forthright and truthful about change.
Much of my thinking about Truthfulness comes from the study of a passage from the Sacred Scriptures of the Baha'i Faith: "Truthfulness is the foundation of all human virtues." I have also had substantial discussions with other agile coaches about the importance of truthfulness and its key role in developing trust.
Posted by Mishkin Berteig at 11:51 PM | |