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!

 

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.

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.

0322141511a

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.

Who doesn't like cookies?

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.

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.