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!
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.
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.
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 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:
Some experiences that are helpful:
Specific tools in your belt/bag that are helpful:
Interested? Drop me a line: JHolmes@PillarTechnology.com. I’d love to chat with you!
I’ve been a member of the Telerik Developer Experts group since I left Telerik. It’s a group of industry developers who help promote Telerik tools. (Note: Telerik was bought by Progress 18 months or so ago. The Telerik name is sadly going away, but their products are all getting wonderful support!)
Jen Looper, one of Progress’s Developer Advocates, was nice enough to write a small profile about me. I talk quite a bit about the project with one of the most awesome teams I’ve ever worked with, plus I rant a bit about the state of things in huge, slow-moving enterprisey organizations.
You can find the article on Telerik’s blog if you’re interested!
“We’re too busy with the upcoming migration to address our quality
problems right now.”“We can’t handle trying to change our delivery culture until after we
ship this next release.”“All hands on deck to support modifying the system to make this next
deal. We don’t have time to add additional testing around that major
subsystem.”
Are you, or your management, saying things like this? They’re all variants of “We’ll change right after the Next Big Thing.”
Here’s some tough love for you: No. No, you won’t change.
Addressing culture and quality is a slow, long-term journey—especially if the fundamentals around test and software craftsmanship are new to your team. Addressing those issues takes commitment from everyone involved from your top-most leadership to the grunts slinging and testing code. (And the DevOps folks deploying things!) It also takes months to see the huge benefits.
There’s always a Next Big Thing. Always. If you’re only focused on putting out the fire in front of you you’ll never make time to fix the five flat tires on your vehicle. (Because if things are that bad your spare is likely flat too. To badly mix metaphors.)
You can’t change your culture and fix your delivery if you keep rationalizing priorities. Perhaps you can’t go all in on a massive effort, but that doesn’t mean you shouldn’t find a series of small things to improve.
Commit. Take the step.
Otherwise I just don’t believe you’ll change at all.
Who “assures quality” on your projects?
Who assures quality? Is it the team of testers are left out of conversations when features are first being discussed, instead of providing their valuable input on overall complexity, risk, and their impact on business value? That same team of testers who aren’t co-located with developers and do work in parallel, instead of pairing up with devs as the work is being done? Those testers who work on testing as an event after development is complete instead of working on testing as a constant activity starting long before developers write code?
Who assures quality? Is it the team of developers who get technical solutions handed to them instead of being involved in determining how to deliver business value? That same team who spend time fighting organizational-mandated friction-inducing processes instead of focusing on writing code? Those same developers who are pressured in to shipping code faster versus supported in learning how to build well-crafted code that’s maintainable and lends itself to fast delivery of value?
Who assures quality? Is it your business analysts and program/project managers who are told to act as customer proxies without having true, constant interaction with those humans who have real needs? Those same BAs/PMs who are constantly re-directed by management who thinks that “Agile” is an excuse for poor planning?
Who assures quality? None of these folks I just spent half a page talking about.
The only person/role/group that assures quality is the people who write the checks for the work being done. The stakeholder is the sole person/role/group that can assure quality.
Stakeholders assure quality in many ways, including:
Delivery teams help the stakeholder assure quality by:
Who assures quality? THE WHOLE DANG DELIVERY TEAM INCLUDING STAKEHOLDERS.
I’m far from the first person to write about this. I’m just the guy who woke up today with several mails in my Inbox that touched on this subject.
Go back to work now. Have a conversation about value in production, and what that really means. Then go ship value. It feels good. Honest.
We’ve heard plenty about empowering teams:
“You’re empowered to make decisions.”
“You’re empowered to do TDD.”
“You’re empowered to raise concerns.”
Empowering your teams lets them know you’ll support them in doing things the right way. Leaders need to give their people top cover, so this is really a great step.
Unfortunately, just empowering teams leaves them the room to rationalize why they shouldn’t do things we expect of professional craftsmen.
“We were running behind so we stopped pairing.”
“Bob wasn’t here this week, so we skipped all our Three Amigos conversations.”
“Someone reset the QA environment and all our data got wiped out. We had too much work in progress, so we didn’t stop to refactor our tests to handle their own data setup.”
These sorts of things aren’t what you want with your teams. You’ve given them the room to do things right by empowering them. Take the next step and make it clear you’re expecting them to get these things done. Moving to a culture of expectations helps your team members hold each other to a higher standard. “Hey, we skipped tests on this story. Let’s pair up and go fix it right now.”
Do what it takes to make expected behaviors clear. Speak up, send unequivocable communications, ensure your “done” barometers clearly state these activities must be accomplished.
Change the culture. Now. Stop talking about empowering. Talk about expecting.
Subscribe (RSS)
The Leadership Journey
