Podcast on Three Amigos

The nice folks at Telerik (a Progress company) were kind enough to host me for a discussion on how using the Three Amigos can dramatically improve your teams’ effectiveness. Ed Charbeneau saw my blog post “All In With The Three Amigos” and thought it would make a good conversation.

You can find the show at Telerik’s Developer Network blog.

Listen for yourself and let me know what you think!

Video of My 'Automated Testing Beyond the Basics' Talk

Last month I did a new talk at StirTrek: “Automated Testing: Beyond the Basics.”

The great folks at StirTrek recorded the sessions and posted them on YouTube. Because they’re all awesome. Watch the video below, or on YouTube.

My usual gonzo deck is up on SpeakerDeck.

All In With Three Amigos

Are you running Three Amigos conversations for each work item/user story your team does? If not, start now. Seriously.

Effective Three Amigos conversations cut confusion, reduce rework, and ensure the entire team clearly understands the why of what they’re building. Teams ensure acceptance criteria are clear, nail down test data, discuss data flows, and clear up a myriad of other potential roadblocks—before a single line of code is written.

Over the years I’ve come to the belief Three Amigos is the best thing you can do for improving your software delivery teams’ effectiveness. I used to think it was running good retrospectives; however, I’ve changed focus to Three Amigos.

Three Amigos is a small step you can adopt in your delivery process regardless of what methodology you use. It doesn’t matter if you’re using XP, Scrum, waterfall, or chaos. You don’t need some massive change proposal to your organization’s formally approved process—Three Amigos is nothing more than an effective conversation about each work item.

Here’s how you can start if you’re not familiar with them: For every work item—Every. Single. One.—have your developers, BAs, and testers gather together as the work item is pulled off for work.

Start with a small list of questions for the group to discuss. The questions vary for teams, but here’s a set of questions I’ve used for teams I’ve worked with.

• WHY are we building this? What is the business value this brings to our users?
• Are acceptance criteria clear enough?
• What risks are associated with this? (Regression, dependencies, etc.)
• Does this item impact existing tests and functionality?
• What test data is needed?
• What will be tested in unit, integration, and UI tests? (Who tests what.)

The point of the discussion is to clarify a number of things on each work item in order to avoid confusion, rework, and errors. Well-run Three Amigos generally take five to ten minutes, sometimes shorter. Initially they’ll be longer as your team learns how to work with them.

If there’s any confusion then you have an opportunity to clear it up before you do work. Bad acceptance criteria? Go talk to the product owner and change them. Unsure what test data you need? Take a sidebar and sit down for further discussion. Confusion over who’s testing what? Whiteboard out data flows, workflows, and architectural impacts so the devs and testers can iron out what’s going to be handled in unit, integration, functional, and exploratory testing.

You should have a Three Amigos on every work item, even if it’s just to agree no Three Amigos is needed for that particular work item. Sometimes different team members might have different views about a work item. If you don’t meet, you won’t know.

Again, rolling in to Three Amigos is the single most effective, low-friction thing you can do to improve your teams’ ability to deliver great software.

Need a starting point? Grab my template (Word 2013 document) and modify it to suit your needs!

Are you running Three Amigos? Do you use different discussion points? Let me know what works for you in the comments.

I'm Looking for a Tester / Value Stream Compadre

I’m looking for someone to join me at Pillar Technology to help our clients improve their testing, quality, and value work for their delivery teams. Interested? Read on!

We’re filling a position for an Executive Consultant—someone as a mid-level to senior-level consultant. Pillar doesn’t do staff augmentation (generally). We work with clients who are honestly looking to transform how they look at solving problems through software. My efforts with clients to date have been both tactical and strategic.

At the tactical level I’ve been involved in building testers’ basic testing skills, learning appropriate automation, and working to change mindsets about focusing on valuable work. That’s come about through workshops, pairing, ongoing training, and helping get work done.

Pillar’s strategic level work for our clients helps organizations find ways to increase value by adopting new processes, practices, and mindsets. That means learning to effectively communicate with the “business” side of the house around things like value streams, flow of work, whole-team quality practices (No, testers are not the Quality Assurance folks.), modernizing testing skills, and a host of other activities.

We’re looking for mid- or senior-level consultants to come on board and dive in with me. Here’s the “Must Have” list:

• Empathy. We value our roles as trusted advisors. Empathy to the clients’ situations is crucial.
• Attitude. You’re doing the job because you want to. You’re helping lift others up because you see the benefits.
• Aptitude. You’re able to be successful. What you don’t know you’re willing to dive in and learn—.

Some experiences that are helpful:

• Walk the walk. You’ve been a practitioner of agile and Lean approaches over a number of years. You know how to adjust for situational context.
• Understand the power of “I don’t know.” Have the confidence to admit weaknesses, because you know where to go find answers and help.
• **Skilled at quickly building up an effective test plan.**You know how to focus on risk, value, and what the customer feels is most important.
• Experience talking value to business. You know the difference between creating epics, features, and user stories that are technical solutions versus items that deliver value to the customer.

Specific tools in your belt/bag that are helpful:

• Exploratory testing. You’ve done it, and you can explain why it’s different than ad-hoc or monkey testing.
• Software craftsmanship. You’re able to talk about why it’s important and can provide some guidance around it, even if you’re not a developer by trade.
• Automated testing. You’ve done it with different tools, you’ve suffered with mistakes you’ve made, and you’ve worked through those mistakes. You know where it fits, where it doesn’t, and how to create a good map of coverage of different testing types. You also understand and deeply believe in the difference between checking and testing, even if you don’t care to waste time arguing about what’s a test or check.

Interested? Drop me a line: JHolmes@PillarTechnology.com. I’d love to chat with you!