Peabody Library

Peabody Library

The adult ego state is characterized by logical, practical thinking and reasoning (think of Spock in the original Star Trek series as an extreme adult ego state). The adult analyzes, solves problems and makes decisions using the rules that have been imprinted, information pulled from the environment, along with feedback from the parent and child ego states. Berne held that the adult was “principally concerned with transforming stimuli into pieces of information, and processing and filing that information on the basis of previous experience.[1]” The adult ego state has been likened to a tape recorder that is switched to record at ten months and then the recorder is switched off at 12 years old. The recordings (i.e. memories) then are used over and over to interpret and make decisions.  Maybe a better analogy would be that of an operating system that is past its final update, only the data changes. The adult ego state can stand in the way of change, if the change challenges the perception of balance, satisfaction or decision process in the adult ego state’s programming.

One of the key functions of the adult ego state is to validate data and actions from the other ego states and pass judgment. For example, Joe programmer overhears that Sid the programmer decided not to unit test the code he committed today and broke the daily build. Therefore, he has to miss the team outing.  Joe realizes that his training that developers should always unit test is true.

When Joe compares the new experience, the material overheard, to what he was taught he is using his adult ego state.  The material he was taught in technical school is used in the parent ego state (well most of it).

The adult ego state provides the same interaction and intermediation with the child ego state.

Another key function of the adult ego state is to interpret and react to adult-to-adult transactions.  Transactions from your adult to someone else adult are the simplest transactions.  They are essentially binary logic decisions based on the rules the adult ego state has recorded and the data at hand.  It breaks down when the two adults have different set of rules from which to make decisions.  The differences are a reflection of your culture. On a positive note, given the motivations of the adult ego state (balance, satisfaction and learning), adult-to-adult transactions are not generally acrimonious, even when they don’t end in agreement. The adult ego state seeks balance.

The adult ego state provides the rational decision-making process and acts as the logical control for the child and parent states.  Our adult ego state was formed before most of us enter the work place.  When pursuing organizational change or forming an Agile team it is important to understand the adult ego states of all those involved.  Understanding of how you audience will make decisions will help you to communicate effectively and get the decision you want.

[1] Berne, Eric. Transactional Analysis in Psychotherapy. Grove Press, Inc., New York, 1961. Page 15.

The phone many times is the communication tool of choice!

The phone many times is the communication tool of choice!

There are many challenges for distributed Agile, however one stands head and shoulders above them all – communication. At a recent speaking engagement, I asked the audience to write down three problems they were having related to distributed Agile. Communication was most commonly mentioned problem with approximately 60% of the responses. Finding solutions to the communication problems that plague distributed Agile teams is critical. Some that have been tried (and work to a greater or less extent) range from low tech (get up and walk across the building to talk to someone), moderate tech (video or telecommunications) to high tech (collaboration tools). The method is less important than the fact that each team member must understand the additional communication responsibilities that are required when working with remote team members.

There are several low-tech approaches that teams can use to stay connected and pass information amongst the team members.  When team members are in the same neighborhood (different floors, different parts of a building or separate buildings on a campus), standing up and walking over in order to talk face-to-face is more effective than sending an email. However, team distribution makes some of the most effective low-tech Agile tools less effective.  For example, card walls or paper Kanban boards don’t work well if everyone on the team can’t see them. Therefore, you will need to use other techniques. Once upon a time, video conferencing was just science fiction.  Today almost every laptop has a video camera and tools like Skype make connecting computer-to-computer free. Video makes communication personal.  It is easier to know someone if you can see them.  Another benefit to using video is that it shows a person’s face, which increases the amount of data passed during a conversation AND more importantly it tends to keep participants off their cell phones and email. Widely distributed teams will face time-zone challenges that require hardcore scheduling. Standard meetings (e.g. stand-up, sprint planning, retrospectives and demos) need to be scheduled to ensure everyone can participate (I use Doodle, but paper and pencil can work too). Other low-tech communication tools that many organizations use include end-of-day calls or notes to synchronize activities among the team members in different time zones.

High-tech tools and high price tags usually go together, which keeps some organizations from using commercially available tools. One high-tech tool that is purely oriented to communications is tele-presence. Tele-presence is like sitting across the table from your colleagues. It is video conferencing on steroids, lots of lights, lots of cameras and lots of electricity (therefore pricey). I have used facilities of this type and frankly they are better than high-end video conferencing. Tele-presence is almost as good as being in person. Given the expense, I doubt a typical Agile team would ever have on-demand access to tele-presence, but if you get a chance, try it.  Other high-tech tools typically combine collaboration tools and Agile project management features. Agile collaboration tools try to recreate the low tech tools (white boards, sticky notes and burn-down charts) so they be taken advantage of in a distributed Agile environment. I have used many Agile tools, examples include tools by Computer Associates, Rally and VersionOne, LeanKit Kanban and Kanbanery. All of these tools keep teams focused on the goal at hand though sharing information. Some commercial tools integrate video and teleconferencing along with wikis, task lists, scheduling, status tracking and reporting components. The problem is that none of these tools are as effective as an in-person team, but they are generally a lot better than the alternative of trying use repurposed waterfall tools or no tools at all. Tools that keep project information in one place make it easier for distributed groups work together.

Communication is best face-to-face with communications occurring not only through words, but also through facial expression and body language. Unfortunately, it isn’t always feasible. Distributed teams need to take steps to make communication as intimate as possible.  The best distributed teams use combinations of tools rather than to fixate on one. [WHAT DOES THIS MEAN?] They use the tools that are the least complicated, and that best fit each communication scenario. For example, combine standard meeting times (rotate the times, so no one always has to deal with the time zone pain) with videoconferencing and tool-based card walls to share stories and tasks. Finally, talk to each other as much as possible and as much as makes sense.

Everyone Communicates!

Everyone Communicates!

Without good interpersonal communication between development team members, the product owner and subject matter experts will need substitute interaction and communication with artifacts (requirements documents, design documents and more). The fallback when conversations aren’t productive, in most organizations, is to produce documents followed by the performing formal reviews on the documents and finally to accumulate sign-offs on the documents. This type of behavior is not considered to be Agile, lean or efficient. Communication is just about the most important behavior underlying successful Agile. All of the techniques used in Agile either anticipate or are geared to facilitate the transparent flow of information between all parties involved in the process. Unfortunately, old organizational habits are hard to break. Three of the most common problems impacting Agile communications are information hoarding, information hiding and avoiding feedback. Actively facilitating and encouraging the creation of communication channels inside and outside Agile teams becomes one the primary roles of Agile coaches, and will foreshadow successful implementations of Agile.

Constraining the transparent flow of information will negatively impact productivity and change. The same is true for overall organizational culture change or a single project: constraints on information flow make delivering value more difficult and more expensive. All projects, whether delivering software or supporting organizational change, depend on teams and team member knowledge. However, when people hoard information for either positional power or perception of personal value they negatively constrain information flow. For example, everyone involved needs to know the ultimate business goal of the project, so that the most effective decisions can be made.  Unfortunately, this piece of information is easily hoarded and provides the hoarder with a feeling that he or she is “in the know.” In these circumstances, information (and potentially knowledge) becomes important in its own right rather than delivering value to the organization.

Information hiding generally happens because someone is avoiding the delivery of bad news.  Hiding information breaks the bond of trust between the delivery teams and their stakeholders. Historically, the types of data that are hidden include being late, being over budget or not being able to deliver on commitments. An article in the Journal of Applied Social Psychology[1], presented data that as a project gets closer to completion, decision makers are more likely to conceal problems that may jeopardize the project. How many projects have you seen move from green to red overnight, just before delivery? Many types of bad news are VERY difficult to hide if projects are using Agile techniques.  Techniques such as burn-down or burn-up charts, daily stand-up meetings and demonstrations (or sprint reviews) are effective information radiators. In Agile, it is very difficult to avoid discussing status and how to re-plan on a daily basis.  Hiding the details of issues at a task level still does happen (this is especially true as the organization learns Agile). The hidden details and nuances are usually what keeps a task from being completed for a few stand-up meetings. The Scrum Master or coach needs to facilitate and teach the transparent flow of information at the team level. Ensuring the interaction of the team members will make hiding details that can make Agile ineffective less likely to occur.

Feedback is a major tool used by Agile teams to self-correct and stay on track. Unfortunately many people instinctively shy away from feedback due to defensiveness and fear. The words of W. Edwards Deming in his famous 14 points, insist that for organizations to be effective “Drive out fear, so that everyone may work effectively for the company.”  Where team, department or organizational culture inhibits the free flow of feedback, the culture must change. Education and training on delivering, accepting and using feedback need to be an integral part of embracing Agile in any organization.

The premise of Scrum and Agile is transparency (generate no surprises), inspection (detect variances early) and adaptation (adjust processes as needed). Open and honest communication between team members and stakeholders is necessary for Agile to emerge or to be implemented.  When hoarding or hiding information becomes an issue, it is easy for information to become the currency of one team member or team.  When information becomes the goal in its own right it will quickly obscure the real goal of any project, which is business value. When organizations, teams or individuals don’t use or listen to feedback there is no mechanism to self-correct from any of the other communication problems, which will kill any project or change program.


[1] Journal of Applied Social Psychology Volume 41, Issue 2, pages 401 428, February 2011

The team shows what they have completed.

The team shows what they have completed.

Demonstrations are a platform for an Agile team (or teams) to interact with stakeholders in order to solicit feedback and direction from a broader audience. A demonstration satisfies three primary goals: communication, risk mitigation and motivation.

The format of a demonstration varies from one implementation of Agile to another; however the basics always include the team communicating the work that was completed during the sprint. This allows the team to showcase the value they are delivering.  It facilities a discussion of needs, desires, risks and concerns between the stakeholders and the Agile team, which enriches the team’s knowledge.

Demonstrating how the team (scrum master, product owner and technical team members) developed the solution for the work units at the end of each sprint avoids many of the classic risks seen in waterfall projects.  One of risks the that a demonstration mitigates is the risk of surprising the stakeholders with a solution that does not fit their needs at the end of the project. Feedback helps the team and the organization avoid building throw away projects by continually validating the direction.

Demonstrations provide a vehicle to generate or reinforce team motivation. Demonstration allow the team to publicly showcase the work they have completed, which generates a sense of accomplishment.  A sense of accomplishment based on tangible results is a type of a feedback loop that helps build team confidence and while creating or reinforcing motivation. My professional observations of teams strongly suggests that motivation and confidence are directly related to productivity and quality.

Demonstrations are a tool to generate conversation about what is being delivered.  Because a demonstration occurs at the end of every sprint the team will continually be demonstrating the value they are delivering, which reinforces confidence and motivation. The act of demonstrating value provides the team with a platform for collecting feedback that will help them stay on track and focused on delivering what has the most value to the business.



Decisions made through a filter of misconceptions and based on imperfect knowledge generally lead to bad mistakes. All three of these concepts interact, therefore changing even one can have a positive impact. What choices do we have to reduce the possibility of making a bad mistake?

First, in most situations we rarely have the time or the ability to gather all the knowledge necessary to have perfect information, therefore the best we can do is minimize the amount of imperfect information being used.

Second, since we are human we are prone to misconceptions. A misconception is a mistaken belief. Misconceptions can be driven by many factors including culture, other beliefs, imperfect knowledge (yes, there is some co-variance) and poor communication.

Thirds, since many misconceptions are a reflection of poor communication, one way to avoid poor communication is to ensure that it is as intimate as possible. I would suggest a hierarchy of intimacy:

– Face-to-Face
– Video Conference
– Telephone
– Webinar/Teleconference
– Teleconference
– Text Chat
– Email
– Snail Mail

Fewer mistakes and even more importantly, fewer bad mistakes will happen if the intimacy of communications is increased. Every time you need to interact whether at work or at home ask yourself if you are using the most intimate communication channel available. If the answer is no, change the methods!


When a tree falls in the woods and no one is around to hear it, does it make a sound? Physics tells us the answer is yes. Likewise, does the question about project progress not asked have a consequence? Project managers might not have as tidy an answer as physics professors. But not knowing could leave a hole in our knowledge or in the knowledge of the team, increasing the potential for a mistake. For example, as a product owner it is important to understand the acceptance criteria for a story to know if it is ready to be fully accepted. In both the short and the long term, what we don’t know can hurt us.



I love books. In a recent interview on the Harvard Business Review podcast discussing, “Talk, Inc.: How Trusted Leaders Use Conversation to Power Their Organizations” the authors discussed the four I’s of communication. The first I was intimacy. Intimacy suggests that “personal conversation flourishes to the degree that the participants stay close to each other, figuratively as well as literally.”  Talking at someone does not build intimacy.

In order to build intimacy and real trust, communication has to flow in both directions and built on a shared reality. Books and other one way communications can help shape a shared reality but until we experience it in the real world it can only be ethereal. Personal conversations and interaction are experiences to shift shared realities into the real world.  Books are monologues, intimacy can only occur if you don’t just relay on monologues.

Do Not Erase



I can still hear the panicked conversation from down hall “I came in this morning and the plan we worked on all day yesterday is gone.” There were other words but I would like to keep this  business friendly. We have all probably had something like this happen. Early in my career as a consultant I got some great advice, “always have a backup”. Unfortunately you tend to get that kind of great advice right after something really bad happens. If you have not experienced the cleaned blackboard or presentation file that won’t open yet take this advice to heart.

Having a backup does not have to be a big deal. Keep a copy of your presentation on paper or thumb drive. If you have spent the day noodling on a black or white board use your cell phone to take a picture or go old school and copy everything down. I have always wondered if the cure for cancer has been made only to be erased overnight when someone misses the “please keep” sign.

3-28 2013 double cross

We all learn that in a presentation you should tell someone what you are going to tell them, then tell them and then tell them what you told them.  If you do that in the same breath, what have you really accomplished? Research has shown tedium can set in at most levels of repetition.

Any project that changes how people and/or machines will interact (unless the project is only delivering background functionality) will require explanation.  Just announcing the change in an ever increasingly louder voice doesn’t ensure anyone will understand or even pay attention.  Communication requires crafting and transmitting a message that can overcome the environmental noise, so that it can be received by the correct party. Repetition and volume are not the only tools you have to make a connection. Repetition, which has been called a penalty for not being memorable, is generally not sufficient to transfer complex information. Consider other factors such as making your message more to the point and compelling to make it more memorable. If marketing and communication are not your forte, check to see if your organization has a communication specialist. If the project is important enough, get consulting help.  If you focus on being memorable you won’t have to rely less of repeating the same message over and over and over . . .

3-17 2013 bank deposit

When I was working in retail, every day we made a deposit of the day’s receipts.  Once they were safely in the depository, we were done for the day.  While we would all want to bank the gains made through process improvement, our world is not quite as simple. Even though it is difficult to recognize and bank the gains from process improvement, I believe it is always critical. Try to recognize, celebrate and communicate your gains. Not banking your gains will leave you nothing for a rainy day.