« March 2006 | Main | May 2006 »
April 24, 2006
Link: Eight Barriers to Effective Listening
On the Retrospectives Yahoo Group, Michael Webb posted a link to his article Eight Barriers to Effective Listening. This article provides practical advice on how to improve communication. Since one of the basic practices of Agile Work is to maximize communication, this article is essential reading!
Barriers to Effective Listening
Just in case you don't go follow the link from my introduction, here is a bit more info to help convince you:
As a process facilitator, one's responsibility is to remove obstacles. This is a list of obstacles to communication and includes for each barrier a strategy to overcome the barrier. Therefore, anyone who is a process facilitator (agile coach, scrummaster, etc.) should look this over and incorporate it into their skill set.
Here is the list of the eight barriers to effective listening:
- Knowing the Answer
- Trying to be Helpful
- Treating Discussion as Competition
- Trying to Influence or Impress
- Reacting to Red Flag Words
- Believing in Language
- Mixing up the Forest and the Trees
- Over-Splitting or Over-Lumping
Mr. Webb ends his article with a very nice self-referential comment:
We can make a difference in the world by learning to listen better and by telling others about better listening. But only if they listen.
Update 20070911:
Interestingly, I believe there are two more barriers to effective listening:
1. Distraction! I know that I have a hard time listening if I am tired, if I am worried about something, if I have sensory overload from another source, or (to my embarrassment) even if I just have my email open while talking on the phone.
2. Poor communication tools! It is much easier to listen effectively if I am face-to-face with the other person. Any type of technology that is used to communicate between two people becomes a barrier to effective listening: email, telephone, chat, etc.
Here is an interesting online quiz/presentation about the barriers to effective listening. In this presentation, there are seven barriers to effective listening listed:
- Content of the message
- Appeal of the speaker
- External distractions
- Emotions
- Clarity of language
- Selective perception
- Inappropriate feedback
Posted by Mishkin Berteig at 10:50 AM | |
April 21, 2006
Agile Adoption Stages for Teams
We know that teams go through identifiable stages of development: forming, storming, norming and performing (1). What exactly does this look like for an Agile team?
Forming
Here the team is typically innundated with three sources of new information: the Agile process and practices, the nature of the project and the other people in the team. This can be overwhelming and people will react in diverse ways: calm wait-and-see, rebelliousness, passive-aggressive, excitement, etc. If the team has an effective coach or mentor shepherding them through this, then feelings will tend towards excitement. The reality of learning so much at the same time will make the first few weeks of the team's time together quite exhausting. People will be actively fighting old habits, and people around the team will be asking lots of questions. Retrospectives will usually show that the team is impressed with their own teamwork and communication and will also show some disappointment with specific agile work practices.
Storming
After only one or two iterations, the team will transition into the Storming stage of development. Because Agile methods "front-load" the learning and the crisis, this forming stage comes fast, but it is also relatively mild. (Front-loading the learning means that all the problems that an organization has that hold it back from delivering quality work quickly are made visible in the first couple of iterations.) People are not used to a project being in crisis right at the start. It is critical for a coach or mentor or manager to be aware of this effect and expecting it. Again, for emphasis: an Agile project is in crisis immediately!... and this is perfectly normal and healthy. If the organization and the team are able to find means of dealing with this early crisis, then the project will continue and build larger and larger successes. On the other hand, if the organization or the team try to ignore or hide the problems, then very quickly work will revert to the old way: bureaucracy or chaos.
Norming
After about four to eight iterations, the team will reach a fairly comfortable place: the basic agile processes and practices are understood, the organization and the team have removed some basic obstacles to getting work done (and consciously left some obstacles in place in all likelihood), and everyone on the team has a basic level of comfort with their role. The challenge at this stage is to avoid falling into the trap of complacency. Although comfortable, this level of performance is probably not all that much better than the old way. There will be real advantages: regular delivery of work, good communication between stakeholders and the team. But there will be many obstacles still to be removed, and the team has a long way to go in its development. If the team becomes complacent, then it is critical that a catalyst be introduced to incite the team to further development. Often, this can be as simple as a systematic and intensive program of capability building. As team members learn and practice new skills: process skills, technical skills, people skills, strategic skills, business skills... and as they become more and more aware of each other's capabilities, they will also become more and more aware of areas for improvement. Incentives need to be provided to help team members focus dilligently on self-improvement and team improvement. The iteration retrospectives become critical to help with this process... the tricky bit is that this is the stage when people start to think the retrospectives are no longer necessary!
Performing
The transition into the Performing stage for an agile team is gradual and happens over a fairly extended period of time. The definition of "getting to done" will gradually expand to allow the team to go from zero to full delivery of the end results every single iteration. There will be a temptation to split up the team and use these experienced team members to seed new agile teams - resist this temptation! Breaking up the team at this point destroys the value of time and effort invested in the team. It is much more effective to start a new team from scratch. The essence of a performing agile team is not the transferrable knowledge about agile processes and practices. Rather, the most important result of the team-building process combined with the agile process is the team itself.
Posted by Mishkin Berteig at 11:57 PM | |
April 20, 2006
An Introduction to General Systems Thinking
I recently completed reading An Introduction to General Systems Thinking
The Subject
This book is about science, philosophy, behavior, organizations, organisms, problems, solutions, faith, reason, and everything in between. Specifically, it is about a general approach to dealing with systems given the limitations of our human abilities.
The Ideas
One of the strongest ideas in the whole book is that there is a class of systems for which we have only very poor tools to understand them. These systems, which he calls "organized complexity" are contrasted to "organized simplicity (machines)" and "unorganized complexity (aggregates)". Machines can be dealt with purely analytically and in a deterministic manner. Aggregates can be dealt with statistically. Systems that are in the organized complexity category are too complex for a purely analytical approach but too simple for a reasonable statistical analysis. The book is focused on methods for dealing with this class of systems.
The Writing
Mr. Weinberg's writing is, first and foremost, engaging. He writes in an informal voice that is a wonderful complement to the subject matter. Even with the informal tone, he is nevertheless able to communicate some tricky ideas with a great deal of precision and clarity. His use of examples, diagrams, stories and quotes throughout the book is excellent. Although I did not do the exercises he includes, upon reading them, I was satisfied to see that they are all interesting. Since I intend to re-read the book in six months or so, I will also publicly commit to doing a good chunck of the exercises too. Maybe you'll see some of my efforts here since many of them are apropos to Agile Work.
How Does This Apply to Agile Work?
Much of the emphasis in agile methods is on the intractability of building a perfect plan for a set of work (particularly in software projects). The group of human beings that are building something is in itself a system of "organized complexity". As a result, it is impossible to treat that group of people as a system that can be made to work in a deterministic manner. We simply can't account for all the variables. At the same time, we would like to have a lot more certainty about the behavior of the group than we could just using statistical methods. (Check out Systematic HR for some related articles.) Agile methods help us find this middle way that gives us a very good shot at reaching our goals, but acknowledges our inability to determine precisely how we'll get there. A good understanding of Systems Thinking helps us comprehend the necessity and applicability of agile methods.
The Table of Contents
The chapter and section titles of this book tell a great deal about the scope of the work. I have reproduced the table of contents here for your reference.
Chapter 1 The Problem
- The complexity of the World
- Mechanism and Mechanics
- The Square Law of Computation
- The Simplificiation of Science and the Science of Simplification
- Statistical Mechanics and the Law of Large Numbers
- The Law of Medium Numbers
Chapter 2 The Approach
- Organism, Analogy, and Vitalism
- The Scientist and His Categories
- The Main Article of General Systems Faith
- The Nature of General Systems Laws
- Varieties of Systems Thinking
Chapter 3 System and Illusion
- A System Is a Way of Looking at the World
- Absolute and Relative Thinking
- A System is a Set
- Observers and Observations
- The Principle of Indifference
Chapter 4 Interpreting Observations
- States
- The Eye-Brain Law
- The Generalized Thermodynamic Law
- Functional Notation and Reductionist Thought
- Incompleteness and Overcompleteness
- The Generalized Law of Complementarity
Chapter 5 Breaking Down Observations
- The Metaphors of Science
- Boundaries and Things
- Qualities and the Principle of Invariance
- Partitions
- The Strong Connection Law
Chapter 6 Describing Behavior
- Simulation - The White Box
- State Spaces
- Time as a Standard of Behavior
- Behavior in Open Systems
- The Principle of Indeterminability
Chapter 7 Some Systems Questions
- The Systems Triumvirate
- Stability
- Survival
- Identity
- Regulation and Adaptation
- The Used Car Law
Also, check it out, Mr. Weinberg has started a blog on writing fiction. He also helps run the AYE Conference (amplifying your effectiveness).
Posted by Mishkin Berteig at 05:18 PM | |
April 13, 2006
Agile Management is Servant-Leadership
Agile Work holds that process improvements are most effectively planned by those who perform the work. So, what happens to the manager role when we empower teams to self-organize? I recently turned up this old email, outlining how Scrum, an Agile project management method, reframes management responsibilities...
Wanted: Cat Herder
One of the methodologies in which I am trained, and which I teach to others is Scrum Project Management. The team lead in this approach is called the "ScrumMaster" (tongue firmly in cheek) or sometimes referred to as "the sheepdog" because he or she must care for the team, keeping out intruders and distractions. At the beginning, some folks have a hard time wrapping their mind around this role, because it feels to them like the old Project Manager role, but with strange twists. Here is an excerpt from an email conversation with an apprentice, in which we discuss how the ScrumMaster can be accountable without having authority. It starts with something written by the co-creator of Scrum, Ken Schwaber:
> Subject: Day in the life of a Scrum Master, according to Ken
>
> 1. Ensure everyone is doing what they have agreed to do;
>
> 2. Determine where this iteration is compared to where it could be
> and update your work-remaining tracker ( & task board, if used);
>
> 3. Work the product backlog (list of work for next iterations);
>
> 4. A dead Sheepdog is a useless Sheepdog; and,
>
> 5. Use all of your senses, including common sense, and remember
> that you have no authority.
>
> (from the CSM methodology v5)
after which the apprentice asked:
> No authority sounds rather scary!...in what context?:)
My reply:
The Team is FULLY responsible for the outcome of the work, the product, what is demonstrated to the Customer at the end of the iteration. It is in this context that the ScrumMaster is not a performer, and has no authority (i.e. to say 'we should do this' or 'here's how to approach it' or 'you missed that'.) The ScrumMaster must keep the team aware of this fact, so they have motivation to solve problems themselves in a 'whole team' manner, and not a CYA manner.
How to deal with this? Try 'I've noticed...', 'have you missed that?', 'I have an idea - what do you think?' 'It's up to you', or asking an OPEN question: 'I've noticed we have Requirements in 5 places. Do we need all of these?' At first people find this threatening, assuming I am passive aggressively saying we DON'T need these. No, it really is an open question, and you can assert that all you want, but the best way is to show it - ask them and REALLY let them tell you - no answer is wrong. For example: During the Requirements discussion, I saw BL tense up when another team member asked "do we really need to write JUnit tests?" So I asked "BL, what do we lose if we get rid of them?" and from his answer, the questioner quickly realized that quality and thrashing is at stake, and the issue died right there. Now that they have discussed it THEMSELVES they will hopefully continue to manage that issue themselves. If not, another question may be in order.
The ScrumMaster is the remover of obstacles (looking ahead, taking them out of the way, but not too far ahead in case of YAGNI: you ain't gonna need it). This includes getting things ready for the team, in time: room, needed materials and tools (computer, markers, paper, whiteboards, chocolate, DBA, lunch, meeting rooms, onboarding etc.) This is why the ScrumMaster should start work before the team, so they can hit the ground running.
The ScrumMaster is responsible for facilitation (getting people to play nicely together - oh my gosh, is this a challenge some days!! :-) But it is also rewarding, when you look and everyone is quietly collaborating and putting their best skills into the work.
The ScrumMaster is responsible for having the big picture (not of the work itself - the team is responsible for that) but the big picture of the Working of the team - the process. This includes stakeholder relations: getting things off on the right foot and letting the team handle it from there.
The ScrumMaster IS responsible for herding the cats in the right general direction (have you seen that wonderful EDS video ad about cat herders? It's hilarious!
Thanks for the good question. Hope this is helpful, or raises more good questions.
ciao
deb
Posted by Deborah Hartmann at 09:20 PM | |
Agile Axioms - A Brief Exposition
The previous article was interesting enough for me that I wrote it up real nice, got it edited, and published it as a downloadable pdf. Check it out at the Berteig Consulting Inc. Agile Work Resources page. There is also a whitepaper about Agile and Lean and a one-page Agile Work Cheat Sheet. Have fun!
Posted by Mishkin Berteig at 03:29 PM | |
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 | |
April 07, 2006
Great List of Quotes for Browsing
This list of Quotations for Learning and Programming is heavily weighted towards programming tasks, but there is a lot of very generally applicable wisdom. Here's a sample:
A common mistake people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools. (D. Adams)
Posted by Mishkin Berteig at 02:24 PM | |
April 06, 2006
Prioritizing requirements
The topic of prioritizing requirements came up in a recent meeting. Often the customer will say that all the requirements are top priority and are unwilling to place priorities in individual items.
The reason that we care about priorities is that we are going to implement the requirements in priority order. The most important things get built before the less important items. So, how do you handle the case where the customer says everything is top priority?
What I've found is that customers often think of priority and the order things get built as two separate items. If you explain that we can't build everything at once and need to decide which things to build first, the customer is usually more than willing to help with that. They're satisfying our need for priority but aren't thinking of it as setting priorities.
If you are using the XP technique of writing requirements on story cards then one technique for getting them prioritized is to hand the stack to the customer and explain that you will implement them in the exact order in the stack. If they wish to change the order of items then this is their chance to do so. It's helpful if you stress that the current order in the stack is fairly random.
I've found that when I do this, the customer will usually split the stack into two piles. One that really has to be done first because those cards are most important and then a second pile of less important cards that could be done in any order.
Cross-posted from Mike Bowler's blog.
Posted by Guest at 05:30 PM | |
Agile Work Seminar and Intensive Agile Work For Teams
Berteig Consulting Inc. has announced an updated public course schedule which includes a one-day introduction to Agile Work, and a four-day intensive course for teams. Both of these courses have been offered previously in a private setting and they have received loads of positive feedback (and suggestions for improvement which have been incorporated into these public versions). And yes... this is blatant self-promotion!
Posted by Mishkin Berteig at 10:21 AM | |
April 05, 2006
A Simple Analogy for a Simple Process
Mike Dwyer has written up a very nice analogy between the simplicity of the Scrum method and the simplicity of the waltz.
I used the waltz analogy a while ago in Scrum development, partially because I was looking at Tim Lister on the cover of Waltzing with Bears and partially because it is such a simple set of rule to dance by and mostly because of the last chick flick I was noble enough not to grab the switcher on was all about ball room dancing.Now wouldn't you know that the two remaining grey cells in my head bumped into a synapse - BAM Headache!
First for all of you who escaped taking dancing lessons the waltz is an extraordinarily simple dance. 1,2,3 1,2,3 right foot, bring left foot to right foot, one step to right. Bring left foot to right. Repeat.
This means Tim and the Bear can do it, rhythmically challenged people men like me can too and so can the folks in Ballroom Dancing. All are called waltzing – except; One is what you do to read about risk, one is beaten into you at dance class, and one is a form of competition that combines Olympic caliber training with the clothes racks from Vegas.
What makes them all the waltz? 1,2,3 1,2,3 right foot, bring left foot to right foot, one step to right. Bring left foot to right.
What makes Jeff's, or Glen's, or my use of the same principles of classic Scrum not Scrum? product backlog sprint backlog, product owner defined DONE. Timeboxed iterations, Daily Update, Impediment resolution, we all have a product backlog, we all have a product owner driven way to select work for a timebox, and we all communicate daily the critical information to each other and those that are concerned. Most of all we all measure by a simple DONE or NOT based on Product Owner acceptance.
Break anyone of these simple rules and you are not just failing at Scrum you are failing period. Goes for waltzing as well as Scrum.
Oh yes there is one more thing that waltzing and Scrum have and that is a rhythm capable of maintaining the dance at different tempos for different levels of skill. This way everyone enjoys what they are doing, does the job to the expectations of the Product Owner, and has the opportunity to improve.
Posted by Mishkin Berteig at 11:34 AM | |
April 04, 2006
Connecting Vocabularies - Cycles of the Mind
At the Coach's meeting ten days ago, several of the attendees used a series of phrases to refer to the learning process or cycle that Agile Work promotes. These vocabularies all have a different slant or implication but they all map to each other fairly well.
I have created a basic graphical representation of the relationships between the vocabularies.
The first is from Garry Berteig's Learning Circle. The second is Boyd's OODA Cycle. The third is attributed to be the scientific method. The fourth is from a Persian philosopher and teacher 'Abdu'l-Baha. The fifth is from Ken Schwaber's Scrum methodology.
If you have heard of other vocabularies for describing this cycle of learning I would love to hear about them. Vocabularies from the sciences, social sciences, humanities, arts, etc. would all be welcome.
I find that these various vocabularies are useful for different circumstances, but also for people who maybe don't "get it" with one vocabulary will "get it" with another. Our affinity to various words and the connections they make for us can be very powerful.
Posted by Mishkin Berteig at 11:54 AM | |