Wednesday, April 27, 2016

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:

Providing enough funding to ensure each role (PM/BA, dev, tester) is adequately staffed

Giving enough time on the schedule to allow systems to be built in a solid, maintainable fashion

Ensuring project teams have the resources (resources, damnit, NOT people) to do their jobs

Working out a reasonable priority for value, and not reprioritizing at a whim

Delivery teams help the stakeholder assure quality by:

Providing useful information to the stakeholder about the project’s state

Useful information, NOT counts of bugs, number of test cases, lines of code, etc., etc.

Ensuring the stakeholder knows the impacts of reprioritizations and scope changes

Also, understanding that those changes are often actually important

Holding each other accountable to creating high-value, well-built systems

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.

Thursday, April 21, 2016

“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.

Friday, April 08, 2016

Heard that question before? What team hasn’t? It’s a fair question from the business, even if they don’t understand the complexities involved.

Often I’ll turn the question around, not to push back on the stakeholder, but instead to try and level-set on what the stakeholder’s goal is. Testing is emphatically not about “assuring quality.” Testers can’t do that, only the whole team can. Instead, testing is about providing information about the system/product/application’s value, risk, and suitability.

I’ll work with the stakeholder to understand their most important goals for the release, then focus my testing efforts around those goals. Those goals should include the stakeholders high-value areas and also high-risk concerns.

About Me

I'm the owner/principal of Guidepost Systems. I help lots of great folks figure out what works and what doesn't in the world of delivering quality software -- something I'm very passionate about. I'm also a Father trying to remain sane while trying to build great software, herd my kids around, fix school lunches and handle the yardwork. (And roast great coffee!)