I was recently handed the "gift" of a very aggressive deadline. It happens, you don't set the date - it gets set for you. (Ironically, Johanna Rothman just wrote a short bit on that topic on her blog.)

When aggressive deadlines get set for you, if you're like most managers, you start to ask questions to see how realistic the dates are and you try figure out what exactly you can and can't get done in that time frame. When I do that, I ask my team to help. I often pull people in early, and ask them to start looking into what testing we need to do, what environments we'll need, what data, what... you get the idea.

An important question I ask before I start to pile on more work (because any time I ask a question, I'm likely asking for more work), is what they are currently working on. Sometimes I'm surprised by the answer. I have a fairly self-organizing team, and they juggle a lot between themselves without checking with me first. So by asking first, I can keep myself from becoming my own biggest problem.

Before adding more work, ask what people are working on. Then, if they have too much, work with them to prioritize what needs to be done first, and what can fall off their plate.

In a recent blog post, Antony Marcano posted his mnemonic for managing risk: MARTA

Mitigate
Avoid
Reduce
Transfer
Accept

Read the full post for details behind each point.

Susan Cramm recently wrote an article on best practices on the HBR website. In the article, she points out that:

In reality, "best practice"...
...isn't always the "best"
...often isn't feasible
...is sometimes unachievable

Instead she recommends focusing on...

Adapting best practices...
Defining quality processes...
Having experienced people...

Checkout the full article for details.

When I'm managing session-based exploratory testing, I spend a lot of time measuring charter velocity. There are a couple of key dynamics I look at:

• charters executed per day


• new charters created per day (broken down by charter priority level)

I typically capture these by tester, but I often look at them as a team aggregate. While I'm interested in individual trends for coaching, for a team of more than two testers, it's more interesting from a team perspective when it comes to creating trendlines. I show an example of how I use these numbers in a recent SSQ article.

Sometimes, when reviewing charters with the team, I look to them to help provide some insight into what we should be focused on with our testing. One technique is to walk your list of charters (all twenty or them, or all 200) and have each person provide some insight into where they think it falls in priority. To facilitate this, I sometimes use a thumb vote.

When thumb voting, everyone must vote. There is no sideline. Since I usually use three levels of charter priority (A, B, and C), those map as follows:

• thumb up = A


• thumb sideways = B


• thumb down = C

What I find is that for most charters, most people on the team are on the same page (or really close). Every now and then, you have to make a decision on a close tie (but since you're the test lead, you're use to doing that anyway). Sometimes however, you see some odd votes. Like four up and four down. Those votes normally lead to some really great conversations. Often, people misunderstand the charter or have a different understanding of the risk involved. This surfaces those differences.

It's also fun. (In an I'm-a-tester-so-voting-on-charters-is-fun sort of way.)