Communication


Listen Now

Subscribe on iTunes

This week’s Software Process and Measurement Cast is our magazine with three features.  We begin with Jo Ann Sweeney’s Explaining Change column.  In this column Jo Ann tackles the concepts of messages and themes.  I consider this the core of communication.  Visit Jo Ann’s website at http://www.sweeneycomms.com and let her know what you think of her column.

The middle segment is our essay on commitment.  The making and keeping of commitments are core components of both professional behavior and Agile. The simple definition of a commitment is a promise to perform. Whether Agile or Waterfall, commitments are used to manage software projects. Commitments drive the behavior of individuals, teams and organizations.  Commitments are powerful!

We wrap this week’s podcast up with a new column from the Software Sensei, Kim Pries. In this installment Kim discusses software HALT testing.  HALT stands for highly accelerated life test.  The goal is to find defects, faults and things that go bump in the night in hours or days rather than waiting for weeks, months or years.  Whether you are testing software, hardware or some combination this is a concept you need to have in your portfolio.

Call to action!

Can you tell a friend about the podcast?  Even better, show them how you listen to the Software Process and Measurement Cast and subscribe them!  Send me the name of you person you subscribed and I will give both you and the horde you have converted to listeners a call out on the show.

Re-Read Saturday News

The next book in our Re-Read Saturday feature will be Eliyahu M. Goldratt and Jeff Cox’s The Goal: A Process of Ongoing Improvement. Originally published in 1984, it has been hugely influential because it introduced the Theory of Constraints, which is central to lean thinking. The book is written as a business novel. On February 21st we will begin re-read on the Software Process and Measurement Blog

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast.

Dead Tree Version or Kindle Version 

Next SPaMCAST

In the next Software Process and Measurement Cast we will feature our interview Anthony Mersino, author of Emotional Intelligence for Project Managers and the newly published Agile Project Management.  Anthony and I talked about Agile, coaching and organizational change.  A wide ranging interview that will help any leader raise the bar!

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

 

 

Listen to the Software Process and Measurement Cast

Subscribe to the Software Process and Measurement Cast on ITunes

This week’s Software Process and Measurement Cast features our essay on the ubiquitous stand-up meeting. The stand-up meeting has become a feature of Agile and non-Agile project alike. The technique can be a powerful force to improve team effectiveness and cohesion, or it a can really make a mess out of things! We explore how to get more of the former and less of the later

We also have a new Form Follows Function column from Gene Hughson. This column is the second of a three column arc on micro-services and architecture.  This installment is titled “Who Needs Architects? – Navigating the Fractals.” Check out Gene’s blog at Form Follows Function.

We also continue with Jo Ann Sweeney’s column Explaining Communication. In this installment Jo Ann addresses communication objectives and why setting and understanding those objectives BEFORE you start the communication process is a big deal if you are interested in being effective! Visit Jo Ann’s website at http://www.sweeneycomms.com and let her know what you think of her new column.

Next
In the next Software Process and Measurement Cast we will feature our interview with Alex Papadimoulis. Alex is returning to the Software Process and Measurement Cast to discuss Release. Release is card game about making software inspired by development strategies like Lean, Agile, and DevOps, and classic trick -taking card games. We also circled back to talk about continuous delivery and DevOps; a bit of lagniappe to add to a great interview.

Call to action!
We are just completed a re-read John Kotter’s classic Leading Change on the Software Process and Measurement Blog (www.tcagley.wordpress.com) and are in process of choosing the next book for Re-read Saturday. Please go to the poll and cast your vote by February 15!

Vote now at Software Process and Measurement Blog!

Shameless Ad for my book!
Mastering Software Project Management: Best Practices, Tools and Techniques as 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.

Listen to the Software Process and Measurement Cast 323

SPaMCAST 323 features our essay, “Five Factors Leading to Failing With Agile.” Not all Agile implementations succeed.  There are five categories of behaviors that lead Agile implementations toward failure. Failure due to these behaviors is avoidable if an organization recognizes them before the damage is done AND has the will to solve them. Forewarned is forearmed!

We also have a new Form Follows Function column from Gene Hughson. This column begins a three column arc on micro-services and architecture.  We begin with a “Microservice Principles and Enterprise IT Architecture.”  Check out Gene’s blog at Form Follows Function.

We also have a new Explaining Communication column from Jo Ann Sweeney.  In this installment of Jo Ann’s column she discusses determining relevant and helpful objectives for communication activities as a precursor to getting value from project communication.

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 8th.  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 Charley Tichenor and Talmon Ben-Cnaan on the Software Non-functional Assessment Process (SNAP).  SNAP is a standard process for measuring non-functional size.  As any developer knows, non-functional size can eclipse the functional requirements and therefore a tool that shines a light on that part of software development is useful for analyzing, planning and estimating work.

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

 

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 8th.  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.

Listen to the Software Process and Measurement Cast.

SPaMCAST 319 includes three segments! The first segment is our essay, Why Are Requirements So Hard To Get Right?  Much of the problems with requirements boil down to people, and 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.

The second segment marks the debut of Jo Ann Sweeny’s new column Explaining Change.  Jo Ann’s first installment tackles the need for defining the impact you expect communication activities to make – knowledge, attitudes, action.  Visit Jo Ann’s website at http://www.sweeneycomms.com/ and let her know what you think of her new column.

The third segment features a new entry of Gene Hughson’s column: Form Follows Function.  In this installment, Gene talks about his blog entry, Fixing IT – Credible or Cassandra? Gene points out that credibility is a precious commodity that, if squandered, is difficult to recover even when you are correct!

Call to action!

We are in the middle of a re-read of John Kotter’s classic Leading Change of 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 8th.  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

In the next Software Process and Measurement Cast we will feature our interview with Alfonso Bucero. We discussed his book, Today Is A Good Day. Attitude is an important tool for a project manager, team member or executive.  In his book Alfonso provides a plan for honing your attitude.

Upcoming Events

DCG Webinars:

Agile Risk Management – It Is Still Important
Date: December 18th, 2014
Time: 11:30am EST
Register Now

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars. The Software Process and Measurement Cast some support if you sign up here. All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you. Support the SPaMCAST and learn from the ITMPI.

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.

I am thankful for my WHOLE family (even the part not in the picture)!

I am thankful for my WHOLE family (even the part not in the picture)!

The fourth Thursday of November is Thanksgiving in the United States. Thanksgiving is a traditional harvest festival in the in the United States and Canada (different dates) although most cultures have a celebration to give thanks for the bounty of the harvest of the land around them. As with many holidays Thanksgiving provides a time for reflection about our lives and the lives of those around us. While I hope we are always thankful, there are times when it is important to actively remember what we have to be thankful for and perhaps even testify just a bit.

I am thankful for:

  • For my whole family and their families and their families families!
  • For my dog and my cats (and that they don’t fight too much)
  • For parents and people that are nearly parents
  • For my friends
  • For everyone that takes or has taken care of me
  • For everyone that has sacrificed so I can be who I am . . . whether they know me or not
  • For the world around me
  • For the problems I face (and for the solutions to those problems)
  • For sand between my toes and the occasional rock in my shoe
  • For the ability to think, smile and laugh
  • For the internet
  • For science and things that are not exactly science
  • For the readers of my blog
  • For the listeners to my podcast
  • For the fact that not everyone agrees with me
  • For the fact that at least a few people do agree with me
  • For mostly rational people and for the guy on the corner that does silly things occasionally
  • For problems to think about
  • For sunrises and sunsets
  • For the 24 hours in a day (even though sometimes I want just a bit more time)

There are probably lots of other things to be thankful for that have slipped my mind, I do not think I am alone in this predicament. Perhaps taking time on a daily basis to reflect on what we are thankful for rather than just on specific days like Thanksgiving would make the world a less stressful, angry and bitter place. But even if reflecting on what you are thankful for could not achieve this lofty goal perhaps it could add one extra smile to your day. A smile that you could share with someone else.

The language they understand is months and dollars (or any other type of currency).

The language they understand is months and dollars (or any other type of currency).

Clients, stakeholders and pointy haired bosses really do care about how long a project will take, how much the project will cost and by extension the effort required to deliver the project. What clients, stakeholders and bosses don’t care about is how much the team needs to think or the complexity of the stories or features, except as those attributes effect the duration, cost and effort.  The language they understand is months and dollars (or any other type of currency). Teams however, need to speak in terms of complexity and code (programming languages). Story points are an attempt to create a common understanding.

When a team uses story points, t-shirt or other relative sizing techniques, they hash a myriad of factors together.  When a team decomposes problem they have to assess complexity, capability and capacity in order to determine how long a story, feature or task will take (and therefor cost).  The number of moving parts in this mental algebra makes the outcome variable.  That variability generates debates on how rational it is to estimate at this level that we will not tackle in this essay.  When the team translates their individual perceptions (that include complexity, capacity and capability) into story points or other relative sizing techniques, they are attempting to share an understanding with stakeholders of how long and at what price (with a pinch of variability).  For example, if a team using t-shirt sizing and two week sprints indicate they can deliver 1 large story and 2 two medium or 1 medium and 5 small stories based on past performance, it would be fairly easy to determine when the items on the backlog will be delivered and a fair approximation on the number of sprints (aka effort, which equates to cost).

Clients, stakeholders and bosses are not interested in the t-shirt sizes or the number of story points, but they do care about whether a feature will take a long time to build or cost a lot. The process of sizing helps technical teams translate how hard a story or a project is into words that clients, stakeholders and bosses can understand intimately.

Include differences (learning styles, that is)

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.

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

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.

Communication is not usually uni-directional.

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.

« Previous PageNext Page »