Agile Testing with Lisa Crispin

This afternooon, I joined Mike Sutton’s Improv session. My takeaway: “It doesn’t hurt to collaborate”. The exercises were fun and funny, and gave insight into how teams worked together. I particularly liked that Mike used a task board to keep track of his session.

Mike Sutton moving cards on talk task board

We did a lot of fun exercises, and had lots of opportunities to do the “failure bow” (similar to “How Fascinating” in Language Hunters) we learned from Tobias in the warm-up this morning. We encountered so many things that happen on software projects. For example, when we had to draw a picture by committee, each person had a different viewpoint on the picture and a different idea of what we were drawing.

Ball Flow Game

Next, I joined the Ball Flow Game facilitated by Olaf Lewitz and Gerry Kirk. This turned into a hilarious example of “too many cooks in the kitchen”, in my opinion. Just try to get a bunch of agile coaches together and get something done! We started out really well, producing the inventory of “magic balls” efficiently, in just over one minute.

Then, naturally, since we had done pretty well, we changed everything at once and came up with a totally new way to “deliver” the magic balls. My personal estimate of five minutes was not too far off the real result. It was a good opportunity to reinforce the fact that it is better to do small experiments and only change one thing at a time than to do a drastic reorganization.

Attempted Game Development

Paul Boos, one of the ACCUS organizers, was kind enough to let me take a slot in the agenda to get help in trying to develop a game that would teach tester-developer collaboration. My goal was a quick game that would teach testers that it’s not a bad thing to test early and often, and teach programmers that it’s valuable to have testers involved throughout development. I can’t afford Legos and I don’t like to check my bag when I travel, so I wanted to do something with a construction kit that uses plastic straws (similar to drinking straws) and connectors.

Some participants created works of art!

A wonderful group of people came to help. They started throwing out ideas, and it first, it seemed there was no way I could create the kind of game I wanted with the straw kit. While they brainstormed, participants built some awesome straw constructions, proving that using our hands does help us learn and think!

It turned out that you can build a lot of two-dimensional shapes with the straws: squares, rectangles, circles, arches, hexagons, lips. The group proposed that the first part of the game would be for each team to build all the shapes. These could be “tested”. In the second phase, each team would put the 2D shapes together into 3D shapes, and try to build the biggest structure that could hold its own weight when picked up. This also would encourage incremental testing.

An additional idea was to throw in “hidden requirements”. For example, when the facilitator comes around to verify the 2D shapes, she could say, “That is indeed a square, but I forgot to tell you, all the straws in the square must be blue.” This would simulate a real-life project.

This isn’t the quick game I envisioned, but it has potential, and I think it’s worth trying out. Thanks to everyone who helped me, I’d never have thought of this on my own! Collaboration rules!

I’m looking forward to Agile Coach Camp and more learning, insights, and friends.

It’s lunchtime at ACCUS Games Day. Tobias Mayer warmed us up with some exercises that involved the whole group (60 – 70 people!) One was doing a “failure bow”, similar to the Language Hunters “How Fascinating!” If you feel you failed, raise your hands in a victory pose and shout out something happy. We will be doing this all weekend, I am sure!

One interesting insight came from comments on the enemy-shield/friend game. Often, a ScrumMaster or manager feels their role is to “protect” the team. Tobias noted that we are all adults and can protect ourselves. That made me think. I think our manager sometimes tries to protect us from the bureaucracy and silliness of our new parent company, with the best intentions, but I think sometimes that backfires. For example, if a manager proposes some half-arsed technical implementation for something the parent company wants, thinking it will reduce pressure on us and save us time, that isn’t really helping us. Better to let us be told directly about the business problem to be solved, then let us find the right way to solve it.

I tweeted that quote (really a paraphrase), and several people disagreed, saying that development teams may need protection from undue outside or management pressures. That’s valid. When my team first transitioned to agile, our manager convinced the business executives to let us have all the time we needed to learn good ways to develop software. Practices such as TDD are hard, and if you’re pressured to deliver, you won’t take the time needed to master them. If you’re punished for failures, you won’t experiment. So there is definitely a place for some protection of the team. Conversely, nobody should inhibit good communication between the development team and the customer team.

Coaching Skills Dojo

There were five track sessions to choose from after the warm-up, and it was hard to choose, but I went with Michael Sahota’s coaching skills dojo. This was a great chance to practice coaching, and learn by observing others and by playing the role of the client.

We started out by identifying observation, listening and questioning skills that coaches need. Then we took turns playing client, coach and observer. When playing client, we used real problems that we have. We had 20 minute sessions with five minutes for each ‘turn’, then five minutes of debrief.

Andrew Fuqua writing our ideas on observation, listening and questioning skills in Michael Sohata's coaching skills dojo

I feel my coaching skills are lacking, so I was fearful of this, but knowing I could use the “failure bow” gave me courage to take risks. It is so interesting to ask good questions, use appropriate body language, listen and observe well to help a client understand his problem and think of possible experiments to solve it. I have takeaways both in terms of coaching skills – I shouldn’t be afraid, I do have the skills, I need to remember and listen more, and help the client clarify the problem – and on what I learned from being coached on actual problems!

This afternoon, there are three timeslots, each has five sessions. So many choices, so little time! I’m looking forward to learning some new games, honing my coaching skills, and also getting help developing my own game to help testers and developers learn to communicate and collaborate better.

I have been doing some writing in the past six weeks, in addition to rehabilitating my broken-and-now-healed ankle. But it’s all been published elsewhere. Here are some links:

Software Quality Connection, “How to Improve Communication between QA and Development“

SearchSoftwareQuality.com, “Agile development: The whole-team approach”

Also on SearchSoftwareQuality.com, “The whole-team approach to Agile development: Examples and benefits“

I’ve got a bunch of tips and Ask the Expert Q&A on SearchSoftwareQuality.com, please check them out! I’d appreciate feedback.

My review of Uncle Bob Martin’s The Clean Coder is up on my Techwell blog. If you’ve read the book, I’d love to hear your thoughts on it. If you haven’t read the book, please do so!

My interview with Simon Baker was posted on Stickyminds and Techwell today. There will also be highlights in the next issue of Better Software.

I consider our software development team to be one of the coolest on the planet. I’ve met a lot of teams around the planet – well, ok, only three continents – and I can only think of one that might be cooler than ours. We’re a small team, we have a great track record for the past 7+ years, we’re valued by the rest of our company, we’re allowed to do our best work, we’re always improving. We work at a sustainable pace, no nights, no weekends, no crazy hours. What’s not to like? (Yes, you’ll find me tweeting and blogging at odd times, but I enjoy writing, and at the moment I’m laid up with a broken ankle).

And yet, I’ve been tweeting for several weeks now about the fact that we want to hire a Java programmer and a software tester, and posted on several mailing lists, and the response has been underwhelming. I whined about this a couple weeks ago on Twitter, and received some good inspiration in response. One pointed me to Trish Koo’s blog post where she recruits a tester for her company (she’s in Sydney, luckily we aren’t in competition), and the other was to Atomic Object’s tester recruiting page (they’re in Grand Rapids, we’re in Denver, I rest my case).

This is my personal blog, not an official recruiting site for my employer, ePlan Services (A Paychex Company), and I’m not the hiring manager (I’m not a manager of any sort, but we all have input into the interview and hiring process), but I’d like to take the opportunity to do a little recruiting anyway.

What’s In It for You?

We’re a small team, following Agile principles, using most of the XP practices, working in a mix of Scrum, Lean, Kanban and whatever else works for us. We collaborate, we help each other, nobody’s afraid to ask for help, and we jump in on any task that needs doing. We’re a true part of the business, helping to set priorities and solve business problems, not the “software team” off in a corner. And we need you, a valued peer with whom we are proud to work!

You’ll work on a web-based financial services app, written in Java with some Groovy, using Spring, Hibernate and Velocity, and supported by tens of thousands of tests in JUnit, FitNesse, Canoo WebTest and Watir. Ours is a challenging domain to learn, but we work closely with awesome folks on the business side to understand what they need and find the simplest ways to deliver that.  If you like working test-first, in small increments, getting quick feedback from automated regression tests and from business stakeholders, you’ll enjoy working here.

We take a Whole Team approach to quality and testing. We start every theme and user story by first thinking about how we’ll test it. We discuss upcoming themes and stories with the Product Owner and other stakeholders and write high-level requirements and test cases together. Testers develop test cases and strategy in more detail, in collaboration with customers, and specify tests to drive development. Developers automate those tests as they write the production code. Testers automate the GUI regression tests in Canoo Webtest. Testers do extensive manual exploratory testing, helped with Ruby/Watir scripts.

Working here, you’ll enjoy time to learn, with teammates willing to help. Does some other test framework seem like it might solve some automation problems? Another tester, developer or sys admin will probably be willing to pursue that idea with you. You’ll be working with a team of truly inspiring and fun people. If you like to play Quake, you’re really going to enjoy it here.

Rather than take up a lot more space here telling you about our team, I encourage you to read the many blog posts here (and also please see the links on my Articles and Publications page) that recount our real-life experiences. For that matter, you can read the book I co-wrote with Janet Gregory, which includes countless examples from my team. I also encourage you to check out my teammate Nanda’s blog. And my teammate Tony Sweets has also published articles based on ideas he’s implemented here, check out his blog. I could give you more teammates’ blogs, but I think this will give you enough information to know if you’d enjoy working with us.

What You May or May Not Like

If titles and “career path” are important to you, this might not be the place for you. I do have a fancy title, but what I put on my card is “Tester”, and that’s the title for the position we’re hiring. The Java programmer title is “Software Engineer”, I personally don’t see why we want to call ourselves engineers, but we are called the “engineering team” – I pick my battles.

The “advancement” you get on our team is the chance to continually learn, experiment, try new technologies and techniques, collaborate to solve business and technical problems. There are only ten people total on our team now, and 42 in the whole company, so there’s not a traditional corporate ladder. Our good work is rewarded and valued, you’ll feel the love in both extrinsic and intrinsic rewards. You’ll enjoy working here if you’re passionate about developing the best possible quality software product. And, because you like to enjoy your work and have a job that’s both challenging and fun!

Here are the job descriptions and the information on whom to contact. I encourage you to include an experience you’ve had that shows you’re a great fit for our team, based on what you read in our various blogs and articles. Please feel free to contact me as well, I’m happy to answer questions.

* * *

Software Tester

Software Testers at ePlan Services are part of an Agile team that builds the software to allow our company to be a leader in providing Internet-based 401(k) plans for small companies. If you are passionate about delivering value to your customers, we would like to talk to you about an immediate opening at our location in the Denver Technology Center.

To become a software tester at ePlan Services, you will need:

• Experience with software testing techniques such as manual and exploratory testing, test automation, performance testing, or security testing.
• Strong technical skills demonstrated by experience with programming or scripting languages such as Java, C, shell script, or Ruby.
• To collaborate with a variety of people in our company to make sure our software works for our customers.
• Some experience with databases, data modeling, and SQL.
• To show a commitment to ongoing professional development through self-learning, professional training, participation in open source projects, attending conferences etc.

If the above description accurately describes your experience and approach to software testing, please send your resume to:

Trevor Sterritt

trevor.sterritt@eplanservices.com

* * *

Software Engineer

Software engineers at ePlan Services develop the software that allows our company to be a leader in providing Internet-based 401(k) plans for small companies. If you are passionate about delivering value to your customers, we would like to talk to you about an immediate opening at our location in the Denver Technology Center.

To become a software engineer at ePlan Services, you will need:

• A high degree of expertise in Java and Spring.
• To be a dedicated follower of test driven development methods and technologies.
• Some professional experience with Hibernate, SQL, and web development languages such as HTML, CSS, and JavaScript.
• To show a commitment to ongoing professional development through self-learning, professional training, participation in open source projects, attending conferences etc.

If the above description accurately describes your experience and approach to software engineering, please send your resume to:

Trevor Sterritt

trevor.sterritt@eplanservices.com

My summary of the WAT2 conference this past May, in Durango, appears on the SearchSoftwareQuality.com website (you have to register to see content, registration is free, I apologize that it’s a bit of a pain to have to register). I was inspired by this year’s theme of style and grace, as well as the amazing participants, leading testing practitioners from the U.S., Europe and Israel.

ALE Network

I had the honor of presenting a short webinar talk at the second ALE (Agile Lean Europe) Network Bathtub Conference on June 30. I gave two examples from my team on how we have used experiments to address issues that surfaced in our retrospectives. All the presentations from this terrific event are available on the ALE Bathtub Conference website. All of the sessions were full of great information and ideas to try, be sure to check them out! And remember, they’re all short, so it’s easy to watch them.

I just posted our team’s recent experience in taking a different approach when presented with an unusual problem: one theme that needs to get out the door, and another that will be hard to “hide” but will take multiple sprints. Please check it out on my Techwell/Stickyminds blog. How does your team handle unusual situations?

My teammate Nanda Lankalapalli and I have an article in StickyMinds on how we use technical debt sprints to keep our technical debt to a manageable level. There are lots of approaches to managing technical debt – what works for your team?