Communication Theory

Communication means—transmitting information from one person to another. In this article, I am discussing about the communication triangle approach. Your writing – and any other form of communication – needs to take all three parts of the triangle into equal consideration.
The Communication Triangle approach
In this approach, all you have to consider is: the intention of the writer/speaker, the subject the writer/speaker is writing/talking about, and the context and needs of the audience. However, depending on the needs one may focus on one aspect of the , and setting aside the other aspects.

• Writer/speaker-centered (Ethos)—focused on examining your own response or why you responded the way you did. Building trust by establishing your credibility and authority.
• Audience-centered (Pathos)—focused on convincing the audience to your way of thinking. Appealing to emotion by connecting with your audience through their values and interests.
• Subject -centered (Logos)—focused on trying to understand or make sense of the subject at hand. Appeal to intelligence with well-constructed and clearly argued ideas.

Writer/Speaker-Centered (Ethos)
Whether consciously or sub-consciously, your audience wants to know what is the motive of your communication. If you do not make it clear why you are presenting information, some of your audience will assume that you are not being very true, or that you are hiding something. Members of your audience may ask themselves:

• Are you providing information?


• Are you trying to educate?


• Are you making a call for action?


• Are you attempting to persuade others to change a perspective or firmly held belief?


• Are you presenting ideas for problem solving or analysis? Or


• Are you just trying to entertain?


• Where your expertise comes from?


• Are there any expert testimony?

Your audience will be trying to analyze your motives and what you believe, value, and assume. This information helps them determine your credibility and decide whether you are being sincere. So make sure you clarify: Who you are? Why you are competent to communicate? and Where your authority comes from?

Audience-centered (Pathos)
When you communicate, you need to understand your audience. Knowing them helps you avoid using technical terms when speaking to lay people, or “dumbing down” the content if your message is intended for professionals. Things to consider here include:

• What are the audience’s expectations?


• How will they use the information you provide?


• What is the audience hoping to take away after reading?


• Why are you communicating to this audience in the first place?

This is concerned as appealing to the emotions of the audience, which is known as pathos. If you want your audience to be moved by what you are saying. Ask yourself:

• What emotion do you want to evoke? Fear, trust, loyalty...?


• Do you have shared values you want to draw on?


• How do your audience’s beliefs fit with your message?


• Connecting with your audience through pathos is a strong means of gaining support.

Subject-centered (Logos)
Finally, your audience analyzes the content and circumstances of your communication.

• What events preceded the communication?


• What types of arguments are used?


• Are they logical and well thought out?


• How are they delivered?


• Where is the document or speech delivered?


• Is this communication necessary?

Here the emphasis is on logic and reason. Your audience need to follow what you are saying, for it to be believable. Ask yourself:

• Have I presented a logical, well-constructed argument?


• How do I support my claims?


• What evidence do I have?


• What are the counterarguments?

Using the Communication Triangle
When you are preparing consider the three elements required for effective communication. If your communication is lacking in any of the three areas, then you will decrease the overall impact your message will have on your audience.

Step One: Fully consider the impact your credibility has on the message. Failing to do so will risk leaving your audience unconvinced.

Step Two: Fully consider your audience; otherwise, they may feel disconnected and the message will be lost. Appeal to their emotions where this is appropriate and honest

Step Three: Fully consider the context of your message. Ensure you deliver it with a solid appeal to reason.

Key Points

• By applying communication principles to your initial planning, you can significantly increase the success of your communication and it will be effective.


• Your audiences will start believing in you, and will feel you are credible, you understand them, and you are logical.


• Balance Ethos, Pathos, and Logos.


• Ensure your communication is clearly understood, and received with correct intention.

When you reflect on -- how your message is perceived by your audience, you will be able to address their concerns even before they have a chance to rise.

Agile (Scrum Approach) for Documentation

Software development is guided by the increasing customer needs, and the challenge is to deliver usable software continuously. To address this Agile Methodology was developed.

Agile methods deal with unpredictability by depending on people and their creativity rather than formalized processes (Cockburn, 2002). Agile methods are characterized by short, iterative cycles of development driven by product features, collaborative decision making, incorporation of rapid feedback, and continuous integration of changes into the system under development (Highsmith, 2002). Thus, agile methods operate on the principle of “just enough method” because they avoid cumbersome and time-consuming processes that add little value to the software product development process.

In this article, I will focus on SCRUM approach for documentation that work with the development and deliver effective documentation for the product releases.

Scrum is an approach that offers flexibility, adaptability, and productivity to the software development and does not define any development techniques. However, scrum focuses on how the team members function in a constantly changing environment.

Scrum Process includes three phases: pre-game, development, and post-game.

Pre-game Phase includes Planning and Architecture cycle. During the planning cycle a detailed plan on various sprints, duration of each sprint is estimated. A Backlog list is produced containing all requirements that are currently known and they are prioritized (a sprint), the effort needed for its implementation is assessed, and the workflow (stages) of the doc cycle is defined. In the architecture cycle, the backlog items assigned are reviewed, changes necessary to implement the backlog items is identified, a high level design (topics and structure) of various doc deliverables for all the backlog items is produced, problems or issues in developing the content is identified, and finally reassign changes as required.

Development Phase is an iterative cycle. Here the Scrum team establishes the parameters such as time, quality, resources, tools, the Output format. The parameters may change during the process and they are observed and controlled during sprint review meetings of the development phase.

Post-Game Phase is an end of release cycle where all requirements are met and completed. In this phase the tasks such as unit testing, integration, and publishing is accomplished.

The Process We followed the monthly sprint, the sprint is started with sprint planning meeting and ends with sprint review meeting. However, we also had daily review meetings (Sun Rise Meeting) in the morning to review and control the variables.

During the sun rise meeting, the information is updated in a simple sprint backlog template in the wiki; burndown chart and cumulative flow diagrams are displayed in the wiki page for everyone to view the doc status. In this course the doc team knows where they stand and it makes them feel accountable for the successful delivery of the docs for the product. This also brings in transparency to the doc status so that other teams, such as Dev, QE, Product Management, and Project Scrum Manager feel comfortable. Since, we implemented the team has had remarkable success and increased efficiency. It has helped the team to present an objective data for the end of cycle sprint meetings, and it has helped in effective estimation for the new features that needs to be documented.

Using Sprint Backlog Sheet

At the planning stage of each sprint, we create a Sprint Backlog Sheet that contains 8 worksheets: CFD, Burndown, Instructions, Backlog, Stats, Sprint Goals, Allocation, and Impediments.

CFD Sheet: is a stacked area chart that displays what state each topic is in over time. It shows how many topics are in each stage for each day of the sprint. The sprint goal is to move all work items to the final stage (Release to Testing).

Burndown Sheet: contains visuals on

• Sprint progress - how is the team doing toward meeting the Sprint goal?
• Release progress - will the release be on time with the quality and all functionalities documented?
• Product progress - how is the doc deliverables filling out compared to what's needed?

Backlog Sheet: contains all of the topics that we agree to complete during the sprint. It also contains the following details: the backlog Item number, date created, the current sprint number unless carried over from prior sprint; can be blank, status, codes, activity type, initial estimate of hours to complete task, resource - team member(s) who signed up during planning session, and daily burndown updates.

Stats Sheet: contains the source data that generates the CFD. Every day we input the counts of work items in each state.

Sprint Goals Sheet: contains the sprint objective(s)

Allocation Sheet: contains work through allocation vs. capacity data

Impediments Sheet: contains impediments for the sprint on a daily basis

Daily Scrum Meeting
We have daily sunrise meeting in same place & time each day (15 minute max):
The following points are discussed:

• What a team member is accomplished since the last Scrum?
• What will h/she work on between now and the next Scrum?
• What impediments or obstacles do h/she need help with?
  

Some of the rules we set for the sunrise meeting are

• Punctuality is mandatory - we introduced punishments, some of the penalty ideas are donating Rs. 100 to team's favorite charity, Must tell a joke at the end of the Scrum, Must sing a song at the end of the Scrum
• Attendance at each Scrum is mandatory; few exceptions are allowed
• If a member will miss a Scrum, h/she must let the Scrum Master know
• Written status to Scrum Master
• Scrum Master reads status

For sample sheet contact me: upendranb@gmail.com

Estimating your Technical Writing Project

I was engaged in a pre-sales activity and one of the clients gave me few functional specs and requirement docs and asked me to come up with an estimate for an user guide.

That is when I began to look at different tools and methods used in estimating, and I explored the following options to provided estimates:
· Based on SWAG (scientific wild-ass guess)
· Based on previous (historical) data for similar kind of project
· Based on industry standard

SWAGing it Out
I went into a huddle with my team and asked them to take a guess and come up with an effort time for the project. Every one had different values; Team Member A gave 200 hrs, Team Member B gave 250 hrs, and Team Member C gave 215 hrs, and so on. I was in a fix, whom to consider? Each team member's expertise varied, one was good in information gathering, and the other in outlining the framework, and so on.

I took the approach of looking back at what we have accomplished (historic data), and come up with the number for the current set of requirements.

History shows that we made it; if we pursue, we can do it this time too

The challenge was to dig deep and pull out the numbers (effort time) from the documentation project we had undertaken earlier. When I began to do this, I found that for few of the projects I could get some values and for most I could not, because no effort was made in capturing the effort time for the entire life cycle.

Back to Square One, confidence on the estimate was low. Looking at the industry standard was the other option that was left with me to come up with an estimate.

How others estimate? What is the Ball Park? Can we apply it?

I assumed if I start googling out, I could come up with the numbers used by the industry for estimating. When I did that, I had the following questions:

· How many pages, one can produce in a day?
· How scope changes was handled?
· How complex was the project?
· How many new topics and updates were accomplished?
· What was the strength and experience level of the team members?
And so on.

The numbers for each scenario (complexity, audience, domain, skill, and so on) were different; however, I arrived at project estimates sans confidence or comfort.

There is no way to come up with an accurate estimate, estimates are just guesstimates. This thought was ethched in my brains, but I had to overcome this to be effective. Hence, I worked on a formula to increase my confidence over the estimates arrived based on standards used in an e-learning project estimation, and the formula is:

A (Estimates) = xx hrs
B (Project Loss Time) = 15% of A
C (Sub Total 1) = A + B
D (Labor Contingency) = 20% of C
E (Non Project Loss) = 15% of C
F ( Grand Estimate) = C+D+E

For example,
Estimates = 200 hrs
Project Loss Time = 200*15% = 30hrs
Sub Total 1 = 230 hrs
Labor Contingency = 230* 20% = 46hrs
Non Project Loss = 230*15% = 34.5 hrs
Grand Estimate = 230 + 46 + 34.5 = 310.5 hrs

I was satisfied with the result, and we submitted our estimates and were awarded the project. The estimates we made were almost correct (85% confidence), a great number to achieve. However, it did not stop me from exploring better ways to estimate effectively.

That is when I was introduced to Three-Point estimation technique. This technique gave me confidence in building an estimation process that has worked 95% of the time (for me).

The Three Point Estimation Technique is based on statistical methods (Normal distribution).
In Three Point Estimation, three values are calculated for every estimate:
a = the best case estimate (optimistic)
m = the most likely estimate
b = the worst case estimate (pessimistic)

These values are used to calculate weighted average (E value) for the estimate and a Standard Deviation (SD) where:
E = a + (4*m) + b / 6
SD = (b - a)/6

E is accounted both in the optimistic and pessimistic estimate, and SD measures the variability or uncertainty in the estimate.

To produce a project estimate:

· Decompose the project into a list of estimable tasks (Work Breakdown Structure)
· Estimate the E value and SD for each task
· Calculate the E value for the total project work as E (Project Work) = Σ E (Task)
· Calculate the SD value for the total project work as SD (Project Work) = √Σ SD (Task) 2

Then use the E and SD values to convert the project estimates to Confidence Levels as follows:
Confidence Level in E value is approximately 50%
Confidence Level in E value + SD is approximately 70%
Confidence Level in E value + 2 * SD is approximately 95%
Confidence Level in E value + 3 * SD is approximately 99.5%


Here is a tool developed based on Three-Point Estimation Technique for our documentation projects and it is based on ideas (templated designed) by Margie Yundt & Sherry McMenemy, Jim Chapman, and PMBOK . Although this tool is still a work-in-progress, I am happy to share what I’ve got so far.



For more on the tool, see my article on Three-Point Estimation Tool for Documentation.