Checking Alignment, Redux

I’ve been writing a lot lately. Writing for long stretches leaves me mentally drained, nearly useless. The words dry up. I stop making sense. I find it increasingly difficult to form coherent sentences that concisely convey my meaning. Eventually I can’t even talk intelligibly.

I recall attending a party after a week of solid writing a few years ago.

“How are you?” my host asked when I arrived.

“Unh.” I muttered. “Good.”

“What have you been up to?” she inquired.

“Um. Writing.” I stopped talking and stared back at her expectantly.

I wanted to be social, but no more words would come. I stood there just staring at her. It didn’t even occur to me to ask how she was doing or what she was up to.

My host looked at me sideways, unsure how to respond to my blank stare. It wasn’t a Halloween party, and yet I was doing a passable impression of a zombie. How does one respond to zombified guests?

Anyway, my point is that I’m in one of those states now. And thus I may have great difficulty making myself understood. Producing words that fit together to express ideas is becoming increasingly difficult.

I’m guessing this is why I failed to explain myself well in my last post. Or at least I am inferring from the response to that last post that there is a gap between what I intended to say and what most people understood me to be saying.

I had three points that I wanted to make in my last post:

  1. It’s easy to speculate about the connection between actual needs, intentions, and implementation.
  2. Empirical evidence trumps speculation. Every single time.
  3. Testers are NOT the only people who gather that empirical evidence.

Given that’s what I meant to say, I certainly didn’t expect UTest, a testing services company, to like the post so much that they would tweet:

We couldn’t agree more! It’s all about the testing!

Yes, it is all about the testing. But—and this is a crucial BUT—it is not all about the testers.

In fact, much of the kind of testing that goes into ensuring alignment between intentions/implementation and actual need is something that testers have very little to do with, and it’s something that cannot ever be outsourced to a testing services company.

Let’s look at the sides of the triangle of alignment again:

Actual Need: the value our users and/or customers want.

Intentions: the solution we intend to deliver in order to serve the Actual Need. The product owner, product manager, business analyst, or designer is the one who typically sets the intentions. It’s their job to listen to the cacophony of conflicting requests and demands and suggestions in order to distill a clear product vision. For now let’s just call this person the product owner. They own the product vision and decide what gets built.

Implementation: the solution the team actually delivers.

So who makes sure that the intentions and implementation match the actual needs?

The best person to do this is usually the person who set the intentions in the first place: the product owner. They’re supposed to be steering the project.

If the product owner has no way of verifying that they asked for the right thing and can’t tell whether or not the resulting software delivers the expected value, the project is doomed.

Seriously, I’ve lived through this as a team member and also seen it from the sidelines. The person responsible for setting the intentions needs a way to tell whether the actual needs are being met. They need feedback on the extent to which the intentions they set for the team pointed us in the right direction. Otherwise we end up in a painful cycle of requirements churn that can ultimately end in organizational implosion if we hit the end of the runway before we deliver real value.

Michael Bolton’s story of getting out of the building and picking up sample checks on his lunch hour is fabulous. But to me, it’s not a story about testing. Rather it’s a great story about how having multiple examples are key to truly understanding requirements.

Further, I’ll suggest that in this story Michael was acting as a Team Member rather than a Tester. The fact that Michael is a world class tester is not the most salient part of the story. The important thing is that he noticed the team needed something and he went out of his way to get it.

It is important not to confuse Michael’s initiative as a team member with an exclusive job responsibility of testers. Michael took the initiative. That’s one of the reasons why he is a world class tester. But picking up that sample check is something that a programmer could have done. Or the product owner. Everyone on a project can contribute to establishing a shared understanding of the full scope of the requirements. And everyone has a hand in gathering empirical evidence, not just testers.

Testers happen to be really good at gathering information. Teams need testers. But teams also need the testing mindset to be baked into the culture. Team members need to ask these key questions before taking action:

  • How will I know my efforts had the effect I intended?
  • How will I know my intentions were correct?
  • How will I know my results are delivering real value?

These questions are at the core of the test-first mindset. And the answer to these questions is never, “I’ll just ask the testers.”


Subscribe to our e-mail newsletter to receive updates.

4 Responses to Checking Alignment, Redux

  1. Scott Barber October 31, 2011 at 12:09 am #

    I like to think about the intersection of what you are referring to as “Actual Need”, “Intentions”, and “Implementation” as “Fitness for Purpose”.

    Like you, I’m sure, I’ve seen many, many, models for creating and delivering technology solutions (including, but not limited to software). One thing that I’ve been confused by since my very first contact with an organization that created and delivered technology to help others conduct their business, is why (IME) there seems to *almost* always be a complete disregard by the implementers for the actual needs of the people/organizations the technology solution is being created to serve (as opposed to the presumed needs, or the articulated desires). This disconnect (again, IME) seems to be greatest when the technology solution is entirely, or mostly software.

    The reason this disconnect (and apparent disregard) confused me is because the overwhelming majority of times I’ve encountered this, the team included people called Business Analysts, Project Managers, and Product Managers. In the places where I got my education and started my career, those are the roles charged with ensuring that what is being created will strike an acceptable balance among:

    – Appropriate value to the org having the need the solution is being created to fill
    – At an appropriate cost to the org for that value
    – Appropriate cost to the solution developing organization developing (i.e. schedule, personnel and $)
    – Other risks to the solution developing organization

    In other words, let’s say my company determined there was a market need for a special shovel to help foremen ensure their workers comply with a new union regulation specifying that when shoveling, a worker must take a 10 minute break after every 1000 lbs of material shoveled — So the need is for a shovel that tallies the weight of material since shoveled since the worker’s last break, and sounds an alarm when that worker is due for their next break.

    I send a sales guy from my company to do some market research — which he does by calling the union and the union named “representative foreman” who both agree there is a need for such a shovel. So there we have “Actual Need” in terms of a product.

    So I pick an available product manager and tell her to get started & promptly forget about the project. About 6 months later, I drive past some construction on my way to work & remember the shovel project. I call in the product manager for a status update. She tells me:

    – We’ve spent about $10M in R&D
    – We almost have a prototype done
    – We’re having a little trouble with the personal identification protection, but we’ll get it worked out
    – We expect to be ready to ship in another 6 months
    – The shovels should list for about $27,000 each

    Does anyone else see a problem here? Today, the workers are using what they consider to be *very* expensive $50 shovels. Those shovels break, get left out in the weather, etc. The “weight limit between breaks” is being “enforced” by estimates & no one is complaining — workers, union, or property owners. Today, equipment is assigned to workers by painting a unique colored stripe on their helmet & their equipment, so that who is using whose equipment is an already solved issue (and was not identified as part of the actual need).

    So what happened here? Someone didn’t keep the product being developed in line with the actual need. Was that a tester’s job? Only to the degree that they were given the correct information to work with and explicitly assigned that mission. Was it the BA’s job to get the requirements or stories right? To some degree, but again, only to the degree that was assigned and explained to them — and even then, someone else need to be reviewing what they came up with, since it is most certainly not their job to find the balance between need, cost, risk, etc.

    What happened is a complete and total failure of the product manager.

    Interestingly, when situations like this happen in companies that develop physical products, I’ve observed those product managers get fired. When situations like this happen w/ software products, the software simply gets deployed to production, it loses money, or fails in some other major way, the product manager shrugs, blames someone else, takes their bonus for shipping on time, and moves on to the next project.

    Ok, so maybe I’m stringing together an example representing a blending of several issues I’ve seen to make a point, but I think it makes the point, yes?

  2. Claire Moss November 5, 2011 at 2:12 am #

    Early user testing (especially testing focused on user experience) seems to be a good reality check option for software. I certainly feel better knowing that we’re heading in the right direction based on feedback from actual users. While that may not be an option for everyone, I think more people could take advantage of it.

  3. Don Dornblaser November 22, 2011 at 1:24 am #

    Hi Elisabeth,

    Thanks for another great post. The part that really stuck with me is where you say that people tend to focus on testing the implementation against the intentions rather than the actual need. It’s so true. We’ve been moving steadily towards using personas and their problems as precursors to user stories, and conducting client and prosepct inverviews to verify that they these problems are pervasive and that clients are willing to pay to have them solved. I think usability testing every few weeks also really helps to reset our focus back on the acutal need rather than on our intentions. Keep in touch!

    — Don

  4. Istvan Verhas December 1, 2011 at 2:19 pm #

    Actually the customer does not know exactly the ‘Actual need’. She/He has only also intentions. So the triangle three sides are ‘Customer intentions’, ‘Product owner intentions’ and ‘Implementation’. The ‘Actual need’ is outside of the triangle and can only be checked by the empirical evidence of the customer.

Leave a Reply