Narcissism of Small Differences

Narcissism of Small Differences
By Thomas M. Cagley Jr

Audio Version:  SPaMCAST 185

Every interview I do for the Software Process and Measurement Cast teaches me something about our industry and the people that populate it.  Occasionally a topic is brought up that sets me off on a new path of exploration and that changes how I interact with the world around me. The interview with Corey Haines in the SPaMCAST 182 was one such interview. During the cast, Corey referred to the concept of the “narcissism of small differences” as a barrier to delivering value.  His point was dead-on but after I did some research I discovered that, like many other concepts, this one is a bit more complicated than I originally anticipated.

Why did the concept of “narcissism of small differences” jump up on my radar?  First, I think we all can think of examples of meetings or decision processes snarled by minutia after the really important parts had been agreed upon.  Why do we seem to get hung up on the small things as if they were really as important as the big points?  Secondly, software development, maintenance and support functions are team activities.  In most cases it is not just one team but rather teams interacting with other teams, each team having its own membership requirements and variable relationships with those outside the group. Anything that interferes with a team’s ability to function and communicate has a downside that can ripple outward and slow the delivery of value.

The Wikipedia[i] entry for the “narcissism of small differences” traces development of the term to Sigmund Freud in 1917.  The entry goes on further to describe the concept in both in terms of building communities and differentiation of outsiders.  Dr. Glen O. Gabbard, M.D., suggests that Freud’s concept of “narcissism of small difference” provides a framework to preserve a feeling of separateness and self in groups. Freud and Gabbard were not viewing the concept in terms of organizations or software development; however taking a broader view is not difficult.

Behavioral affectations like “narcissism of small differences” evolve because they have value.  That value may be to the group, by making members obvious to each other or as a tool to resist new ideas that are perceived to be detrimental to the group or individual.  As my daughter Meghan put it to me in an email exchange on this topic, “There is a duality to the idea.”  The focus of small differences can be either  a barrier to communications and decisions or  a tool to unify a team.   It boils down to that there are side effects—that some are good and some are not.

Side Effects:

Let us begin by postulating that organizations are naturally hierarchical and that position within the hierarchy is affected by competition.  Any competitive advantage can be enough to distinguish a winner or loser.  The focus and advertising of small differences can be used as mechanism to generate a competitive advantage by focusing attention.  Even in a meritocracy small differences can be used to focus attention (the wise amongst us might call this marketing) which might just be the thumb on the scale of success or to block ideas.  Minor differences are mechanisms to express and identify membership in groups within the hierarchy.  A corollary to this thought is that expressing minor differences is a tool to attract positive social attention (assuming the difference is not significant enough to cause you to be ostracized).  Positive social attention has been shown to be positively correlated to position and status within hierarchies.  Tactics that increase the right type of attention will be reinforced and emulated because they are viewed as a tool for promotion.

Another side effect of “narcissism of small differences” is that it can lead to micromanagement. Being micromanaged kills innovation and motivation. Micromanagement is deadly to the development of self-organizing teams.  How does “narcissism of small differences” lead to micromanagement or the failure to delegate?  The problem occurs when narcissism leads to believing that there is only one way to solve any problem and wanting things done “just so.” While this type of behavior can occasionally lead to positive outcomes (positive feedback for bad behavior), more typically it can cause a leader to waste time and effort in attempting to make sure work is done exactly the way he or she wants even when the level of precision would not change the outcome or value delivered.

A third consequence of “narcissism of small differences” is that it can create barriers between people and groups which create communication problems.  The communication problems are caused when focusing on small differences raises barriers between people.  Barriers cause friction when sharing and interpreting data reducing the effectiveness of communication.  Formal and informal groups are integral to how work is done in most information technology development.  Teams are an example of formal groups while informal groups can develop based on topics as “trivial” as support for a sports team or as important as a development framework like scrum (popular agile project management framework).  Groups that create strong boundaries or evoke a “we/they” equation can lead to insular thinking.

What seems like a total negative can be used as a benefit for building a team or a community that can act quickly.  The identification of small differences can be used as signals to bring people with similar ideas together, then develop boundaries to glue them together.  In today’s environment the internet provides a platform where groups that would not have been sustainable can become more sustainable by increasing reach.  The benefit to groups with minimal differences is decision speed. Homogenous groups can come to consensus quicker than diverse groups (how good the solution might be is another story).

Solutions

Reducing the impact of “narcissism of small differences” is not as easy as waving a magic wand.

Real diversity is a mechanism for reducing the negative impact of “narcissism of small differences.”   Teams built with diversity still have to go through the process of becoming a team (the Dexter / Sibbet Team Performance Model is one model of team development).  The process of building a team includes building trust and understanding team goals and roles.  Because a team requires trust, it will need a means of recognizing differences or removing those that can’t be accepted.  Team building exercises are generally used technique for building trust.

Diverse teams will need to work a bit harder on decision making.  The effect of diversity on decision making is felt in the arena of consensus driven decisions.  Consensus is a mechanism for accepting that some differences may still exist when exiting a decision process.  Consensus generally means that not everyone is 100% in agreement however everyone can support that decision.  The process of coming to a consensus requires that all related views are heard (all that want to be) and the small differences can be lived with.  Where individuals within groups fall prey to “narcissism of small differences” arriving at decisions by consensus becomes problematic unless the group continually acquiesces which defeats the benefit of group-think.

One caution on the diversity cure is that realistically much of the minutia we hold so dear is really a reflection of homogenization rather than diversity.  The differences we identify are a reflection of how the same our positions really are at the base level.  We manufacture scenarios of artificial uniqueness through accentuating small differences.  My father wore a bow tie in a sea of “normal” ties as a statement of uniqueness.  Whether the minor differences equate to true diversity is a greater question.  Diversity has been linked to innovation; however if we are merely masking our sameness we are less likely to have diversity in thought.

Another mechanism for addressing “narcissism of small differences” is to change the rules by making the outcome of any decision more important and the stakes higher for failure.  Raising the stakes will create a scenario that will foster alliances by making failure untenable.  High stakes will sweep small differences aside.  An example of this effect, I recently heard, was when two Americans of different social backgrounds met in a third class train in India.  Despite having many small differences the two became immediate friends for the trip.

Another coping mechanism is to actively listen. Active listening is communication technique in which the listener feeds back what he hears to the speaker.  Active listening makes sure you are listening rather than just waiting to talk.  Active listening reduces misunderstandings and conflicts and strengthens cooperation.  Listening will allow you to more easily identify the difference between what is important and what is minutia.
Summary

Why is “narcissism of small differences” a topic of discussion? Because obsessing and defining who we are based on small differences can hamper our ability to deliver value…unless managed.  Barriers that are erected between groups hamper the free flow of ideas and information leading to the possibility of suboptimal solutions. Finally, defining others as “not us” is a mechanism to dehumanize outsiders which makes it easier seek conflict rather than cooperation. When you let minor nuances or differences become a barrier to diversity of thought or constrain the delivery of value, you have a problem.  The next time you feel the urge to debate the size for footnotes, think about whether the time and energy would be better spent and if winning the debate matters in the grand scheme of your project.

---

[i] http://en.wikipedia.org/wiki/Narcissism_of_small_differences

 

Narcissism of Small Differences, Listener Comments

I just posted the audio version of my essay, “SPaMCAST 185 – Narcissism of Small Differences, Listener Comments“

I will post the text soon however in the interim listen to the podcast and take a peek at the mindmap!

 

Agile Release Planning Is A Necessity

Agile Release Planning Is A Necessity
Thomas M. Cagley Jr.

Audio Version:  SPaMCAST 183

It has been said of Release Planning that it is not needed and a waste of time by those who feel that release planning is a retreat from agile. Alternately, it has been called both a black art and a communication vehicle by those who recognize it as a need. Simply put, release planning is contentious.  Why the consternation over something so simple? Part of the angst is a relic of the past and part is a flaw in basic human nature. The first part, memory of over planning, we all have seen in some project and program methods and the second flaw is one of basic human nature in that when something is said it tends to be remembered (a delivery date for example).

A software release can result from one or many iterations. A release plan is a tool that describes what is to be included in the next release or releases based on what the team and product owner knows at a specific point in time. The release plan represents a top-down view of what will be delivered and when it will be delivered. The process required to generate a release plan leverages the knowledge of the team’s (or the teams’) velocity and a sized and prioritized backlog.

Jim Highsmith, author of Agile Development Ecosystems wrote, “A big part of an organization becoming agile is finding the appropriate balance between anticipation and adaptation.” Anticipation can be formal, big up-front planning that is integral to strategic planning and accounting.  The tension is immediately established between the need to know and the need to adapt because agile techniques feature continuous feedback as a tool to determine and communicate when a feature will be delivered or even when a project will complete. The problem created by not knowing precisely (not that it’s ever very precise) when something will be delivered is that the business needs to know or at least wants to know, and they tend to control project funding and, in a broader sense promotions.  Saying that a feature or project will be delivered someday over the rainbow or just “trust me” is usually a career-limiting move.

Why should an agile project develop a release plan? 

Release plans act as a planning and communication tool to combat over-optimism. As a planning tool, the release plan helps the team know if what they are being asked to deliver is possible in the timeframe they have been given or how long it will take to deliver what is on the backlog. While this might feel like a big upfront plan (a regression from agile), a release plan lacks the overbearing level of detail that leads to a false sense of precision that is typically found in a big upfront plan.

A release plan can also be used to project roughly when or whether enough value will be delivered to meet the ROI projections. ROI projections are part of a business case that forms the basis for the business deciding to begin most projects. The release plan is a reflection of what we know now and will continuously evolve which means the value delivered can be continuously evaluated.

I would suggest that a release plan provides information that is critical for product owners, CIOs and other stakeholders to anticipate the future of their business. Anticipating the future is something that every executive wants to be able to do; something their stakeholders require from them.  This is a casual loop that we might not like, but one that will be slow to be unmade.

Finally, Mike Cohn’s agile planning onion calls out the need for release planning for the reasons we just discussed; it is also a simple tool to help teams within larger project know how the jigsaw puzzle that is a project will fit together in the end.  Knowledge of the end of the journey helps teams know where they’re going which improves morale and motivation.

Creating a Release Plan

The construction and maintenance of a release plan requires three basic components: velocity, prioritized backlog and elbow grease. Velocity is the average number of units of work delivered per iteration, the average number of story points is a typical measure of velocity (productivity is a similar but much maligned metric). For example, if a team delivers 30, 40 and 50 story points in three iterations, their average velocity would be 40 story points. Velocity will be used to anticipate how much work will be delivered (approximately) in each iteration.

The second component is the backlog. The backlog is a compilation of the work the project anticipates to be delivered over some period of time. The elements of a backlog can represent more than a release or single project. I’ve worked with backlogs for both maintenance and new application development that were continuously developed, maintained and groomed.  In all cases the backlog represents the product owner’s priorities and should be sized using the same metric that was used to create velocity.

The final ingredient is elbow grease which comes into play once you have calculated (or estimated early in a project) the team’s velocity and a prioritized and sized backlog has been established. When the components are ready the core agile team meets to establish the release plan. The process of layering iterations into the backlog based on velocity sets the “what will be delivered” within a discussion of when. The initial release schedule can be used to communicate the order in which features can likely be delivered. Once created, the overall release plan of prioritized features, epics and stories is fed directly into the iteration planning process. 

The process of creating a release plan is rarely as smooth as dividing the features by the average velocity.  Dependencies, risk mitigation strategies (do the hard stuff first) and the granularity of features must be accounted for when planning.  I think of the process as a combination of basic math and building a mosaic.  A release plan can’t be viewed as precision vision of the future.  The release plan is approximate for many reasons; however, biggest reason is that the product owner can and probably will reprioritize the backlog over the life of the project. The release plan can be used to continually test whether the delivery date (or dates) is feasible based on the approach being taken. This is not an exact science, perhaps this why some think of release planning as a black art.

The initial release plan is understood to be a rough prediction. When initially created, it must be detailed enough only to get the project started by predicting that the project can be delivered, that it will deliver enough return on investment to more than pay for itself or that it will be able to deliver the functionality required within the currently known constraints.  Trying to create a release plan that provides absolute precision is tantamount to trying to predict the course of the stock market in granular detail.  In Agile projects we continuously plan and correct the course as we go, rather than believing we have the power of clairvoyance. One of the primary mechanisms for course correction is the release plan which will evolve in response to feedback.  Feedback includes identification of new stories, stories that take more or less time or basic changes in business direction.

So what’s next? Remember the release plan is just a plan; it will change. It is not to be created once and forgotten.  In order for a release plan to have value, it will require leaders to spend time grooming the backlog.  Grooming includes breaking down and re-estimating larger stories and epics.  Update assumptions about velocity at the end of every iteration and using that update to determine the impact on the release plan. I suggest that in each iteration review, the team should discuss with the product owner and other stakeholders whether the project is on course to deliver what they want and what can be done if the project is not meeting their goals. When the plan for any specific story changes (and it will), review the changes with the product owner. The release plan is a tool to show the impact of change.

A release plan is a tool. Can any project leader answer the question of whether a project is possible without being overly optimistic without a simple tool? Even when an answer can be logically framed, can it be proven? A release plan can be used to provide a visual frame of reference to indicate what is possible and how changes or additions to the backlog will affect the project. What is possible is a question that can only be answered in terms of now, what is possible based on what we know and can legitimately foresee. The problem is what can be foreseen is generally not a perfect forecast. A release plan created from a team’s average velocity and a prioritized and sized backlog is good start.

 

Manufacturing, Engineering or Craft?

Manufacturing, Engineering or Craft?
By Thomas M. Cagley Jr

Audio Version in SPaMCAST 181

A few weeks ago I sat next to a gentlemen on a flight to Albuquerque. After talking through a couple of glasses of wine we found we were in related fields. As the conversation progressed he confided in me that he did not understand why software projects were never on time, never on budget or never exactly what he wanted — since software development was engineering and he’d been told by his consultants that development was like a factory. I paid for the next round of wine as I tried to persuade my new friend that building, enhancing or maintaining software was not really like assembling a car.

Why has the manufacturing model as a metaphor and therefore the ideas of Fredrick Taylor been so firmly entrenched in IT? In reality, is IT a creative model (science or craftsman) or a manufacturing model (assembly line) more accurate in describing the behavior required to deliver value from development? Which metaphor is more predicative? If we introduce the term software engineering, does the use of the word, engineer complicate how IT personnel are perceived? Does the perception create a set of expected behaviors for software development and maintenance personnel that makes it harder to deliver value than it needs to be?

I have been always hard-pressed to buy the factory / manufacturing mode. I have worked on an assembly line. One of the jobs I had was building tires for Firestone Tire and Rubber Company at their plant in Memphis. That job was one of the reasons I made sure I went to University. Building tires is interesting from an engineering point of view. Tires are built shaped like a barrel with sheets of rubber and other components layered on each other, based on a specific design or recipe. In the end, the recipe metaphor might be the most appropriate as in the end they cooked and molded into the shape we know. Every specific type of tire follows the same set of steps. Any thoughts of creativity in the process are erased by the second tire you “make.” How can the metaphor of manufacturing model be used in software development, maintenance or enhancements where creativity and art are needed to deliver a solution?

One of my hobbies is craft brewing beer. Craft brewing starts with a recipe that specifies the amount of grains and hops to be used, approximate boiling times and a schedule for adding the hops as the process progresses to which is added elbow grease. As all brewers know, going from being a novice to something more, they begin to modify and tailor their recipes to meet their individual tastes. While operating within the basic recipe and laws of both chemistry and biology (brewing is cool), the brewer acts as a craftsman rather than a simple cook or assembly line worker.

I would suggest that a better analogy for software development is a scientific or engineering craftsman which mirrors my experience in craft brewing.

Words and names are important because they frame the questions that will be addressed. An engineering project begins with an idea, just like any other project. From the idea requirements are created and followed by the transformation of those requirements into something of value based on the physical laws and material tolerances. Projects following an engineering pattern include building a bridge or building a computer. The outcome of these types are predictable (assuming no major mistakes). When you build a house you generally pay a fixed price based on a fixed set of requirement. A builder is expected to answer, with high precision, the questions of how much the house will cost, when it will be completed, and when it will be delivered. When dealing with a craft or art, the answers to those questions are generally much fuzzier. While an artist might give you a fixed price for a portrait of your family the true cost, margin, and delivery date are far less predictable if for no other reason than the interplay between human, tools, and suppliers is more chaotic. Computers do not create great art . . .humans do.

So why does this discussion matter? Hasn’t this been debated many times over the years? Why does the model you leverage to describe IT matter? It matters because it sets expectations. If we use the manufacturing model why shouldn’t we expect to provide firm fixed prices? In manufacturing we should know when we can deliver the product. We should understand all the requirements from beginning of a project. In many cases the exception would be that we are delivering a product that we put on the shelf or that we assemble from known parts. This might be true if we were buying a vanilla commercial-off-the shelf product like Microsoft Office or SAP. If using an engineering metaphor, our processes will be based on the physical laws of nature and/or material science to describe how things are to be built. Examples include building a computer or standing up a set of servers. At its base, engineering is deterministic (x + y = z . . . every time). If developing or maintaining software were an art we would have very different expectations on whether we could predict the future (cost, quality, and delivery). A creative process that actually is far more chaotic and less deterministic.

Reality suggests that developing systems, enhancing systems, and maintaining systems are human dominated activities which are less than perfectly deterministic; therefore, they have at least some “craft” involved. I’m not suggesting that software development, enhancements or maintenance are art but rather a combination of science, engineering and craftsmanship.

 

The Beginner’s Mind

The Beginner’s Mind
By Thomas M Cagley Jr.

Audio Version:  SPaMCAST 177

Why is it easier for some organizations to innovate or to change more than others? Why do some organizations become less flexible after a new idea is successfully implemented? I believe that the concept of the beginner’s mind holds a substantial clue about why some people and organizations either embrace or resist change.

The beginner’s mind is a concept from Zen Buddhism known as Shoshin. The concept of the beginner’s mind refers to having an attitude of openness, eagerness, and lack of preconceptions when studying a subject.  The beginner’s mind can be present even when studying at an advanced level.  Quoting the Zen teacher Shunryu Suzuki, “In the beginner’s mind there are many possibilities, in the expert’s mind there are few.”  The beginner’s mind embodies the emotional qualities of enthusiasm, creativity and optimism.  These qualities are critical for tackling tough problems and for innovation.  The beginner’s mind is just one framework for understanding why some organizations and individuals seems to embrace the boundlessness of the environment around them but nevertheless it is a powerful tool for self-reflection or judging change readiness.

I would like to address the idea of change willingness through the filter of the beginner’s mind from two perspectives: The first is from the point of view of the constraints we accept or create for ourselves and our organizations; and the second would be to reflect on attributes that help us accelerate embracing change.

Constraints

Experts

• Many if not most people reading this essay either are or are on the way to becoming experts.    Expertise can be a double-edged sword. In order to become an expert, knowledge and hopefully wisdom must be accumulated which can allow an expert to see the depth and breadth of a specific topic providing the basis to solve many problems. The effort and sacrifice required to become an expert can at the same time create barriers leading to a lack of systems thinking and flexibility. Embracing the attributes of expert-dom (note that I did not say that you should eschew knowledge or wisdom rather the behavior of being an expert) has consequences much in the same way cholesterol hardens and clogs arteries. The investment of time and effort required to become an expert can generate a need to defend our comfort zone when challenged or when circumstances change. Another classic problem with experts is that it is easy to become a one-trick pony. For example I am sure we can all think of someone that has arrived at their level of expertise by using a specific technique (for example using Scrum, Kanban or classic project management techniques).  The default option is to try that one technique first without respect for changing circumstances. Taking the point of view of the beginner, it would be better to spend the time needed to review the problem even if they have seen it before.  Why? It is because they would not expect the circumstances to be the same before judging whether any specific technique or piece of knowledge is relevant.  I remember a mentor early in my career suggested that I practice the black art of expert-dom but not the behaviors that the moniker suggests inorder to avoid downsizing in the short run.  It was a good strategy however in the longer run constant re-invention has been more effective.

“Shoulds”

• Rules and “shoulds” are an integral part of modern corporate life.  Rules come in many flavors from policies (policies on sexual harassment for example), to software development lifecycles, to informal coding standards.  The problem with many “shoulds” is that they reflect other peoples ideas of how we should work and what is best based on their perception of the environment.  The beginner will question the rules and “shoulds” to separate what is necessary and desirable because they do not have the same preconceived notions.

End Vs Journey

• A few years ago I wrote an essay on my trek to Machu Pichu in Peru. The lost city of Machu Pichu was incredible; however much of the learning experience was derived not from the ruins themselves but from four-day hike through a myriad of climates.  It would have been easier to take the train instead of carrying a backpack through the Andes: however the sites and the self-knowledge derived from the journey would have been lost.  The same can be said for the problem-solving required to develop, maintain or enhance software.   Knowledge is built not only from the result (Machu Pichu) but from the journey (the hike).  PS – this is why we have retrospectives and post-mortems.

Fear of Failure

• As our lives become more complicated and / or we invest effort in developing a specialty, it is easy to take the safe, well-trodden path because we feel that failing represents a limitation that can’t be easily overcome or will effect more than just ourselves.  By pushing us to the safe path, the fear of failure reduces the possibility of bringing innovative solutions to bear on development problems and limits the experiences that lead to learning something new. Taking chances is critical to expanding knowledge.  My advice is to experiment, fail fast, fail often but not constantly and don’t fail twice doing something the same way.

Defensiveness

• There are many paths to defensiveness, many of which we have already explored.  One of the reasons defensiveness is bad is that when you become defensive communication becomes difficult.  As soon as you becomes defensive, barriers are erected which makes it difficult to listen, accept and process data that is at odds with your point of view. Frankly, being seen to be defensive will chase those away who have different points of view, which can only serve to reinforce the original point of view which creates barriers between ideas.  A self-reinforcing cycle that can’t have a good ultimate outcome.

“BEEN THERE DONETHAT”

• If I had a nickel for every time I heard the expression “been there, done that” I would be a rich man (or at least on the way).  A beginner does not make the mistake of assuming that since an idea has been tried in the past that it can’t or won’t work now.  As we have noted before, the world is a dynamic place and circumstances change and therefore when problem-solving all possibilities should be on the table.  Consider problem solving techniques that evaluate alternatives as quickly as possible; prototyping and experimentation (spikes and tracers in agile quarters) are tools to quickly evaluate solutions.

Preconceptions

• Constraints are an integral part of life, the universe and projects. Most of us have been educated to discover the constraints we are operating under and deal with them. The constraints we have been taught to find and therefore accept as real can blind us from possibilities in a manner similar to the filtered vision that expertise can bring to the table. The beginner does not begin with a set of preconceived constraints and “shoulds”. At the very least, a beginner will question preconceptions of the world around them.  Note: Not all preconceptions are bad.  For example the preconception that holding a meeting while driving in traffic is generally not good idea is probably not worth spending a lot of time questioning or testing. In the business world it is easy for processes to pick up additional steps that were added for a specific purpose or to ensure a specific incident does not happen again — which may no longer be applicable or that the solution is overkill.  If a step does not make sense just accepting that you “should” do it just because the process says so is generally not a great answer.  I am not suggesting that the beginner’s mind is a “get out of jail free card” for civil disobedience but rather that the status quo is generally not the most efficient solution and pushing to reinvigorate it through change is a better answer.

Accelerators

There many ways to enhance the beginner’s mind so that you unlock creativity and innovation.  A strategy is to take positions diametrically opposed to the constraints we just discussed.  For example, to embrace the beginner’s mind an expert could quit being defensive of new ideas while still capitalizing on the knowledge and wisdom gathered while becoming an expert.  Bottom-line, experts would need to resist developing barriers and being defensive when confronted by new ideas.  Other mechanisms to accelerate embracing the beginner’s mind include:

 

Openness

• The beginner’s mind sees the possibilities in every situation because it is open.  The goal of openness is to help ignore the constraints of what has been done in the past or just settling on the solutions our area of expertise makes us comfortable with.  I suggest investigating a new concept, taking a class on calligraphy (a nod to Steve Jobs) or just reading a book on topic outside of your comfort zone to help open your mind.  Openness is just as much a learned behavior as is the fear of failure or defensiveness.

 

Become a Learner

• One of the benefits of a beginner’s mind is that it is open to continuous learning.  Much has been written about the need for continuous learning and training in IT (in reality this true for any profession). There really should be no debate of whether it is the responsibility of the organization or the individual to continually enrich or reinvent themselves (the same can be said about organizations — just ask Kodak); you are in control of your own life and career. In order to actively enrich your horizons, you need to be actively learning at all times which requires an open and questioning mind. Time, success and expertise can contribute to hardening of filters which slow learning but only if you them. I am not suggesting you should be a failure, with no expertise and that you die young; rather, I am suggesting that you recognize that the filters we erect to focus our attention can lead to myopia which reduces the possibility of innovation and growth. While being a lifetime learner is not an immunization for career tragedy, it can reduce the risk and transition time if and when career shocks occur (it will also make you more fun to talk to at parties).

Boundaries

• It is easy to see boundaries all around us — boundaries between people, boundaries between teams, boundaries between processes, boundaries between applications and boundaries between organizations just to name a few. By definition boundaries are barriers.  It is easy to let experience and fear cause us to see a barrier as insurmountable and retreat into more comfortable territory. A beginner does not see boundaries as insurmountable obstacles but rather new territory and ideas to explore.

Positive Outlook

• Simply put a beginner looks for a way to succeed, rather than a reason an idea won’t work. My experience has been that it is far easier for someone to see how a change can’t work than it is to see how it can work.

The concept of the beginner’s mind provides a framework to consider why some people and organizations have an easier time embracing new ideas and why they innovate serially.  Each step away from the joy of change and experimentation towards constraints and deterministic solutions creates barriers between people, ideas and new solutions which generate a risk of systemic failure.   Become a beginner again.  Take a class on a topic you have always been interested in but haven’t done anything about.  Relish the experience of being excited about learning, not being the expert and asking the stupid questions as you explore the boundaries of the topic. The experience and feelings from this simple act can act as a template that you can translate into your day-to-day world to liberate the beginner’s mind and the potential for innovation and creativity lurking within.

 

Human Interaction During Testing on Two Continents

Human Interaction During Testing on Two Continents
Thomas M. Cagley Jr.

Audio Version on SPaMCAST 175 

Testing is the means of proving that the development process has understood and built what was required.  In its purist form it provides a set of proofs that validate the ‘whole’ development life cycle.  Regardless of the test model used there is one overriding goal; to deliver the best product possible within the constraints of time, budget and scope.  Meeting the goal of testing requires a strong level of interaction and communication between the testing and development teams.  This requirement becomes an imperative when testing occurs on two continents.

 

One day I woke up to a gorgeous sunrise then the phone rang and I inherited the testing component of a development project.  The project was well along, with development nearly complete with the external system and user testing looming.  Development and testing were to be done on two continents.  In a nutshell, the project was troubled (the usual cast of characters were at work; over budget, late, feuding sub-teams and subject to runaway requirements).  Reviewing how the testing had been distributed had to be reviewed to determine whether the most efficient use of the project’s limited remaining resources was occuring.  Of course this begged the question whether resources could be redistributed.  As soon as I heard the words; project, testing and soon, a mental assessment checklist popped to mind:

 

• Had test planning been performed and reviewed (and by whom)?
• Could the test cases actually prove the requirements?
• Had the developers been a party to the creation of these cases?
• Had user acceptance tests been defined when the stories were created?
• What were the criteria for acceptance (functionally, quality and date)?
• When was the last time that the test managers (and/or the project manager) actually talked, rather than emailed each other?
• What was driving the current project delivery date?
• Could I impact how the work had been distributed (sources and teams)?
• Was there a phone list of project participants?
• What time was it inIndia?

 

Testing is a human activity built on communication and interaction both with the project deliverables and the participants.  My first stop was the world clock at (www.timeanddate.com/worldclock) and then the phone list.  The test plan was my third stop.  If done correctly it would provide the basis to synchronize the test teams.  The test plan is a core management communications and negotiation tool.  The plan compiles and communicates the information about testing activities to provide a common way for all involved parties to understand and track test activity.  The plan lines up resources so that even a manager can know what will be done, when it will be done and who will do it.  The critical components of a test plan to drive multiple testing groups on two continents are:

 

• An overall statement defining the minimum level of testing that will be acceptable.
• Test ownership
• The application components and subcomponents with their relationships
• A test schedule (with effort, duration and resources)
• The test metrics
• The acceptance criteria
• The communication plans

 

Defining the minimum level of testing for the project creates a baseline, a tool to define what the quality goal of the project really is and then to resist cutting testing below a level that would meet the goal.

 

In any project it is important to determine the types of tests to be done.  Examples include regression testing, usability testing, system testing to name a few; however, when testing is done with more than one team it is imperative to determine who will be responsible for each test.  A single point of contact is (or at worst a single team) must be identified to lead and be responsible for a specific test.  Note, this does not mean that only one team can be involved just that someone needs to be in charge.  Determining ownership is best driven by its relationship to the development lifecycle, unit testing is best owned by the development team. Understanding the relationship between types of tests and the development lifecycle is an important piece of knowledge in the ownership decision process.  Oversight of the process should always be driven by the organization that sourced the project.  This is critical to making sure communication and information flow can be managed.

 

Components and the schedules are related items.  Knowing the components and subcomponents of the application being built or modified and their relationships provides the knowledge needed to create a road map to plan testing and for building a schedule for actually performing the test.

 

Metrics provide a means to monitor testing while in progress, rather than simply relying on verbal status.  Verbal status, while important, can easily be misinterpreted or represent progress that is out of date.  Metrics provide information and knowledge that cuts across any cultural boundaries.  The metrics should describe software functionality tested, degree of code coverage and progress against a schedule which are core management issues.  Publishing test metrics provides a language to synchronize not only the test teams but the project team, as a whole regardless of organization or culture.

 

Acceptance criteria serves two purposes.  First, acceptance criteria define when a project is complete.  Second, if created and documented early in a project (before coding to take a page from the agile methodologies) they serve as a communication tool for validating requirements.  The definition of acceptance criteria must be led by the organization owning the project and ‘users’, all parties should participate but ownership stays at home.  Acceptance criteria provide a language of acceptance that cuts across communication barriers.

 

Providing a plan for the compilation and communication of complete information about the plans, progress and problems for testing allows both continents to provide support and anticipate changes in their own schedule. Interaction, communication and knowledge are important components to making testing happen and becomes even more important when more than one team is involved or when testing done on two continents.  With adequate information, testers are better able to plan and perform their tasks more efficiently and to get an accurate picture of the system. Did I mention communication was important and that it must happen over the entire project life cycle?

 

Testing is frequently unpredictable, and unpredictability, the bane of managers, creates painful schedule surprises and Maalox moments. This is especially true when multiple teams in multiple locations with multiple cultures are involved.  Communication and coordination based on planning that combines all of the different perspectives of testing and system development  (schedules, functionality, code and problem resolution) makes it is possible to understand and manage software testing.  Defining how to source testing is important to all outsourced projects, the test plan or test architecture is a decision making tool and a tool to synchronize activities between sources.  Communication based on a plan lets you manage the testing process on one continent or two rather than to allowing  it to manage you.

 

Software Process and Measurement Cast: Five Years Old and Growing

Audio Version:  SPaMCAST 171

When the Software Process and Measurement Cast began five years ago it was the culmination of an idea that had begun percolating for many years. It did not spring into existence fully formed. The cast began as a bi-weekly show combining both an essay and an interview. We have evolved to a weekly cast. The metrics minutes essays have come a regular feature. 

 The cast has been a path to give something back to the industry that has been so good to me while at the same time do something that would satiate my need to continually learn while being exposed to new ideas. The audience for the first show (and more than a few after that) could be counted on on one hand or on some multiple of hands and feet. After a few breaks and a lot hard work the audience, measured in downloads, has reached 10k per month.  I am happy to say that we are still growing. There are so many people to thank for the shows success that it is a deeply humbling experience.  Interviewees, sponsors, great contributors and my family have made all of this possible. 

 Does this sound a bit like a swan song?  Not on your life.  Where do we (we because I am including you) go from here? While I am happy with the general format I think the intro and outros need to be freshened up.  Another change I would like to affect is to engage more of you to provide content to build the essay segment into more of a journal or magazine. If you have a review or essay and want to be an internet star, I have the platform for you! If you have a submission let me know, I will be happy to review it and help produce it.  Note all submission will be reviewed to make sure they fit the show’s  format and level of quality. If you don’t want to record your review or essay, I can have it narrated.  A recent example of audience content can be found on SPaMCAST 169 where Elizabeth Harrin wrote a great book review and Barb Cagley provided the narration.

 Other plans and goals for 2012 include growing the audience by 50%, a new website that consolidates the podcast and blog, re-institution the SPaMCAST newsletter and adding at least one video cast (Pat Ferdinandi has rubbed off on me). Want to help or have ideas on how to grow the audience? Contact me and we can discuss how we can make something happen. Anyone that helps will get exposure to the whole SPaMCAST audience.

 Finally, I am actively searching for additional sponsors like LeanKit Kanban. Chris Hefley and the crew at LeanKit have been and continue to be great sponsors.  Sponsors help with upgrading equipment, offsetting the hosting and other costs. 

 Year Six will be a great time for all of us. I hope the cast will continual to be useful, informative and exciting!  Thank all of you for making this possible!

 

 

Software Process and Measurement Cast Five Year Anniversary Press Release

Year Five Press Release (PDF)

For Immediate Release
January 23, 2012

Avon Lake, OH – The Software Process and Measurement Podcast (SPaMCAST) is celebrating its 170^th episode after five years of interviewing many of the leaders in the software development world. The anniversary edition of SPaMCAST features an interview with Hillel Glazer, speaker, process guru and author of High Performance Operations.

SPaMCAST feature interviews have included:

• Chris Hefley, Chief Executive Officer, Leankit Kanban, Bandit Software, LLC
• Dean Leffingwell author of Scaling Software Agility and others
• Peter Taylor  author of many books including The Lazy Project Manager
• Elizabeth Harrin author, award winning blog, The Girl’s Guide to Project Management
• Tim Lister, co-author of  Adrenaline Junkies and Template Zombies
• David Anderson the author of  Agile Management for Software Engineering
• Kent Beck, pioneer in Agile Methods
• Scott Ambler, though leader in Test Driven Development
• Ivar Jacobson, developer of Use Cases
• Grady Booch, discussing Life, the Universe and Development

The Cast covers topics that deal with the challenges of how work is done in information technology organizations as they grow and evolve.  The show combines commentaries, interviews and feedback to serve up ideas, opinions, advice and facts.  In a nutshell, the Cast has provided and will continue to provide advice for and from practitioners, methodologists, pundits and consultants. The editor, Tom Cagley, is a leading consultant in software development process improvement, the Vice President of Consulting for the David Consulting Group, Past President of the International Function Point Users Group and co-author of Mastering Software Project Management.

The Software Process and Measurement Cast can be found at www.spamcast.net. It is also available on all major podcast services including iTunes and the Zune Marketplace. All previous episodes are available download.  The Cast currently enjoys 10,000 downloads a month, up 20% in the past year It is delivered as a free public service to the information technology community and has listeners across the globe.

Contact:
Thomas M. Cagley Jr.
Editor

Email: Spamcastinfo@gmail.com
Mobile: 440.668.5717
Skype ID: Thomas,Cagley.Jr

 

Serial Mono-tasking In Action
Part Two of The Case Against Multitaking.
By Thomas M. Cagley Jr.

Audio Version of Part One
Audio Version of Part Two

Recap of Part One: True multitasking in the work place is rare at best.  Even when we think of fast-switching as a form of multitasking, multitasking lacks efficiency due to switching costs. If you decide to accept the cost of multitasking, the act of multitasking is — complicated. Complexity causes errors and makes more work which reduces effectiveness even more.

Serial mono-tasking with planning is a mechanism that can help minimize switching costs and complexity.  As noted in Part One of the essay, mono-tasking makes the most sense if efficiency and productivity are your goals. How we implement mono-tasking in the face of an interrupt-driven world is an open question.

Serial Mono-tasking In Action

I would suggest that any approach to dealing with tasks whether for a program, project or a personal to-do list must be based on a process that includes specific coping mechanisms.

Prioritization:   As noted in “The Case Against Multitasking”, having a few tasks queued up reduces switching time. Switching time is the time required for the person doing work to prepare to do the next task based on a new set of rules. As an example of these different rules, consider the rules and constraints you have in mind when writing an email to your significant other; now consider the constraints and rules you would have to keep in mind if writing an email to your boss (unless they are the same). Another example of a task with different rules would be coding a user-facing website as compared to loading a data warehouse table. Prioritizing tasks can serve three purposes:  The first is to minimize the differences between rule sets when switching (I will do all of my work email before updating Facebook) which will reduce the impact of switching. Secondly, prioritization at the team level provides the ability for the team to group (self-organization) the work so as to reduce rules and constraint differences between tasks. Thirdly, prioritization lets team members mentally prepare before the switch (another coping mechanism). Bottom line, prioritization is about tackling what is important first.

Isolation: Team environments tend to be noisy and interrupt-driven because IT personnel are nothing if not individualistic. Each person will have their own coping mechanisms. Find your own mechanism to block distractions; wear headphones, learn to focus, turn off IM for periods of time or consider working from home if possible. In other words, adapt to the environment without withdrawing or rejecting those around you. Remember that as noted in the first part of the essay, background noise does not have a substantive scientific basis so blasting “En da Godadiva” might not be a great idea.

Focus:  Filtering or blocking things out and focus are related but they are also different. Focus is about narrowing your consciousness to contemplate a specific topic. To aid in developing focus, avoid distractions; turn off IM, don’t check emails and in radical cases hide from team members (just for a little while).

Adjust:  When things don’t work out as you plan (and how many plans work perfectly?) make changes. Adjust both the process you are using and the environment to maximize your effectiveness (note, I did not say efficiency or productivity). Any process with human involvement is naturally chaotic requiring adjustments. One of the observations I have heard from studies of the Toyota Production System is that if a process is not being changed and adapted then it is not being used properly.

Process:  A system or a process is required to control the flow of work.  It would be difficult to prioritize and focus on a set of tasks and therefore to be productive if there was no control on how a task could enter or be accepted to be worked on.  Processes like Kanban, SCRUM and even the venerable waterfall methods all include mechanisms to control the flow of work and to decide on which items should be addressed and when.

A side note in the discussion of process, is that fully committing all resources on specific tasks in a project leaves no time for probems therefore is tantamount to enforcing overtime or to falling behind schedule. All processes must allow time for both the interruptions a corporate environment always has and the overhead of the workday (email, time accounting, non-project meetings, coffee, bathroom breaks . . .to name a few). One method suggested by many time management gurus is compartmentalization.  For example, blocking a period of time for heads down working followed by a window of time to read and return emails or phone messages.  The goal is to have a process that allows you to work as simply as possible. This means the process needs the ability to capture to-dos, categorize, prioritize and then track work to completion (which is exactly what backlog is for an agile project or a work queue in Kanban).

 

At a personal level have a process, prioritize your work, filter out distractions and focus on what is important.  Learn to postpone interruptions rather than switching. When interruptions can’t be avoided, shut down rather than just stopping what you doing to react.  Shutting down will minimize retooling when you restart. When the urge strikes to check email or jump back into Twitter, just say no, take a deep breath and try to refocus. At a personal level I am a fan of David Allen’s Getting Things Done (GTD) and personal Kanban.

When working on projects, the multitasking problem can be addressed by adopting techniques that support serial mono-tasking with planning at a tactical level. Agile and Lean techniques are tailor-made for addressing this issue. Agile and Lean techniques have recognized the power of doing one thing at a time. Scrum and Kanban both feature isolation of tasks so that they are selected and disposed of in a serial manner.

Serial mono-tasking requires discipline to have a process and for you or your team to focus.  It does not mean slowing down, but it does mean making choices.  In many cases, rushing off to deal with interruptions gives the impression of importance but in the long run it probably makes your project late or reduces the quality of the product you deliver.

 

The Case Against Multitasking

Audio Version:  SPaMCAST 167

To multitask or not to multitask, that is the question.  Whether ’tis nobler in the mind to suffer the slings and arrows of mono-tasking or to take arms against a sea of trouble and by opposing do more…at least appear to do more.  Is the discussion of mono-tasking versus multitasking a tempest in a teapot, a true productivity killer or perhaps are we really discussing how we segment work?  Depending on how you define the word, I believe it is the later.  The problem is that like so many other words we have conflated a number of concepts into a broader idea.

In my opinion, there are three common scenarios that get conflated into the term multitasking:

1. Actively doing two or more things at once (breathing and talking).
2. Actively doing one thing while passively doing another (writing this essay while listening to the radio).
3. Switching between tasks related, unrelated or loosely coupled (rotating between reading a book and updating Facebook).

The formal definition from the Merriam Webster dictionary defines multitasking[1] as “the performance of multiple tasks at one time.”  This fits scenario one and two (to a less extent) but definitely not three.

In the work place, true multitasking is rare.  It is not that we humans can’t multitask because we can multitask even using the strictest application of the definition of the word.   We are good at multitasking when it is a combination that includes an autonomic task (like breathing, heart beating or sweating) and something more active such as chewing gum or when it includes accidents such as the combination of talking on a cell phone while driving and running into the back of my car. The data shows that generally humans are not really very good at true multitasking in the workplace. Linda Stone noted in the Huffington Post[2] that people tend to stop breathing while they answer email. She even named the malady, email apnea. If you need more examples just reflect on the data concerning cell phone usage and driving or if data doesn’t work for you then try rubbing your stomach and patting your head at the same time. Computers, on the other hand, are really good at multitasking and no matter the number of processors we have on our desktop we have not crossed that chasm to become full cyborgs yet.

The second scenario termed multitasking is a bit of a nuance: actively performing a task while passively performing another.  A classic example of this form of multitasking is reading a book while the radio is playing in the background.  In many cases this form of multitasking is an attempt to manipulate the work environment to aid focus.  The question of whether background noise affects concentration has been often studied.  In the January 2010 edition of the Scientific American, the magazine noted that background or low-level noise often disrupts people’s concentration[3]. Whether background noise helps or hurts concentration is probably one of brain wiring.   During the Christmas holiday I observed my son-in-law who can concentrate for hours but zones everything else out and my youngest daughter who requires multiple simultaneous inputs to get into flow state.  One for background noise and one against, maybe everyone is different.  At any rate, the data suggests that even on as basic a level as the having the radio on while reading, multitasking generally does not improve focus and efficiency.  By the way, if you are one of those that require background noise to concentrate, I recommend good headphones.

 

The final scenario generally conflated with multitasking is switching between multiple tasks.  This scenario is also known as fast-switching or serial mono-tasking.  Switching is in reality the juggling of resources to accomplish a set of tasks; at a macro-level you might be multitasking; however, on a micro-level you are mono-tasking.  The issue with this type of behavior is that juggling is not always easy even if you are good at it.  Inefficiencies are caused by both the queuing/scheduling of tasks and then the retooling that occurs when switching between tasks. During my research for this essay I found that in the brain, juggling multiple tasks is performed by mental executive processes that manage the individual tasks and determine how, when, and with what priorities they get performed[4]. The executive process coordinates activities so that the right outcomes occur, an analogy for what is going on inside of our minds is the air traffic control system.  The air traffic control system makes sure planes get where they are going with a minimum of delay and without two planes trying to use the same spot in the sky at the same time (bad). The coordination of tasks requires a level of overhead, just think about coordinating schedules for shared project resources if you need proof that overhead is required. However, more significant inefficiencies occur when a person switches between tasks.  Task switching experiments have shown a need for the person switching tasks to take time and mental resources to reorient. The reorientation tax (the amount of effort you need to expend to switch tasks) goes up with task complexity, lack of familiarity of the next task and the relative differences between the tasks.  Research has shown that task queuing (lining tasks up in order of precedence) so that the person doing the work can know what is coming and /or can influence the order they are to be done, can be used to reduce the impact of switching[5].  Reduction in the impact of switching can be mediated by separable executive control processes that prepare systemically for transitions between successive tasks[6].  The issue with the fast switching brand of multitasking is that in many cases the queuing of tasks is not as seamless as it should be which creates wait-states or multiple re-tooling situations because work does not flow as cleanly as it is diagramed on the Microsoft Project schedule (this is one of the reasons Reinertsen indicates that full allocation reduces efficiency).  Please note I am not comparing this type of multitasking to taking breaks between tasks to clear the “buffers” which has been shown to be valuable.

The data suggests that a mono-tasking environment that reduces interruptions is the most efficient work scenario[7]; however, the work environment is rich in interruptions.  Further according to Capers Jones, the information technology field has more named specialties than any other profession which means that individuals are spread across more project teams so they can practice their specialty.  Switching between projects leads to the switching tax we mentioned earlier.  Switching between tasks and projects is firmly etched into the classic project management body of knowledge based on 19^th century manufacturing thinking (it’s now the 21^st century).  We have even gone as far as to building the scheduling of shared resources into our project management tools which suggests that getting rid of the problem will not happen in the near future.  Today’s working environment leaves us with few options as methodologists.  Our goal must be to avoid switching when possible, minimize the impact when we can’t and then to decide to live with what we can’t change.

 

Next . . . A plan to address at least part of the problem

 

 

---

[1] http://www.merriam-webster.com/dictionary/multitasking, December 31, 2011

 

[2] http://www.huffingtonpost.com/linda-stone/just-breathe-building-the_b_85651.html , January 1, 2012

[3] http://www.scientificamerican.com/article.cfm?id=ask-the-brains-background-noise, January 1, 2011

[4] Choices, Choices: Limits of the Brain, Anthrostrategist  Blog, August 28, 2011 (referenced December 17, 2011)

[5] Rubinstein, J. S., Meyer, D. E., & Evans, J. E. (2001). Executive Control of Cognitive Processes in Task Switching. Journal of Experimental Psychology: Human Perception and Performance, 27(4),763-797.

 

[6] Rubinstein, J. S., Meyer, D. E., & Evans, J. E. (2001). Executive Control of Cognitive Processes in Task Switching. Journal of Experimental Psychology: Human Perception and Performance, 27(4),763-797.

 

[7] Multitasking and Monotasking: The Effects of Mental Workload on Deferred Task Interruptions, Dario D. Salvucci and Peter Bogunovich, PDF, https://www.cs.drexel.edu/~salvucci/publications/Salvucci-CHI10.pdf, December 12, 2011, p1