Friday, September 27, 2013

The Macro Expansion Heuristic – A Real World Example

I enjoy learning new things, and I especially enjoy making connections between things I've learned or read about, and applying them to real-world situations. I had the opportunity to do that today while I was brainstorming with a colleague for a presentation on model-based testing and its application in intelligent automation. We were talking about the benefits that model-based testing provided when my colleague said something that caught my attention: we are modeling requirements.

I tend to be overly careful in conversations about model-based testing because my experience comes from modeling the states of use of an application and not the approach we’re taking with model-based automation, and I don’t want to use the incorrect context. So I stopped and thought about it for a few seconds before telling my colleague that I wasn't comfortable with that statement. Something about it didn't sit right with me, and I suspected it was that the statement either did not correctly say what was meant or did not mean what was said.

We talked it through and mapped it out in our mind map, but were still unable to agree that the statement was correct, but by now I believe that my colleague was also unsure as to whether or not he had said what he meant or meant what he said. It then occurred to me that I had seen a similar problem before, and that problem had been presented along with a heuristic that we could apply to solve the problem – the concept of a macro expansion, which I had first seen applied to communication by Michael Bolton in his blog post “What Do You Mean By ‘Arguing Over Semantics’?

When we generalize on the concept of a macro expansion we can utilize it to take a single word and expand it into a series of words that more accurately express what we mean. I asked my colleague if we could do a small exercise on the white board to sort this out, and he agreed. Taking one of the markers present I wrote on the board:

“We’re modeling the requirement.”

As I was writing I told my colleague that if we were to expand that statement, we would get something that better said what was meant. So, under that I wrote:

“We’re modeling that the requirement was correctly implemented.”

After further discussion we agreed this could be shortened without a loss of clarity, so I wrote:

“We’re modeling correct implementation.”

We were both comfortable with that statement, and felt that it truly expressed what we were attempting to say. 

Having the feeling that we were on to something, we took this one step further. If we’re modeling correct implementation then any discrepancy between the actual implementation and what we have modeled means that there is a problem. That means that the models we are creating are mechanisms by which we recognize a problem. That sounds rather familiar....


Thursday, September 12, 2013

Takeaways from Our First Lean Coffee

I've noticed over the past several months that the team’s Monday morning weekly kick-off meeting was becoming more and more ineffectual. It originally began with the idea of getting team members interested and involved in the projects and tasks their team mates were working on, allowing the opportunity to meet, provide input and insight, and take a break from their own projects. What it degenerated into was a high-level review of Friday’s weekly report. It wasn't quite as bad as some of those daily stand-ups I've attended where team members point at the board and mumble “Yesterday I worked on that. Today I will work on this. No obstacles.” However, it was certainly getting close. We would occasionally find the rare nugget of information that wasn't reported on Friday, but it was certainly failing to meet its initial charter. It had been my idea, and I had the responsibility to either make it work or cancel it.

I had spoken with the team a few weeks ago, asking if they wanted to cancel the meeting, citing a lack of ROI and better use of their time, yet each one voted to keep it going. I gave it a little more time, noticing that they still really weren't that into it. I kept going back to the juxtaposition of the vote to continue holding the meeting and the apparent lack of engagement and effective communication in the meeting. That, to me, signaled that the team really wanted to communicate, but the outlet provided by the meeting wasn't the proper outlet for that. But what was? What was lacking in this meeting?

I tried to think of other, more productive uses of everyone’s time. I toyed with the idea of making the Monday morning rounds to their desks to talk about their projects, taking up only as much of their individual time as needed. That sounded like a pretty good use of everyone’s time, and would allow me to get the information I was after, but it didn't allow them to interact or perceive new ideas. I kept trying to think of other ways to get engagement from the team, but was unable to identify any viable solutions. Until CAST2013.

I was watching the twitter feed during CAST2013, and started seeing tweet after tweet about the Lean Coffee. Lean Coffee? Really? I didn't recall ever having heard about Lean Coffee before, so I did a little research and quickly became intrigued. Lean coffee sounded simple. It sounded relevant. I asked peers if they had any experience with holding a Lean Coffee, and received some very favorable responses.

Last week was the last time we held our status meeting. I canceled the meeting in Outlook and scheduled the Lean Coffee for the same time slot and place, providing a link to leancoffe.org and a YouTube video that talked about the mechanics while showing a Lean Coffee in progress. I was expecting a slow start with a smattering of topics provided as the team figured out how everything worked without an agenda, what we were going to talk about, even what we could talk about.

This week, we started our Lean Coffee. This week, the results were truly outstanding. The team was engaged, they provided excellent topics, they discussed each topic excitedly (often voting to continue the discussion), and they voluntarily extended the meeting an additional thirty minutes to address additional topics. When we finally concluded the meeting, we had resolved several topics, identified three longer-term action items to be addressed outside of the Lean Coffee, modified the board to better address the longer-term action items, and everyone left that meeting still talking excitedly, including me.

I knew that the Lean Coffee had hit on something, but I was unsure about what, exactly, that was. Later, after I had time to pause and reflect on our first Lean Coffee, I realized that there were several factors that made our move to Lean Coffee a success.

Although I had made the connection between the vote to continue the Monday meeting and the continued ineffectiveness of the meeting to address its charter, I had not understood what the relationship was. Ultimately, the meeting was not valuable to the team because it did not address their needs and concerns; most meetings do not address the needs of the attendees, they address the needs of the meeting organizer. So, there we were, every Monday, using up valuable time, including a portion of the limited face-time they have with me, their manager, and I was not addressing their needs and concerns, I was addressing mine and what I thought theirs were. So, the team’s perception has been that the meeting was neither relevant nor timely to them.

A second takeaway was that the best way to get the team engaged in a meeting is to have them help generate the meeting’s agenda. The team was eager to discuss new concepts and thoughts on improving our test efforts when they were provided in context of their concerns and the issues they were currently facing because they were both pertinent and timely. Helping to create the meetings agenda also gives the team a sense of ownership in the meeting and therefore responsible for the success of the meeting. It also demonstrates that management not only values their involvement and their contributions to improving our testing efforts, but is actively pursuing their input. That, to me, is truly vital. Even a good self-organizing team doesn't want to be self-organizing in isolation. They welcome and seek out management’s involvement throughout the organizational process.


These insights were just from our first Lean Coffee, and I’m very excited to see what happens next. I've already seen one team lead propose changing the team’s weekly meeting to a Lean Coffee, and another has proposed using a Lean Coffee format to present a portion of our seven year strategic plan to our management team. That’s what I call engagement!

Sunday, September 8, 2013

Doing the Math for Assessing Communication: The Bijective Oracle

I've seen some conversations and blog posts recently about whether or not we should be arguing over semantics. Some I read and follow, some I don’t, but someone recently directed the people involved in one of these threads to a blog post by Michael Bolton. The post is entitled “What Do You Mean By “Arguing Over Semantics”?, “ and I think it provides one of the best discussions I've seen on this subject. The thing that caught my attention was when Michael finishes the post by saying:
“There’s a common thread that runs through these stories: they’re about what we say, about what we mean, and about whether we say what we mean and mean what we say. That’s semantics: the relationships between words and meaning. Those relationships are central to testing work. 
If you feel yourself tempted to object to something by saying “We’re arguing about semantics,” try a macro expansion: “We’re arguing about what we mean by the words we’re choosing,” which can then be shortened to “We’re arguing about what we mean.” If we can’t settle on the premises of a conversation, we’re going to have an awfully hard time agreeing on conclusions.”
That really struck a chord with me because it highlights what I see as one of the larger obstacles to effective language-based communication: the one-to-many relationship that exists between a word (the one) and the meanings (the many) generally associated with that word. This is easily extended beyond single words to include groups of words structured to form larger constructs such as clauses, phrases, sentences, paragraphs, etc., in which case we now have a many-to-many relationship between words/constructs and meanings. There can be many disconnects between what we say and what we mean, and we often don’t know whether we actually say what we mean and mean what we say. Moreover, if we’re not sure, how can the people we’re trying to communicate with be sure?

One oracle I try to apply when it comes to assessing the effectiveness of language-based communication is the mathematical relation of the bijective function, which is a relationship that is both injective and surjective. Yeah, I’m a math geek, but bear with me while I describe this oracle.

In mathematics, a function is simply a relationship between a set of inputs called the domain, and a set of outputs, called the range or co-domain, in which every member of the domain is mapped to exactly one member of the co-domain. If we apply this to the relationships between words and meanings by mapping each word/construct to exactly one meaning within the context of our current communications, namely the meaning we are trying to convey, then we have made some progress in alleviating the issues that arise from the many-to-many mapping between words (the set of inputs) and meanings (the set of outputs), restricting the mapping and thereby reducing it a to a many-to-one mapping. But at this point we still don’t know if we are saying what we mean and mean what we say; we just know what we mean and it has many ways to be said. Effective communication needs to use the same words to convey the same meanings.

The problem is that we haven’t addressed the fact that different words/constructs can be used to convey the same meaning. To do this we need to apply the oracle and determine if every meaning is mapped to at most one word/construct. In the language of mathematics, we would say that our relationship would then need to be injective, or one-to-one, so that not only is every input mapped to one output, but also that every output is mapped to a distinct input; no two inputs produce the same output. So now, if we use our oracle to assess our communication, we should be able to better see if we have established a one-to-one mapping between what we say and what we mean. If not, then there is a possibility that we are not saying what we mean and meaning what we say.

For our communication to be truly effective, we need to make sure that every meaning has been mapped to a word/construct in our conversation. Have we left anything unsaid? Have we used words/constructs to explicitly cover all meanings we wanted to cover? Every meaning we want to convey needs to have a relationship to a word/construct we have used in our communication. This means that our relationship needs to be not only injective, but that it also needs to be surjective, so that every element in our output set is mapped to a corresponding element in our input set. If we do this, then we've worked to ensure that our communication is complete.


So, using our bijective oracle, we can look for potential problems in our communication. Is our communication injective? Have we reduced the many-to-many relationship between words and meaning down to a one-to-one relationship? Is our communication surjective? Have we said everything we need to say? If so, then there’s a pretty good chance that we are saying what we mean and mean what we say.