Monthly Archives: February 2010

Regularly releasing potentially shippable software

Brian Marick wrote a couple of years ago that “Teams that don’t produce potentially shippable software at the end of each iteration are likely in trouble.”

With more and more teams using a kanban approach to developing software, it would seem that producing potentially shippable software on a regular basis would be more common. But is it? Does your team produce potentially shippable software at the end of each iteration? Why or why not? What can we do to make it the case?

Kanban requires a rigorous dedication to building software. If your “agile circumstances” are less than ideal — and really, how often do you have an ideal situation? — such as an unengaged customer, nebulous deliverables or uncertain deadlines, you need to be all the more rigorous. Build in practices that keep the team honest, like a regular demo (even if the customer doesn’t attend). I’ve seen too many teams burn themselves by waiting until the last week of the project to create a CI build server or see if they could cut a release. If the team releases potentially shippable software starting after the first week of the project and continuing regularly, they’ll save themselves a lot of headaches and reduce the risk of a nightmare end of the project.  And they’ll focus on giving their customer something of value each week, instead of what amounts to a bunch of work in progress at the end of the project.


Leave a comment

Filed under Uncategorized

What’s in a name?

At Asynchrony several teams have dedicated QA leads. These team members spend a portion of their time testing, but they also help customers write stories, and they define acceptance tests and take the lead in automating them, among other activities. I know a lot of people in the software world refer to the people who do these activities as “Agile Testers,” but, with no malice intended, I reject the term “tester.” That’s because it fails in two ways: First, QA leads do much more than merely test, and second, it implies that they are the only ones who test, when in fact, everyone on the team should test. Ultimately, the activities that the person does are more important than the title he goes by. But words are still important, and to the extent that people tend to identify activities with roles and roles with titles, I think “QA lead” is more helpful than “Agile Tester.”

Leave a comment

Filed under Uncategorized

My ideal job description

In order to think more intentionally about how your career is going, I think it’s useful to think about your ideal job description. Then you can assess where you are and how far you need to go to get there. Perhaps articulating the description can even be helpful for conveying your position to your manager and having a constructive conversation about making it happen (in some cases, it may even be refreshing and welcome news to your manager). Here’s where I see the value that I bring intersecting with activities that I enjoy, in order of frequency:

  • Work in agile software-development teams doing QA lead activities. That includes pairing with developers to write automated tests and drive acceptance-test-driven development, overseeing relevant metrics and engage the team in conversation about them, working with customers to elicit requirements. (daily)
  • Facilitate retrospectives for other teams (weekly)
  • Read relevant newsgroups and articles on QA topics (weekly)
  • Spend a couple of hours a week blogging on QA topics (weekly)
  • Mentor other QA leads in the company (biweekly)
  • Be responsible for a monthly article on QA topics for company distribution (monthly)
  • Coach/consult with teams in agile transition (quarterly)
  • Teach agile QA course to QA leads (quarterly)
  • Attend industry conferences, like Agile, STARWest, CITCON, etc. (semi-annually)

Leave a comment

Filed under Uncategorized

Creating safety at a first retrospective

A colleague recently asked me for some input on leading a team’s first retrospective:
I am leading a team’s first retrospective soon. From my initial research, it seems many of the participants are “scared to death” (mainly because they do not know what to expect). There is also speculation that it will be a challenge to get those same people to speak up. Any suggestions?
One thing that I’ve found to be helpful in making everyone feel comfortable to talk is doing an icebreaker activity in which everyone speaks. For a team that was new to me and was having its first retrospective, I started with a simple “emotion check-in” (on a post-it, write a word or phrase about how you’re feeling right now). Instead of having them read their own, I had them put them in a hat, pass the hat back around and pull out someone else’s, and read it. That gave them a chance to speak without any real pressure. Studies have shown that when someone speaks once, he or she is more likely to speak again.

Leave a comment

Filed under retrospectives

Taking responsibility

Being excellent starts with a nominal commitment to take responsibility for yourself. One area of responsibility is attending meetings, and being on-time. Unfortunately, some people eschew this responsibility, as evidenced by the following IM chat I actually had with someone:

Matt Philip: we’re going to plan a bit tomorrow morning from 9-9:15 — can you make that?
name.redacted: maybe
Matt Philip: Ok, great
name.redacted: call me @ 8:30
Matt Philip: why don’t you set an alarm for yourself?
name.redacted: nope
Matt Philip: I’m not your mom.
name.redacted: nope, but you’re the organizer
Matt Philip: organizer != hand-holder
name.redacted: (organizer != hand-holder) == bad organizer == no attendees
Matt Philip: That’s true, if the attendees are people who can’t take the minimal responsibility for themselves to show up for a meeting without someone holding their hand.
name.redacted: yep

I imagine that, at some point in the not-too-distant past, showing up on-time for meetings was an expected behavior for anyone who planned to hold a job for more than a day.

Leave a comment

Filed under bad examples

CITCON North America 2010

From Paul Julius:

Hey everyone!

I wanted to let you know about CITCON North America in Raleigh Durham on April 16 & 17. If you can’t make it yourself, please do pass along this invitiation to your friends, colleagues, cohorts, guildies, etc. I hope to see everyone again this year at one of the instances. Note that we are doing Singapore this year, too. So that makes 4 CITCONs world wide that you could attend. I’ll give a special prize to anyone that makes all 4 (excluding JTF)!

CITCON, the Continuous Integration and Testing Conference, is an open spaces conference in its 5th year. The topics aren’t decided until the first night of the conference, but past events have proven extraordinarily useful to anyone interested in Continuous Integration and the type of testing that goes with it. Developer-testers, tester-developers, tool creators, and Agile advocates have all gained a lot from attending.

The conference is free to attend! You have to pay $20 to register, but you get that back when you attend the conference.

This year, the North American event will be in Raleigh-Durham at the Sheraton Chapel Hill Hotel. Registration is open, but limited to the first 150 registrants. Sign up now to reserve your spot at this innovative, exciting, education, fun event.

The conference operates as a non-profit, so our advertising budget is basically zero. We can use your help to get the word out. If you know someone that might be interested, please pass this announcement along to them.

Also, if your company or a company you know would be interested in sponsoring CITCON, there are a wide range of sponsorship options.

If you have any questions, please don’t hesitate to contact me.

Paul Julius
Co-chair, CITCON 2010

Leave a comment

Filed under announcements, conferences

What is an “excellentist”?

First, it’s not a word. Not as far as I know, anyway. And it’s not some cross between Edwards Deming and Bill S. Preston, Esq. But I like it because it expresses something of how I want to approach the work I do as an agile QA lead and tester. I’m not a perfectionist, but I am (or at least try to be) an excellentist. That is, I’m not perfect and don’t expect others to be perfect, but I do want to be excellent and work with others who expect the same from themselves, and from me, to create a culture of excellence. It’s not quite Soup Nazi-level, but this exchange hints at the idea:

SOUP NAZI: You are the only one who understands me.

KRAMER: You suffer for your soup.

SOUP NAZI: Yes. That is right.

KRAMER: You demand perfection from yourself, from your soup.

SOUP NAZI: How can I tolerate any less from my customer?

1 Comment

Filed under announcements