SPaMCAST 363- Best 2013 Mix Tape

http://www.spamcast.net

Listen Now

Subscribe on iTunes

I am on vacation for two weeks and could not leave you without some Monday morning mind candy, therefore, we are doing two very special shows this week and next.  This week I have included the responses to the “if you could fix any two (or sometimes just one) things” question I ask at the end every interview from the three most downloaded interviews of 2013.  The top three and one extra were::

SPaMCAST 224 featured Mike Burrows. Mike focused his wishes on:

1. Changes agents need to take their role as change agents seriously.
2. Delay is expensive.

Link: http://spamcast.libsyn.com/s-pa-mcast-224-mike-burrows-kanban-values

SPaMCAST 246 featured Tobias Mayer. Tobias focused his wish on:

1. People, not management or consultants, need to own scrum. (One wish was enough for Tobias)

Link: http://spamcast.libsyn.com/s-pa-mcast-246-tobias-mayer-t-he-people-s-scrum

SPaMCAST 270 featured Alan Shalloway.  Alan focused his two wishes on:

1. Everyone needs to acknowledge there are laws of software development.
2. Assuming that everyone involved in delivering software is highly motivated.

Link: http://spamcast.libsyn.com/s-pa-mcast-270-alan-shalloway-sa-fe-lean-kanban

And just because I could . . . a bit of lagniappe, SPaMCAST 138 Featured Jo Ann Sweeney. Jo Ann focused her wishes on:

1. Reminding the listeners that change often starts before IT starts a project there we need to listen carefully to the stakeholders.
2. Project teams should care about end users.

Link: http://spamcast.libsyn.com/s-pa-mcast-138-jo-ann-sweeney-communication

If these excerpts tickled your fancy listen to the whole interview by clicking on the links shown above.

Next week the best excerpts from 2014!

 

SPaMCAST 321 -11 Reasons For Agile Success, Communication, and Cloud Development

http://www.spamcast.net

 

Listen to the podcast

SPaMCAST 321 features our essay on the reasons for success with Agile.  I asked friends and colleagues what they think are the top reasons an organization succeeds with Agile.  The answers were not always what I expected. We review the top 11 factors leading to success with Agile. Listen and share your feedback.

This episode also includes the next installment of Jo Ann Sweeney’s new column Explaining Change.  Jo Ann discusses whether communication always adds value to a project. Visit Jo Ann’s website at http://www.sweeneycomms.com/ and let her know what you think of her new column.

The third segment of this podcast is a new installment of the Software Sensei, where Kim Pries shines light on the area of cloud development. Development for cloud computing is red hot. Understand the nuances that developing for the cloud to enhance your effectiveness!

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change on the Software Process and Measurement Blog.  Are you participating in the re-read? Please feel free to jump in and add your thoughts and comments!

After we finish the current re-read will need to decide which book will be next.  We are building a list of the books that have had the most influence on readers of the blog and listeners to the podcast.  Can you answer the question?

What are the two books that have most influenced you career (business, technical or philosophical)?  Send the titles to spamcastinfo@gmail.com.

First, we will compile a list and publish it on the blog.  Second, we will use the list to drive future  “Re-read” Saturdays. Re-read Saturday is an exciting new feature that began on the Software Process and Measurement blog on November 8^th.  Feel free to choose you platform; send an email, leave a message on the blog, Facebook or just tweet the list (use hashtag #SPaMCAST)!

Next

The next Software Process and Measurement Cast will feature our interview with Clareice and Clyneice Chaney. Clareice and Clyneice provide insights and practical advice into how Agile and contracting can work together.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

Available in English and Chinese.

 

Learning Styles and Communication Problems

Include differences (learning styles, that is)

The team that completes a project will be different from the one that began the project. Each person on the team will have a range of individual experiences, and presumably, they will learn from these experiences. A mismatch of learning styles can result in communication problems. Communication problems act as a filter for what each individual learns by blocking or altering what the learner perceives.

Learning styles reflect an individual’s preference for how they learn. In many cases individuals mirror their own learning style when they share with others. Most, if not all, teams I have been associated with over my career have been comprised of individuals with different learning styles. This means that to effectively communicate and transmit knowledge, each team member must understand the learning styles of their team members (this is another reason why stable teams generally have higher levels of performance).

An example of the impact when team members do not understand each other’s learning style can be seen in a team I recently observed.  The team is a relatively new team and is distributed, with most interactions occurring via teleconference. Most team members have not had time to adjust to each other’s learning style; therefore members use their own learning patterns as a default when interacting. For example, one team member follows the logical/Lawyer learning style. When presenting information they build a case – fact by fact – in great detail. No one else on the team leverages this as their primary learning style. The great level of detail and the slow (but relentless) build to the conclusion leads to frustration and disengagement. On the same team, another member is verbal learner/Talker.  This person needs learns by hearing, and in many cases, by vocalizing each point.  This person presents information in the same manner as they learn, talking it through (with lots of Keynote slides … with no pictures). In both cases because the members are not aware of the learning styles of other team members communication is inefficient (and my observation is that it can be ineffective).

Teams that are centrally located generally recognize learning style mismatches based on visual and empathetic feedback and can self-correct (assuming that team members actually pay attention when they get together). Distributed teams generally need to take a more active approach to learning each other’s preferences. I recommend the following approach which can be used as a team-building exercise or as a retrospective exercise:

1. Before the exercise, create a couple of canned scenarios.  For example:
   1. Scenario One:  Pass status information about a trouble task, including a plea for help.
   2. Scenario Two:  Build consensus for a design decision.
2. Have each team member identify their primary and secondary learning style.
3. Share these styles with the team.
4. Once all team members have shared their style, have each team member select a method that is not their primary or secondary style and have them convey the information needed in complete each scenario. (Allow 5 minutes for preparation).

The goal of exposing the team to other types of learning styles is to push each person outside their comfort zone.  This serves multiple purposes. First, the process helps to build empathy. The process also reinforces the awareness that, on a diverse team, all messages need to be shared in a variety of ways so that multiple learning styles can easily absorb the information.  Finally, by learning and becoming sensitive to other learning styles, individual team members will expand their ability to recognize nuances in communications that lay outside their normal learning style. This will ultimately increase the effectiveness and efficiency of the team.

 

Why Are Requirements So Hard To Get Right? (part 2)

Not the most efficient communication technique

IT projects have been around in one form or another since the 1940’s. Looking back in the literature describing the history of IT, the topic of requirements in general and identification of requirements specifically have been top of mind since day one.  There are numerous definitions of ‘requirements,’ however at a high level requirements can be thought of as what the functionality developed by the project should ‘do’. Identifying requirements is difficult because it requires nearly a perfect storm of the correct process, involvement of the correct people for the business problem to be solved (before it is even defined) and an environment that is conducive to making all of the parts work together.  This confluence forms a set of three constraints that are overlaid on flowing time which ensures subtle changes are continually being introduced to all of the variables.  A breakdown of process, people or environment will reduce the effectiveness of the result or render it unusable.  The factors driving the people category are typically the most volatile and a seemingly least controllable of all of the variables within the requirements process.  This essay will focus on the ‘people’ category with subsequent essays focusing on process, environment and suggestions for solutions.

People have a major impact on the vagaries of requirements.  All of the strengths and weaknesses that individuals and groups bring to the table will influence the final requirements product. A few of the more intractable contributors to requirements variance are:

1. Lack of experience
2. Human nature
3. Communication
4. Organizational politics

This is the continuation of our discussion in which we address communication and organizational politics.

Communications problems can be secondary effects of other initiating events such as a software defect, a missed date or a dropped requirement.  The problem is compounded by the fact that many people just don’t communicate well because:

• They don’t listen when they think they already to know the answer,
• There are those that do not know enough about the business therefore can not interpret what they hear,
• There are interviewees that don’t choose to answer the question asked,
• Or interviewers that don’t ask the right question, and
• Or interviewees that are the wrong person to interview.

The list could go on further; there are just lots of things that can go wrong.  Communication is a combination of getting the right people with the right knowledge facilitated correctly all in the right place at the right time.

Organization politics can cause communication problems by creating filters between the speaker and listener.  One example of a problematic type of organization politics is a topic called solution-driven requirements (also called a solution searching for a reason or an answer searching for a question). In teams or groups that organize around specific technical solutions (vendor packages), they tend to look for ways to apply their solution to increase or maintain their organizational base. Unfortunately humans are great at recognizing patterns, and a solution is a pattern.  Pattern recognition is a survival technique however it has drawbacks for gathering requirements.  Gathering requirements with the solution already in mind is like a solution hunting for a problem. Anything that potentially blocks the ability for interviewees to express themselves freely or for interviewers to hear business needs can potentially create a scenario where errors or omissions occur. Remember when all you have is a hammer you’re apt to see everything as a nail rather than to consider that you might need some other tool.

There are a number of tactical solutions for all of these issues, however the first step to solving requirements issues that are people-centric begins with recognizing that a problem exists.  One best practice that I would recommend, taking a page out of the Agile handbook, is to use coaches to support the people working on gathering and managing requirements.  The role of coaches is to be the voice of the people focused inward on the team and the work.  A coach observes how work is done, provides support and instruction in a consistent and focused manner when and where it is needed.  This role is different from that of project manager which is externally focused, interacting with outside parties and clearing external roadblocks.  While people are not the only factor driving the quality of requirements, they are a critical factor.  Pay attention to how people are being deployed, provide support and instruction and make darn sure the right people are in the right place at the right time.

 

Four Types of Meetings

Who doesn’t like cookies?

Corporate calendars are crammed with meetings. More than once I have peered over a friend’s shoulder as we tried to find room on a calendar for a meeting, only to find that the task easier said than done. I once told my children that my job was to go to meetings. Unless your organization has made some tough choices, none of us are immune. The question is when do we actually get anything done?

Meetings are held for a variety of reasons:

1. To Communicate:  Meetings gather people together to give and get information. Presentations are often used as an information delivery vehicle. These types of meetings tend to be unidirectional (information flows in one direction). I have a very dim view of the value of Q&A sessions to generate two-way communication. This one of the easiest types of meeting to get rid of by substituting videos, memos, podcasts and blogs. These substitutes can be consumed as needed and without the cost of gathering people together.
2. To Work Together:  A second reason for meeting is gather people together to pool expertise in order to generate ideas, to create a deliverable or to perform a review of a deliverable. Group work seems to be used for all forms of work.  The synergy generated by good teams working together is well documented. But, is the group in a meeting a team? If not, then working separately with collaboration tools will yield an equivalent result without the overhead of a meeting.
3. To Make a Decision: A third reason for meeting is to make decisions. These meetings require gathering the right people with the right information at hand. In organizations with participative forms of management, this type of meeting is critical. In hierarchal/command and control organizations, these types of meetings tend to be advisory in nature, which makes them more akin to a communication meeting (see above).
4. To Get Cookies: The final reason to hold meetings is for human contact. Many offices are now embracing distributed teams and work-from-home solutions.  Even when everyone works in the same building, cube farms tend to be the norm. All of these workplace solutions isolate team members; meetings are a way to interact with people. These meetings tend to masquerade as working sessions or as communication meetings (usually without firm goals).  These meetings are needed, but the number and delivery vehicle need to be managed carefully so they do not overwhelm anyone’s calendar and do not stop real work from getting done.

I counted the number of meetings on my calendar for this week.  There are twenty-two meetings currently on my calendar; some begin as early as 4 AM! The majority of those meetings fit into the first three categories and one holds the possibility of lunch (a variant of cookies). Meetings can be productive, but first step starts with understanding the type of meeting being held.

 

When Good Numbers Go Bad: Communications, Part Two

This guy is an idol called San Simon that, in exchange for cigarettes and booze, guarantees good fortune.

Beliefs:

Beliefs act as a powerful filter that can cause communication problems. Deep-seated beliefs force the believer into a difficult position when it comes to challenging the status quo. When change occurs without the ability to challenge the rational for the change, it leads to confusion and possibly to conflict. This is a scenario where Good Numbers Go Bad. Beliefs aren’t necessarily based on mathematical or scientific fact. Once upon a time most people believed the world was flat. This belief constrained behavior. For example, a senior executive I knew firmly believed that education and training were not related to improved capability in his organization. If the organization stopped supporting training, his belief would potentially lower productivity, innovation, capability and potentially increase the need to outsource work. The workforce would not stay current or gain new skills.. Facts and the relationships between facts can are abridged through beliefs. Metrics professionals must continually create awareness so that everyone in the metrics equation keeps an open, questioning mind to extract the full value from numbers.

Just Plain Wrong:

One of the final classes of communication errors occurs when the metrics team publishes the information gleaned from a chart, graph or single number and it is wrong. In my mind, the most frightening words are “my interpretation of this graph is that the earth is flat.” Misinterpretation can be caused by a number of problems ranging from education and knowledge of the interpreter, active misinterpretation or the act of spreading misinformation (or that belief thing in the last section). Regardless of why the interpretation is wrong, damage is done. As soon as the misinterpretation is out there, the metrics program will be viewed as non-neutral and, potentially, biased. When measurement drives activity based on misinterpretation, the results can be erroneous business decisions with lasting implications. It can leave a bad taste in people’s mouths for a long time.

Zombie Hypothesis:

One of the worst errors made by humans is not publicly recognizing a mistake and trying to tough it out. The affliction can be encapsulated by the phrase “throwing good money after bad.” When applied to a metrics program, this affliction can lead to a scarcity of funds for metrics and SPI investment opportunities. Not facing up to your mistakes causes a scenario where Good Numbers Go Bad. The cost and effort needed to gather, analyze, report and react to the measures being collected will eclipse the value derived if you are living a lie. The Zombie Hypothesis is a variant of the Law of Crappy Process which implies that the worst, most incorrect data will become the de facto standard (real or perceived) for your measurement program. When you find a problem, recognize it, fix the process(es), then the definitions and re-implement the measurement. The effectiveness and efficiency of the measurement program will be improved. More importantly, you will inhabit the moral high ground of knowing you are measuring the right thing in the right way.

 

When Good Numbers Go Bad: Communication, Part One

Communication is not usually uni-directional.

One of the most tragic errors young metrics programs can make is the field of dreams syndrome: measure it and they will find it useful. Questions surface such as: ‘Why isn’t anyone using our measures?’ Or ‘Why isn’t anyone interested?’ Dashboards and reports are created and no one cares. There are at least two underlying problems: insular vision and lack of validation.

Field of Dreams

”A metric program is ineffective unless it is linked directly to a set of goals, mission or vision.”

— Michael Sanders, former CIO of Transamerica Life

The field of dreams syndrome begins with a metrics vision in a single person’s head (an executive or measurement guru). When this vision is then translated into tables and charts without socialization and presented as a fully formed measurement program – problem number one. In some cases this issue is not a problem, the culture in some organizations is used to strong individual leaders driving their points of view into the organization. It becomes a problem when the lack of socialization translates into a communication problem. Potential users do not know how the metrics created, where the data (and requests for that data) came from, what it measures and, most importantly, what to do with it. Why is Joe measuring my performance based on his view of what is right? Regardless of how the syndrome expresses, at this point good numbers have gone bad.

Misinformation:

“It is of paramount importance for an organization to ensure that the proper decisions are made based upon the best (most accurate) data available.”

—David Herron, David Consulting Group

Misinformation can be caused by numerous situations ranging from errors and misunderstandings to lack of knowledge. Any of these situations can cause a breakdown in communication. How you address misinformation once it’s found is an important topic. If misinformation is swept under the covers, Good Numbers will Go Bad. Directly addressing the underlying cause of misinformation is usually the correct answer. The corporate culture of some organizations can make it impossible to directly address the problem. Therefore making an indirect approach is sometimes the only means of addressing and correcting the misinformation. In either case, you need to find a means of addressing the problem. Remember that an un-lanced boil feasters. Like a boil, uncorrected misinformation will tend to fester and destroy the credibility of the metrics program, and perhaps the staff that maintains it.

Silence:

Good Numbers Go Bad not only when data or information is wrong or miscommunicated; it happens when the silence around the data collected is deafening. When data and information enters a black hole never to be seen again, it always causes a negative reaction. The first problem that occurs is that the effort to create the report data will quickly be questioned. This is an easy way to generate the wrong kind of attention during budget season. The second and more important point is that conspiracy theorists will assume that something is being hidden. When people believe something is being hidden, they will create their own story that will rarely be kind to the metrics program. Transparency must be the central principle for any metrics program. Show the data, explain what is done with it, that how it will be used and is being reported. Remember that show and tell really shouldn’t stop in kindergarten. Communication is the prescription for Good Numbers Gone Bad.

Monologues:

Late night television is the home of the monologue. Jay Leno and Jimmy Fallon use monologues to make us laugh. Their only feedback is the laugh track. The unidirectional flow of the information is an important feature of a monologue. Late night comedy and metrics presentations shouldn’t have this in common (albeit a bit of levity is probably a good thing). Most metrics reports and presentations are approached as if they were monologues rather than dialogs.

The monologue approach occurs for a number of reasons. The first is the confusion of the volume/value attribute. Metrics programs need to show value, and the two attributes of volume and value are sometimes confused (the more the merrier isn’t the case here). When these concepts are confused, it seems that the goal of a metrics presentation seems to be to show every bit of data ever collected, crammed into charts (or slides). Then to tell anyone who will listen what they mean (also known as death by slides). Focusing on volume chokes the ability to hold a dialog. Volume and value/quality are unrelated attributes. An old adage states, ”a designer has achieved perfection not when there is nothing left to add, but when there is nothing left to be taken away.” (Read any or all of Edward Tufte’s books.) Design your presentation to evoking action by the recipient. Simplicity and minimalism are concepts that need to be used when designing your presentation tool. Show pictures, but have the data. Once you have a tool to aid your communication, the next step is to use the tool to facilitate a dialog as the basis for creating understanding. A dialog provides a platform for the metrics team to affect behavior of the organization and to absorb information about how work is being done. Wikis and blogs are means of creating this type of dialog.

Another idea to combat monologue is to recognize that presentations and handouts are not the same thing. Presentations are structures to create dialogs; handouts are one-way vehicles, monologues.

 

Transactional Analysis: Transactions

Transaction Analysis

Transactional analysis, originally developed by Dr. Berne, defined the transaction as the basic unit of social intercourse. When two people communicate, one person initiates the transaction. The person to whom the transaction is directed responds. Basic transactional analysis involves identifying the ego state that initiated the transaction and which ego state responded.  There are three types of transactions: complementary, crossed and ulterior, all of which you will encounter on a daily basis.

The crux of transactional analysis is the rule that effective and successful communications must be generated from complementary transactions. Complementary transactions complete a transit from the receiving ego state back to the sending ego state. If the transaction is from adult to child, the response must be child to adult.  For example, seeing that Paul the programmer is agitated during a team discussion, Sari the scrum master pulls Paul aside and says . . .”Paul you seem to be upset, tell me what you’re feeling.” The transaction goes from the scrum master’s nurturing parent to Paul’s child. If Paul responds, “I was feeling cut out of the conversation and I need help,” he would be responding from his child state to Sari’s parent.

Crossed transactions occur when the communication transaction does not return directly to the state it came from.  In the saga of Paul and Sari, if Paul had responded from his adult state to Sari’s adult state the communication would be confused and ineffective. For example, Paul asked Sari for a definition of the term upset. A crossed transaction occurs when an unexpected response is made to the stimulus. Crossed transactions occur for many reasons ranging from misinterpretations (the receiver does not understand the transaction) to misdirection (the receiver want to avoid the conversation). Crossed transactions can escalate into anger unless one (or both) parties disengage or redirects the conversation back to complementary patterns.

The third type of transaction is ulterior. Ulterior transactions always involve two or more ego states in parallel.  One portion of the transaction is generally verbal and the other an unspoken psychological transaction.  For example, if a manager tells an employee, “this is a really intriguing problem, but it it might be too hard for you.” This message can be heard either by the employee’s adult (I don’t have the capability to deal with this scenario) or by the employee’s child (I will do it and show him!).  Ulterior transactions are manipulative and increase the risk of communication failure and conflict. A better approach be to avoid innuendo and to break the conversation down into a set of complementary transactions exposing the meaning of each step in the conversation.

Teams are built on effective communication.  Very little productive work can be accomplished if communication breaks down. Agile team members need an understanding of the three ego states and how the transactions between the states can either be complementary (effective), crossed (ineffective) or ulterior (manipulative). Transactional analysis provides a framework to understand whether our communication is effective and how to get it back on track when it’s not.

 

Transactional Analysis: Strokes, Daily Process Thoughts

Even elephants crave strokes.

Transactional analysis defines two basic units of measure – the transaction and the stroke. The transaction is the unit of social intercourse and the stroke is the unit of social action. Strokes are when one person recognizes (verbally or non-verbally) another person. Rene Spitz incorporated the concept of a stroke into transactional analysis; when he observed that infants deprived of handling were prone to emotional and physical difficulties. We all hunger for social contact, and in fact suffer greatly without it. Sales guru David Sandler, in his book with John Hayes, Ph.D, You Can’t Teach A Kid To Ride A Bike At A Seminar suggested that everyone is stroke deprived. Therefore we are always looking for strokes that provide recognition, either positive or negative.  In order for a team to reach maximum effectiveness each individual needs to get the positive strokes they need, while minimizing the negative strokes. There are four basic variants of strokes – positive, negative, unconditional or conditional.

Strokes can be positive (“That is great idea”) or negative (“That is a horrid idea”). Strokes can have different values depending on the source and the perceived veracity. For example, a peer telling another that a business solution was brilliant will have more value than a simple “good morning” even though both are positive strokes. In this example while the “good morning” is a positive stroke it is undifferentiated and would be discounted more than the specific stroke about work done. Agile teams provide an excellent platform for delivering and receiving strokes.  In Daily Process Thoughts, May 2, 2013 we discussed how team boundaries impacted team effectiveness.  Team boundaries help establish trust which amplifies the value of strokes. Getting enough stokes from the team reinforces membership and increases teamwork.  Teamwork and productivity are highly correlated.

Strokes can also be either unconditional (“You are a great person”) or conditional (“You are a great person for solving my problem”). An unconditional stroke is for being you, and a conditional stroke is for having done something.  Positive conditional strokes are a powerful motivational tool when they are genuine (when you think they are not genuine you naturally discount them). Because unconditional strokes pertain to characteristics which occur naturally they can not be earned.  For example a piano player might be given a stroke for having long graceful fingers and that would be unconditional. If he was stroked for his performance, that would be conditional.  Unconditional strokes are often used as softeners when coupled with a negative stroke.  For example how many time have you heard someone begin a conversation with “You are a smart person” (or some variation) which is a positive, unconditional stroke only then to whack them with “but that was stupid” (negative, conditional stroke).  The last example could also be considered a counterfeit stroke which is giving something positive, then taking it away again.

Giving strokes is positive feedback loop that reinforces behavior.  When there does not seem to be enough strokes to fulfill an individual’s need, they will seek out negative strokes rather than getting no strokes at all (i.e. being ignored). While observing a daily stand up meeting for a few days, I noticed one individual who came late, daily, for which he was called out, daily.  Upon investigation I found that the person was not interacting much with the team, and was therefore receiving little feedback.  Coming late to the stand-up was his mechanism for getting a negative, conditional stroke. As an outside coach, I facilitated an impromptu retrospective to discuss how we could get everyone involved in a positive manner.  The team performed better afterwards and everyone showed up on time to the stand-up meetings.

Everyone needs strokes and no one gets enough. We are all looking for ego stokes in all of our interactions. Strokes are delivered by transactions between the three ego states defined in transaction analysis.  Strokes are powerful tools for any team to use to reinforce membership (your teammates will help satisfy your need for strokes and you can do the same for them) and for reinforcing competence. In the end all strokes have value, and when there aren’t enough positive stroke we will seek negative strokes which slowly poisons the team environment.  Focusing on delivering high value, positive strokes will foster an environment of trust for teams to be at their most effective.

 

Transactional Analysis: Child Ego State

Anyone can speak from the free child ego state.

The child ego state represents the part of us that reacts to the world emotionally. We learn this role as we experience events and simultaneously record our emotions. The bulk of these emotions are recorded from childbirth all the way up to approximately 5 years old, which marks the age of social birth. There are two sides to the child ego state – the adapted child and the free child.  The adapted child reacts to the parent state either with obedience and submission, or sulking and defiance. The free child state is characterized by openness, spontaneity and boldness. The child ego state tends to be feeling and very egocentric. Three patterns of communication involving the child ego state are very common in IT environment, parent-to-child, child-to-parent and child-to-child transactions.

As we saw in Daily Process Thoughts August 13, 2013, the parent-to-child communication channel is common in all organizations regardless of whether they are hierarchical, participative and Agile. In command and control organizations, a typical parent-to-child transaction is for the manager to tell the employee what to do. As a result, the employee/child can react in a range of ways from acceptance and compliance to passive, or even active, resistance depending on whether they are answering from the adaptive or free child ego state. I recently saw a tester that was informed by her boss that she need to regression test the application she was working on over the weekend (the boss was speaking from the controlling parent ego state).  The tester responded with an angry, whiney tirade about having her weekend wrecked to fix the “crud” from the development team (she responded from the child ego state, in essence she threw a fit).  The manager, continuing to operate from the controlling parent space, ended up forcing her to accept the work. If the manager had switched to a more nurturing parent state, he may have deescalated the conversation to shift the tester’s ego state either to the adult ego state or closer to the free child state. If the manager had been able to shift the discussion from the aggressive, adaptive ego state less damage would have been done to the manager and tester’s relationship.

Generally when we are unsure, nervous, unwell or need someone to guide us, we will tend to respond from the child ego state. In the example, the tester was unhappy and was trying to engage the manager’s nurturing parent ego state. When a child ego state engages a parent, they are looking for someone to provide direction and leadership. On an Agile team, the concept of self-organization and self-management means that any team member can and should step in and provide the support from the nurturing parent ego state.

The third common child ego state interaction in IT departments is between child ego states. As noted earlier, the child ego state has two varieties, the adaptive and free child.  For example, when I observe teams one of the interaction patterns I look for is healthy horseplay or joking around. I generally find that this type of free child to free child transactions is a sign of a closely-knit team.  Teams in which large quantities of interactions are between adaptive child states are usually troubled. This is often evidenced by team members whining and complaining. In this case, use facilitated retrospectives to find the root cause of the team’s problem.

Humans are emotional creatures therefore we communicate from and to the child state often. Some of the communication is healthy and some of the communication is less healthy. Transactions from adapted child ego state are generally viewed negatively (e.g. confrontational, rebelliousness, anger or whining), while the transactions from the free or natural child ego state are positive.  Scrum masters and coaches need to be able to recognize which ego state communications are coming from and how they are being received so they can help ensure that communication is effective and healthy.