Leading Beyond The Scramble: Part 2

A few years ago I was discussing an industry trend with a colleague. I wanted to move my career forward, to step up and grow beyond the testing niche I found myself stuck in. My friend listened patiently, and then at the end of the conversation, said “You know what Matt? Sometimes you have to step up and lead.”

It was the right answer … and I found it a bit empty. I wanted some advice on how to lead. “Just do it” left me wanting more.

When I sent my article on the scramble in for feedback, reading between the lines, I think my peer reviewers felt a bit like I had in that conversation. Part one doesn’t tell people how to lead – and certainly not how to deal with resistance.

That’s okay, or at least, I am okay with that. Part one was intended as an inspiration piece; to explain the difference between motion and reaction. That is all.

Still, people thought I could do better.

I think they were right.

Ironically, if I tell you to want what to do, I would be creating a kind of follower. Worse, as I’m not there and you are, my advice would likely be bad. What I can do is tell you a story or two, of a time I worked with a team that was close to panic and helped influence the direction to something more reasonable.

Let’s get started.

Regression Testing in eCommerce Land

It was a major eCommerce site for a wholesaler. The team was executing well, getting new code to production every-other two-week sprint. Our test/release process took a week, which wasn’t bad for a team with 10% testers covering current and the previous version of all major browsers, plus android, iPhone, and iPad devices. To do it we modelled coverage and quality on a low tech testing dashboard we created with Google Spreadsheets.

Then I came in one Friday morning at it all fell apart.

Well, almost.

The plan was to start the morning with a one-hour test training session. I had a copy of Rob Sabourin’s “Ten Sources of Test Ideas”, and each tester was going to create one test idea from three of the categories, and we would discuss. This was the middle of one iteration, and we weren’t going to ship to production for three more weeks.

Except that suddenly changed.

Management wanted to put the new features out now. As in tonight … and to make the ship decision by noon. I could almost feel the condescension as one manager said “it sounds like we won’t have time for your little tester training exercises thing.”, but I did not let that happen.

Because I knew what would happen. The team would feel pressure and bounce around the spreadsheet, either leaving holes in coverage or making all the coverage 1 or 2, which is essential “I breathed on it and it did not fall over.” In other words, we would scramble. At the end of the process, we wouldn’t be able to provide meaningful information to management, and we’d either whine about needing more time or management would make a ship decision without much value from testing. (Unless we stumbled on some bugs that were clearly show-stoppers, which, as I’ll explain in a bit, would have been unlikely.)

The “cover everything a little” approach wasn’t even smart. We knew the features that had gone in the last week; we knew the path-to-purchase that mattered – login to search to the product page, add to cart and checkout. We could customize the coverage based on risk and how critical the features were, plus any other information that mattered, such as what the developers or management were worried about, or browser popularity.

I pushed back. I said we were going to use the meeting to come up with the kind of strategy to enable just this problem – to provide valuable information in one-tenth the time.

So yes, we had my “little training session.” Each tester looked at browser popularity, new features, core features, and Robert Sabourin’s list to come up with three charters to run sessions we estimated to be 20 minutes of length. We put those stickies on a wall and dot-voted them, then sorted by importance. Starting in the TODO column, each tester pulled one test idea at a time into DOING, then DONE, then worked on another, all morning. Management could see what we were working on, they could add new test ideas, they could move the priority around – and they could see what we left to be tested. At noon we got to test and management together and took a poll by having the team “vote” (thumbs up, down, or middle) with if the ship decision should happen.

No one scrambled. No one felt pressured. The testers led that release, instead of following.

It was one of the finer moments of that year.

A Time I Opted Out (“Or What?”)

The story above is true, and it was a good day. To balance things, I’d like to tell you about a not so good day.

It was a different project at a different company, but yet another scramble. The development team was writing reports against tables that did not exist; the test system wouldn’t even boot up and run. It was bad. When I started on the project it was three months late, by which I do not mean the project was late, but that I started three months after it was supposed to have shipped to production.

We did not have a working test system.

Every three months the project management team would slip the schedule by three months. I would literally say “isn’t it time for a three-month slip?” and we would have one.

I have no idea what the technical staff were doing all day. They spent a great deal of effort trying to convince each other they were busy, even though in some cases the systems we were supposed to be working on were no operational. There was a lot of scrambling, of status reports and bluster. It didn’t make any sense. I transferred out after about four months, and the project kept slipping.

The final go-live date was June 1st. Word came from on high that the team had to have things working by June 1st, or “else.” I don’t know what “or else” meant. I certainly didn’t see a reason that we were going to go-live on that day.

I have to shamefully admit that I had some fun with the technical staff, going down to the team area and asking leading questions.

Matt: “So you’re going to go-live on June 1st?”

MTS: “Yes, we will!” Matt: “Or what?”

MTS: “We MUST go live on June 1st?”

Matt: “Or … what?”

MST: “We HAVE to go live on Just 1st?”

Matt: “Right. But what if you don’t?”

You guessed it. No go-live on June 1st.

The project slipped to July 1st (The “true, last, end-of-project, must happen go-live date”) … and they didn’t make July 1st either. Around the middle of July, the company cancelled the project, fired and threatened to sue the 3rd party vendor providing the engine we were trying to integrate with.

As I said, this is not my finest moment. I probably should not have teased the people on the failing project as it was approaching the end-game. That wasn’t very nice. I’m not super-happy about the outcome, either. Matt saved himself, but the rest of the team scrambled. I did not influence the outcome. Then again, looking back, I doubt I could have influenced the outcome. Getting out might have been the best I could do.

One thing I did learn from this is a heuristic to recognize when the scramble around you is a problem; the kind of scramble that will end in failure. These look, from the outside, like any other scramble: Everyone is going insane, running around, because they have to make the deadline. The difference is when you ask for real consequences to the business if the team misses the date. You know you’re in trouble when no one can give you any. That means the scramble is likely artificial and low value. As Ed Yourdon explains in his book Death March – “Sometimes the tough artificial date is because the real value of the project is slow. Scheduling it really would make it not worth doing.”

Don’t be afraid to ask “What if we miss?” – And listen carefully to the answer.

No, It is not going to be the end of the world

Over the years I have heard technical (and business) people of all stripes tell me they “had” to follow, or cheat, or do something else they found distasteful “to feed my family”, or “else I would be fired.”

I’d like to suggest an alternative option besides mindless following.

First, breathe. Clear your mind. Take a walk.

Figure out the worst thing that could possibly happen. You get fired.

Ask yourself: Is that really going to happen? And if it did, so what? You’d get another job.

You might lose your house. So what? Can you get support from family, friends, your church, the government?

It is possible that the most that can happen is damage to your stuff or your pride. And realistically, you won’t lose that much stuff. You’ll get another job. You likely won’t even get fired. You might get a 0% raise one year. I certainly have. The earth will continue to revolve around the sun.

Once you realize that it won’t be the end of the world, you realize that no, you do not have to follow, to give in to the scramble. You can, instead, lead. Propose reality the way you see it, act assertively that way, and other people will see things that way as well. Before you know it, people will look to you for answers.

It’s been said before that the best way to be effective at your job is to act like you don’t care about keeping it.

So forget about the scramble. Forget about the craziness. Take a breath, pause, then do what’s best for the company.

A Final Thought

Sometimes you can’t lead the way out of the scramble. People are excited, frantic, frenzied, going to stay that way, and there is nothing you can do about it. Keep your own wits about you, stay in control of what you can, and remember the name of the project. Once it’s over, count the cost of project SquareCalc, or whatever it is, and remember the name.

Then, the next time the team is about to launch into a scramble, suggest that “Everyone wait a minute. Isn’t this familiar? Isn’t this just like project SquareCalc? Do we want another Squarecalc?”

Sometimes the only way the team can learn, change and grow is through shared experience. You may have to let them experience it, and then remind them of it, all in a gentle, measured way.

Moving away from the scramble is hard to do, I know. Still, you wanted a real article about test leadership.

Whoop.

There it is.