Wednesday, May 18, 2016

Telerik Developer Experts Profile

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!

Tuesday, May 17, 2016

We'll Change Right After... No. No, You Won't.

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

Wednesday, April 27, 2016

Who Assures Quality?

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:

  • 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

Don't Empower. Expect.

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.

Friday, April 08, 2016

Estimating Your Testing Effort

“How long is it going to take you to test the release?”

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.

High-value areas might be things like

  • Checking out properly handles credit transactions, including errors like invalid card numbers
  • Users can save their profile information so it’s automatically retrieved next time they browse
  • Players can no longer hack their mech to run 100 MPH and instead are limited to the 10MPH as specified in the rules

High-risk concerns might include

  • No privacy information is surfaced outside the account holder’s profile
  • No SQL injection is possible on public-facing pages. (A lesser risk is the same concern on internal pages)
  • Performance for the five most-valuable workflows are within the agreed upon metrics

I’ll use that conversation to drive out what I feel is the needed level of effort given the stakeholder’s desire for clarity around their highest priority items.

Want to learn some approaches to estimating your testing effort? Join my pal Matt Heusser on 21 April for a webinar discussing different ways to get reasonable, realistic estimates fleshed out.

More information and registration at the QASymphony site for the webinar. Go sign up!

Sunday, February 07, 2016

Demonstrating Risk, Stability, and Testing

Learning Through Games

UPDATED: Kim Engle pointed out I'd forgotten to include a timeframe to run this. Depending on amount of laughter and discussion this can take between 30 - 45 minutes.

Many coaches use the Jenga game to help illustrate the importance of testing early and often. It’s a fun activity that demonstrates the concepts in a light-hearted but eminently clear way.
I’ve wanted a similar approach to help drive home the idea of stability, risk, and how testing helps mitigate those issues. I also wanted a clear expression of the always-present constraint of time. Moreover, I want to explicitly demonstrate that stable components don’t need anywhere near the amount of testing as less stable components.
I came up with the following approach several months ago, and it’s been very effective the three or four times I’ve run it so far.

Overview

The general idea is to build a structure of a specific minimum height in a constrained amount of time. Attendees are given different materials each iteration with the same height and time constraints. The different materials inject stability issues, making it harder to meet the minimum height requirement within the time constraint. This tends to be a lot of fun, because as with the Jenga game there can be a lot of crashing as structures fall apart.
I’ll start the exercise talking about value and risk—two things I continually hammer home during my coaching sessions—and talk about how this exercise is a tradeoff of value and risk. I don’t specifically call out stability during my explanations. I like that come to the forefront as the game unfolds. Your mileage may vary.

Rock, Dice, Marbles Game

(Apologies to Rock, Scissors, Paper.)

The Goal

Illustrate the interaction of risk, stability, value, and how testing comes in to play helping stabilize things and mitigate risk.
Materials required:
  • One set of dice per team – nine to 12 dice
  • One small rock per team. Rock should be somewhat die-sized and roughly square. You don’t want them too flat—part of the point is the rocks being unstable…
  • Two marbles per team
  • One small blob of putty, PlayDo, or otherwise squishy stuff. This blob should be fairly small. It’s meant to illustrate testing, a constrained resource.
    Dice, clay, rocks, and marbles.
    Setup:
  • Break up your group in to teams. Keep teams under six if possible. Three to five per team seems to work best.
  • Give each team one set of dice. Keep the other materials hidden.

Timeframe: Allow 30 - 45 minutes for this.

Iteration One

Rules for I1:
  • Must build a tower at least eight dice high. I’ll also often use the sides of my Moleskein as a measure instead of just saying “Eight dice” or whatever.
  • Time limit of 90 seconds
Running I1
Explain the rules, then start the timer and have teams build their towers.
When the timer finishes you’ll have some successful teams and some who had trouble with falling towers.
Discussions
This is the first place to start discussing the main point: stability. The structure’s a bit wobbly, even when using dice. Sometimes teams will use interesting approaches to building. Use opportunities as they arise to discuss how different approaches help mitigate instability, risk, etc.

Iteration 2

Distribute a rock to each team. This is generally met with some groans and pained laughter. Play that up! The game’s meant to be fun in addition to educational!
Rules for I2
* Must start tower from scratch. No building on top of existing ones!
* Must build a tower the same height as I1
* The rock must be used as part of the tower. It must contribute to the tower’s height, meaning you can’t just set it off to the side of the tower. It has to have something on it, or be on top of something else.
(I’ve had some creative attempts to get around the intent of this. Testers. Go figure. Again, use this as an opportunity to inject some humor as you describe the rule and ask the teams to honor the intent of it!)
Running I2
Same as before: Start from scratch, 90 seconds, fire the teams off and see what happens!
Discussions
More instability, this time in a big way. I’ve had some teams build smaller towers that included the rock. This is actually a great discussion point: those teams shipped some value! That’s not a bad thing—it offers a great opportunity to discuss value versus risk trade offs!
Look at people who succeeded in any fashion and talk about how they managed their risk/stability.
Now carry the discussions over to software delivery. Make a connection that the stability in this game is a metaphor for different components/systems we work with.

Iteration 3

Pass out two marbles to each team. Yet another opportunity for injecting some serious humor. “Oh no! You’re giving us another rock???” “No! I’d never do anything so mean! Here, have marbles.”
Rules for I3
Same height and time constraints. Start from scratch. Rock and one marble must add to the height of the tower.
One critical modification here: The stakeholder must have a tower at the minimum height. A shorter tower will not deliver him the business value he needs.
Running I3
Same as before. There should be a nice amount of crashes, laughter, and muttering.
Discussion
Huge stability issues. Connect back to software: stable components and systems. Less stable or newer components which haven’t been used for as long. Brand new systems, or ones written very, very badly.

Iteration 4

Now distribute out the small ball of clay/putty. Talk about stabilizing as you’re doing it. Don’t tell teams how to use the clay.
Rules for I4
Start from scratch, same height, 90 seconds. Rocks and marbles must contribute to height.
Running I4
Same as before. Start it off, let it roll.
Discussions
Talk over how teams used clay for stability. I’ve seen a wide range of uses: dots between dice, nothing on dice, big blobs on the marbles, etc. One team made a large pancake of clay and wrapped their rock and die in it—what a great metaphor to tie directly to software wrappers around unstable components!
If the teams haven’t made the connection of clay == testing, help guide them along that. Now’s the time to really head off down the road of “You have 35 - 40 hours a week to apply all your testing expertise. Where are you and your team going to focus? What’s the scary unstable stuff? Where’s the high-risk stuff?”
This is also the spot in this exercise where I really hit home on careful thinking around test coverage, regression, and dear God PLEASE STOP TESTING ALL THE THIRD PARTY TOOLS YOU HAVEN’T CUSTOMIZED.

Finishing Up

You should definitely poll your attendees to see what they got out of this. I always get some neat feedback, and it’s important to validate the attendees got some glimpse of the goal of the exercise.

Note on Licensing of this Exercise

I invented it, I’m licensing it.
Here’s my terms: Use this as much as you want, whenever you want, wherever you want. Pass the concept on to others as often as you want. The sole term in this license is if we are ever in the same place at the same time you must buy me a [drink] and share your experience with the game I mean exercise. Let me know if it worked, and how you’ve changed it.
Awful terms. I get it.
[drink]: Coffee, soda, or beer. Scotch is best; however, I’m happy with anything as long as you share your experience!

Wednesday, December 16, 2015

Give Yourself a Great Christmas Present: A Job With Pillar

Want to start off 2016 with a job that’s challenging, interesting, and fun? Come join me at Pillar Technology!

We’ve got a significant number of job openings across a lot of disciplines. We’re looking for people to fill roles as Delivery Leads, DevOps, Experience Architects (and here at Pillar that is a real role, not some vaporware handwavy marketing thing!), and of course Software Craftsmen!

I joined Pillar last March and it’s been a tremendous time since then. I’ve know the folks at Pillar for years, and I love how they’ve grown in to a focused, passionate, awesome organization. If you looked at Pillar some time ago, I’d encourage you to give us another consideration. This is the best environment I’ve had in my career, and I love the clients I’m working with.

Interested? Drop me a note either at my work address or personal and I’d be happy to chat with you via mail, Skype, phone, or face-to-face. Sorry, no Morse code. I forgot everything after having earned the Signaling merit badge 40 years ago…

Subscribe (RSS)

The Leadership Journey