Keeping Things Simple

It was an interesting day in Lake Wobegon.  I spent a fair chunk of the afternoon with a tester who was having a problem.  She was working on writing tests that others would execute - except that the others never followed her scripts.  The really missed the gist of most of the steps.  She kept saying "Why can't they just follow instructions?"

My response was not very nice.  "Why are you writing tests that make sense to you, but others have a hard time executing?  What if you simplified what it was that each test was doing?"

"ALL THEY HAVE TO DO IS READ THE INSTRUCTIONS CAREFULLY THEN FOLLOW THEM!"

Sure.  And if they are confusing?  What if they don't know they are doing the wrong thing?  How could they tell?

Here's the gist of my suggestions from this conversation, and I suspect it may help others in "scripted testing land":

1.  Simply, simplify and then simplify.  If you are writing tests you will not be executing, don't make them mathematical problems to solve - and then follow the equation to get the answer.  Give the people executing the tests the information they need to do what you need them to do.  Don't make them solve puzzles just to start the work.

2.  State what the goal of the test is.  Explain it briefly and what the purpose is.  Explain they why of what they are doing and they may understand better.  They may also think of things of value which you had not considered.

3. Be open to suggestions.  I don't know everything.  I bet most folks don't either - no matter how much they want us to think they do.  Other people may make suggestions.  They make me a better tester.

4. Be open-handed.  When folks (like lower level testers) make a good (or great) suggestion - let them know you appreciate it.  When it pays out in rewards - make sure the greater portion of the credit goes to those who made the suggestion.

5. Be honest with yourself.  Delusions are deadly.

6. Keep calm.

I sometimes upset people without intending to.  Sometimes, well usually, I feel bad about upsetting them.  Unlike some folks I don't say things to intentionally cause pain.

If you are working in a shop where I am working, and where I have been tasked with helping people test better - remember that I will never do anything to hurt you out of cruelty or malice.  If you think I am - say so - then be ready for some more.

My role is to help you improve, just as I turn to other folks to learn.  Usually that pain, speaking from personal experience, is a sign of growth.Your old ideas are passing away.  They are making way for new ways of thinking and that can hurt.  A LOT! 

When the grandkids were living with us and something happened, they were always afraid we would be mad.  No - not usually.  Upset maybe.  Sometimes were got frustrated.  But we were not mad - or angry.  They'd look at us in amazement - "You're not mad at me? Really?"  No.  Sometimes we were a little hurt, but not mad.

"Honey, you have only been on this Earth 12 years.  I can't expect you to know everything.  Sometimes things happen when you don't intend them to.  I'm not mad.  Let's talk about what happened and see if we can find another idea in case this comes up again."

My wife gave me that tremendous gift.  It works with granddaughters, grandsons and (ready?) Junior Testers.

We can't expect you to know everything someone who has been doing this for many, many years knows.  And when we help you it is because we want you to grow and blossom.  We're not mad at you.

Just remember to keep your tests as simple as you can.  That way less experienced folks will understand.  And maybe us old folks will understand as well.

False Heroes and Heroes Revisted

In late March, Twitter was alive with a collection of the Thinking Testers debating the "no heroes" theme which bubbles up from time to time.  I suspect that if you follow a collection of people on Twitter or by reading their blogs, you may have seen some of this.

You may have seen some aspect of the "no more heroes" discussion.  This is the argument that a frighteningly large number of people, many of them manager types, reward "heroes" who "save" a project - even if these same "heroes" are the ones who created the need for heroic behavior.  The oft-cited, and sadly true observation that people will act in which ever behavior is rewarded is painfully true from my experience.

If bosses make a point of rewarding those who regularly "step up and save the project" without looking into why the projects are in trouble, or even looking for trends in whose projects always need saving - then that is what they get - people "saving" projects. 

I truly have no idea why people, bosses in particular, don't see the pattern.  Then again, maybe they do.  Maybe they see it but they just don't want to see it and so pretend that they don't see it because... Yeah.  I think you get it.

One shop I worked at, there was one guy who perpetually did this.  There was always plenty of time to work on whatever the "big" project was.  So, "little" stuff that "needed" to be done tended to get inserted.  These tended to be cool, kinda fun in a geeky sort-a-way.  If the "real" project was really boring, or really uncool, the tendency was to increase these "side projects" that needed to be done even more.

So, what was the response?  All the rank and file developers, testers, PMs, BAs - everyone recognized this pattern.  Everyone knew what would happen.  Everyone had seen it so many times, it was predictable.

SOME code would be delivered close to the "code complete" date.  But it never would be on time.  And the first build never worked.  Instead, testers would get a lecture on how late this guy was up the night before "finishing" the stuff that was delivered.  He considered us ingrates.

When confronted with the cycle of behavior, he, and his manager, would simply fall back to a series of set responses.  "Other stuff was needed right now and he was the only one with the bandwidth to do it."  Except if he really had the bandwidth, the project code would have been delivered on time, and with the promised unit testing done.

Instead, he got praise in meetings for "stepping up."  No.  He did not step up.  He created the situation then stepped into it.  He wasn't a hero.  Sorry.

Michael Bolton made a really important point in the twitter discussion I mentioned above that made me think a bit more on this idea.  It is similar to my own general thoughts, but somehow, he said it much better.

"It seems, when you say "hero", you mean "self-aggrandizer", or "enabler", or... something. But not /hero/."   (@michaelbolton on Twitter, 22 March)

This, I think, is the core problem.  In earlier posts, I talked about "False Heroes" - I've met true heroes and worked with some.  These folks are not heroes.  I think from this point on, I simply will use one of Michael's terms. 

People doing outstanding things in extraordinary circumstances, behaving admirably while those around them falter.  What does it take?  Find a real hero and ask them.  

Note:  I began working on this before the events of 15 April in Boston.  You want to see what a hero looks like?  Scores of them visible in the videos from there.  Heroes contribute because it is the right thing to do, not for the praise and recognition that some are heaped with later.

Hold Fast. #BostonStrong  

Myths or Why Agile May Not Save You

It has been interesting of late for me.  It seems that my corner of the world has discovered this way cool solution to all your problems with making software.

Have you heard about it?  It is so neat.  It is this thing called Agile.   Yeah.  Its cool.  There are conferences about it and everything.  And people talk about how great it is.

Now, there are some truly Agile shops around here.  Some have been here for some time.  Some of these are extremely good.  Others demonstrate what I think of as the Magic Myth of Agile.

We all know that silver bullets don't work, when it comes to software.  We know this because we have seen them not work.  So we've turned to the next best thing. 

Magic.

Yeah, that is even better than a silver bullet.

A couple of weeks ago I had a conversation with a couple of people that turned into Pete smashing their dreams into small tiny pieces.  Brutally.

I was talking with them about their current project and asked some questions on the intended functionality that would be gained.  They answered with where to find the answers in the documentation suite.  So I tried again with "What is the business intent in implementing this change?"  I was referred to the business requirements as documented in the requirements repository, which fed the documentation suite.

I kind of wrinkled my nose a little (I was still being nice, really) and asked if "the guys" who were deep into the project could describe what it was that they were doing, just really high-level, space-shuttle level maybe?  Well, they were them.  And they were not really sure.

OK - Red flag.  Big one.

They said the problem was that there were so many steps and so many people involved that no one really knew what the project was doing because everyone just worked on their bit and no one talked with anyone else. 

Hmmm - OK, do you have project meetings?  Can you ask questions in there?  Well, yeah.  They have meetings every week.  Sometimes twice a week.  But the people who are there are too-busy-to-really-answer-questions-and-want-them-in-an-email-and-then-they-don't-answer-emails-and-they-get-mad-if-you-ask-them-questions-on-the-phone-and-when-you-see-them-in-they-hall-and-ask-them-questions-they-say-everything-is-in-thedocumentationandtheyneedtofollowtheprocessandiftheydon'tfollowtheprocesstherewillberepercussionsandtheywillbesorry!!!!!

whew -Yeah, that is pretty much how that came out. 

Then one of them said something interesting. 

"I wish we'd go Agile." 

The other fellow there jumped in "Yeah, that would solve so many of these problems they were having."

I asked which ones?  The lack of understanding of what was wanted?  The people not responding to questions? People putting them off?  Or - worse in my mind - people wrapping themselves in the cloak of the process model to avoid answering questions? 

"Well, yeah, but with Agile we don't need to do all this documentation stuff, we can just start coding.  That is what from says they do and they are Agile." (Spot the magic shop...)

Isn't that kind of what the process was before this new process model was implemented?  Read the request then start coding?  Don't try and work with people to figure out the purpose and need behind the request, just start coding?

"But we knew what they needed or our managers did so we could always ask them" was the response. 

How will Agile help you?

"We won't need all these stupid meetings and we can just tell people what we're doing and we don't need to document all this junk  That takes so long and no one really reads that stuff anyway."

No one?  How do you make the design if you don't read the documentation you're given then talk with people about what that means and how it can be implemented?  How do you determine how these changes can be best implemented if not talking with people who need the changes to do their jobs?

It sounds like part of the problem you are having is in the way information is shared.  If people aren't communicating now, why do you think they will if the shop suddenly becomes "Agile"? 

"Well, the deliverables are all about writing the documentation stuff, not about talking about it.  Maybe if we did less of that, then we'd have a better understanding."

OK, that seems reasonable.  For the documents that you are supposed to be "contributors" on, do you actually contribute?  Is there the opportunity to do so or are they more like, the person "responsible" writes them and that is that?

"He's in a different department and he says that we can't meet with him in time to make the deadlines for the documents to be completed, so he just writes them.  When we ask questions later he says that it is too late and the documents are already approved and we should have thought about that sooner.  Its really frustrating."

OK, so what about the documents you are responsible for creating?  Do the contributors get a chance to really contribute?

"Well, they say they don't have time, or some of them don't understand what we are talking about and stop reading them."

And now the fun begins.

Since Agile is really all about people working together to make good software, how is it that this would work here?  Can people set aside their other projects and spend time on one at a time?  When you have three or four projects you are working on now, how would you expect that to work if we were an Agile shop?

"You don't get it!  We'd still have the same projects, but we could just do them differently.  We would not need to wait for this other stuff, because there is no documentation in Agile."

Really?  I've never heard that from a reputable source.  Most Agile projects I have seen have had loads of documentation.  The difference is that it was all meaningful.  We did not worry so much about the format or the template, but we made sure that the information, like the decisions made in meetings or discussions, were recorded and it matched everyone's recollections.

The other thing I saw was that people worked on one project at a time and saw it through.  There was not the "3 top priority" projects and the extra stuff to fill in when we had time.  We worked on the project and got the best stuff out that we could get out.

"Man, you just don't get it.  That is not what Agile is all about.  We have to get to a meeting."  ... and there was a bit of muttering as they walked away.

I am afraid that the myths are still there and are still as entrenched in some minds as they were before. I should have asked them if their information on Agile was garnered from things they read on the internet.  After all, everyone knows that if it is on the internet it must be true. 

While I can empathize with them for the frustration, I also fear they have no idea what the real problem they are facing is, nor even how they are participating in continuing that problem.