Uncharted Waters

Aug 9 2018   9:52AM GMT

Name It Claim It

Matt Heusser Matt Heusser Profile: Matt Heusser


High Powered Executives Name it, Claim ItI’m sitting in the office of a high-powered executive, and they tell me how the entire technical staff is “bought in to Agile” and uses BDD to enable continuous delivery.

Then I go talk to the people.

It turns out that builds are performed by the “build master” checks the code out of version control, going into Visual Studio, loading the project, pressing Ctrl+Shift+B, getting an executable, and copying it over to production. There are several different projects and some teams can deploy a few times a week.

As for BDD, some of the lead testers create “given when then” acceptance criteria that are sent to a developing nation for testing. There is no evidence of collaboration, no shared understanding. When the “specs” fail, we still have a silly argument about what the software should do, what the “given when then” means and if it is correct.

When I ask to see the tests running, I am told that the technical staff cannot show me a test run. The offshore testers run them overnight. No one at the corporate headquarters knows how to run them.

This is an example of “Name it, Claim it”, which is far too popular in Software Delivery Today.

How name It, Claim It happens

A leader in the organization supports an idea. They may make a bold announcement, hold an all-staff, and even send people to training. At this point, they begin telling everyone that they perform the activity – all without following up to see if the idea was ever implemented.

One manager I worked with went so far as to suggest that his team performed “ambiguity reviews” of requirements before they were “accepted.”

No one ever did.

I mean not once, not one time. The manager simply displayed the ambiguity review guidance and took credit for it. For the first few months, I was on his team. We received no direction, timing, advice, or information about Ambiguity reviews; I heard from people outside our team that we were doing them.

Name it, Claim It Can Hurt YouIt doesn’t matter it if’s Extreme Programming, Unit Tests, TDD Microservices or Continuous Delivery — you can’t just name the thing, then claim to be doing. Actual improvement requires investment and experiment. People will make mistakes. The organization will slow down a bit to try the new idea before it can go faster.

Most importantly, management needs to be awake at the switch.

Real management

As a consulting company owner, my biggest problems have been when I have allowed feedback to lapse. Without checking in, I think everything is fine … right up until my contractor gives notice, or I get a frantic call from a customer.

No news is rarely good news.

Real managers don’t just inject change into an organization – they follow up and adjust. At my company, Excelon Development, we tend to think in terms of the six boxes model to manage change. That is, people need more than the word, they need expectations, incentives, skills (or training to develop skills, and opportunity to practice), tools, and the capability to learn. Managers who look to those things will provide people a reason to move in the desired direction.

When name It Claim It comes your way

You’re in a room and a leader claims that the organization is “doing Six Sigma”, or, perhaps “Completed our Agile Journey”, and you feel the journey is … not complete. In some cases, you might not see any evidence of change. At all. In some ways, you might even feel like you are living a lie. Now what?

Here’s two options.

First, is the idea good? Say your director of Software Engineering just held a meeting and claimed you are CMMI Level 3. Level 3 requires code review, and you want code review. So you can just start doing it. When people question you, you say “Are you going to be the one to tell Director Henderson that we aren’t doing code reviews, part of level 3?”

You’ll get your code review.

On the other hand, perhaps you don’t want to do all these extra practices required by the process someone else claimed you were doing. (That you are not doing). In that case, just communicate what you are doing exactly. Tell the next level of management what you are actually doing. Let’s say they understand little of the process that you are doing now. You are collecting no metrics and doing no experiments and they are telling people it is six sigma. Well, that is their problem.

The trick is to not internalize the pain for failing to do something. Don’t feel bad about it. Communicate what you are actually doing and go home at five o’clock.

If you are in leadership, then you want an option better than “Name It, Claim It.”

Let’s talk about that next time.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: