Previously

This is the ninth in a series about TDD’s value to humans, following

  1. Keeping my job, in which I lost my manager’s trust,
  2. A last-minute feature, in which I regained some,
  3. Deadline pressure, in which I earned quite a bit more than I’d started with,
  4. Continual delivery, in which the circle of trust grew to include our Operations team,
  5. Fail-safe, in which we were always deploying soon,
  6. A big project, in which we delivered an 8-month project with minutes to spare
  7. Win-win, in which we helped another project hit the same deadline, and
  8. No secret, in which people oddly found the reasons for our success disappointing

A growth opportunity

Our team had solidly established the habit of writing good tests first and listening to what they told us. People who could read Perl could read our tests, and we’d taken full advantage of that to build shared understanding with stakeholders of sufficiently technical backgrounds, whose trust served to reinforce the effectiveness of our collaboration and our product. We knew how valuable it’d be if we could find a way to extend that understanding and trust to a broader audience. We were on the lookout.

When our product and team moved to a better-fitting department, our team’s reputation garnered some attention from our new neighbors. For the first time, we found ourselves living next to a group of QA folks, whose perceptive manager saw us as an opportunity. His more skilled people could help us and learn from us. Would I like to borrow one of them for a full two-week iteration?

Unlike previous occasions when I’d been offered a person on short-term loan, I instantly had a pretty good idea how we could put a skilled tester to effective use. But not yet. First, we needed to prepare.

Our preparations

Our TDD practice was already oriented toward system behavior, aimed at uncovering not only design choices but also acceptance criteria. We would usually find surprising ramifications of a chosen approach early in development, while it was still relatively cheap to review with stakeholders and either get more precise agreement or adjust the goal. We wanted our borrowed tester to comfortably participate in those conversations and potentially contribute test scenarios. We now needed a language more shared and more commodious than Perl. And we didn’t need — indeed, couldn’t afford — to start shlepping around any manual tests or non-executable specifications on our journey. Dear reader, you doubtless see what we saw: Gherkin could be our shared language, and Cucumber could incorporate it into our build.

There was one small problem: none of us had ever used Cucumber before. We didn’t want to waste any of our tester’s limited time figuring out how to wield a new tool. We wanted to be ready the moment he arrived. So we immediately picked a feature perfect for learning: a low-urgency feature intended for the benefit of our compatriots in Operations, and whose desired behavior we understood very well. Instead of confidently writing our usual tests, we wrestled with how best to express our assertions in Gherkin-inflected English, and how best to arrange for them to fail meaningfully against the production code we were wanting to change.

When we got it figured out well enough, with Cucumber hooked into the build, we asked Ops to review the spec with us. Because they could! And maybe they’d spot something we’d misunderstood! When they didn’t, we proceeded to test-drive as usual, albeit with slightly different red-test messages; when we got to green, the feature was every bit as done (and well done) as usual.

The payoff

We were ready for our tester. When that iteration kicked off, we would set right to pair-writing scenarios, likely conjuring more meaningful tests than we’d have done on our own, and our visitor would be acquiring a new and marketable skill.

Or at least he would have, if the window of opportunity hadn’t been rudely slammed shut.

A change of plans

The original offer, and our preparatory actions to take advantage of it, occurred while product decisions had still been mine — which is to say, when the team had opinions distinct from mine, I generally listened and took them into account. But I was in transition to a much-needed role as an internal Agile coach, so my team and product were necessarily in transition too. By the time the promised iteration rolled around, product decisions were no longer mine — which turned out to mean they were made with very limited consideration for the team (me included).

The new product manager promptly nixed any further efforts with Gherkin as a language, Cucumber as a tool, and QA as a partner in our development process. No reason was ever shared with us for this decision, which we felt wasted our investment in time and effort, ignored our needs and wishes, and limited our options for improving our effectiveness.

Conclusion

Cucumber continued to be the test runner for that lone Ops feature. But who knows how much it might have helped us collaborate more productively with testers, non-technical managers and customers, and the business as a whole? We never got the chance to find out.

Posted Thu Jul 2 22:30:05 2015 Tags:

Back to our roots

Last week I had the privilege of speaking at Agile Roots in South Jordan, Utah, a place hemmed in by mountain ranges to the east and west. An image that depicts how it felt to be there was hard to capture, but as the plane came into Salt Lake City, I was able to capture this:

SLC landing

The mountains to the east hold Snowbird, the place where “Agile” was given its particular meaning. I’m not religious about the Manifesto, or much else, but I couldn’t shake the feeling I was someplace important — possibly because with so many outstanding speakers, I felt particularly honored to be included.

That’s just it

And if there’s a single word that conveys why my experience at Agile Roots was so special, it’s “included”. I haven’t always felt that way at other conferences I’ve attended, even as a speaker. But from the moment Alan Dayley suggested that Agile Roots was the sort of conference I’d enjoy, and as Lisa Crispin and I were preparing our workshop, I suspected this experience would be different. And by the time I’d been administered a Pat Maddox power hug and had lunch and dinner with some other speakers, I knew.

Agile Roots was amazing: small and familial, filled with great people, and run with evident love and care. A beautiful conference, and an honor to be — and feel — part of it.

SLC sunset

Listen to one of my talks

Schmonzcast #18: In addition to the workshop, I gave an experience report. At an Agile-unfriendly Fortune 100 bank, with little budget or domain expertise — and no testers! — our tiny team’s discipline and creativity enabled us to safely and reliably manage risk, deliver value, and earn precious trust. If you like, you can hear me tell a few stories of our most effective maneuvers.

Posted Wed Jun 24 23:41:00 2015 Tags:

PSL

Last week I and 23 others made a pilgrimage to Albuquerque to participate in the Problem Solving Leadership workshop.

What did we do all week?

Mainly exercises, discussion, and reflection on designing problems to be solved, environments in which to solve them, and ourselves.

Can I say more about any of that? No, I don’t want to ruin anyone else’s fun.

What did I learn about designing problems and problem-solving environments?

Maybe nothing, maybe lots. Not sure yet. Maybe I’ll notice over time, as I’m facing various challenges, that I seem to keep having better ideas about how to approach them. One idea I’ve had before that occurred to me again:

Observation from exercise retro: we always work in iterations, whether we choose them or not.

Another: for the entirety of the workshop, Esther and Jerry modeled changing focus rapidly between the problem, how we’re solving the problem, and how we’re arranging ourselves to solve the problem. I value this kind of self-correcting thought process very highly, and it was an unusual chance for me to observe it in others (and not only our facilitators) for an extended period.

What did I learn about myself?

Self-observation: few things are more exhausting to me than seeing someone treated unkindly.

Conversely, others can tell that I make efforts to be kind.

Observer feedback: I’m like a lone hiker. I go off on my own, be creative, and am accepted back because I bring something valuable.

I found the metaphor striking and the explanation somewhat surprising, considering:

Self-observation: I’m more energized by being part of a conspiracy than by being a lone conspirator.

But there’s never been any question where I get my energy. Further proof:

Coffee + cool, dark, quiet time + reflection = second wind. Classic introvert.

What will I remember?

Getting to know some nice people with fast brains.

Acting as emergency backup consultant during lunch so Jerry could eat too.

Feeling validated when my approach to consulting was apparently (1) not entirely unlike his and (2) helpful.

Sitting quietly with Jerry for a few minutes, sharing something very dear to me, and appreciating his appreciation.

Should you attend PSL?

That depends. Are you as capable as you’d like to be at creating an environment that enables everyone to contribute productively to solving problems?

Posted Thu Jun 18 02:37:55 2015 Tags:

Previously

This is the eighth in a series about TDD’s value to humans, following

  1. Keeping my job, in which I lost my manager’s trust,
  2. A last-minute feature, in which I regained some,
  3. Deadline pressure, in which I earned quite a bit more than I’d started with,
  4. Continual delivery, in which the circle of trust grew to include our Operations team,
  5. Fail-safe, in which we were always deploying soon,
  6. A big project, in which we delivered an 8-month project with minutes to spare, and
  7. Win-win, in which we helped another project hit the same deadline

Our somewhat interesting behavior

Our track record of delivering working, valuable code every month began to attract some mild curiosity. For most teams, the organization’s barriers to releasing production code had the effect of encouraging them to go to production less often with only the planned changes. We didn’t see that as an effective way to manage risk for — or add value to — code with test-driven properties. To suit our context, we chose the opposite approach: go to production more often with whatever was ready. Onlookers were curious to note that this game we were all playing could evidently be played so differently without immediately and visibly losing.

Our very interesting behavior

When we delivered a project on deadline while supporting another project being delivered on deadline, our strange approach (whatever it really was) looked much more like a winning strategy. Onlookers who might have dismissed our monthly release-what’s-ready cadence as “undisciplined” might have felt motivated to reevaluate. Our previous track record plus a successful project attracted much more curiosity.

What about QA?

One question I’d get asked was, how did our QA people validate the changes we were making so frequently without strictly adhering to a plan? Surely this was taxing for them. How did we arrange their work to be able to sustain our pace?

We didn’t have any QA people. Our tiny team on a tiny budget had learned, of austere necessity, to survive without. Our software had wide-ranging security implications. We had to work in a quality-assuring way at all times. There was no QA bottleneck because there was no QA phase.

This was a surprising answer. Nearly all development teams had “QA people” (whatever that even means). I would occasionally get an offer of someone for a few days, but I never knew what to have them do. What could they manually test that we hadn’t already automated? What could they exploratorily find that we hadn’t already found? To be polite, and just in case, I would accept these offers, summarize what was new lately, and point them at the GUI. We got very little value from this arrangement. If we could have added a permanent team member with complementary testing expertise, it might have been much more valuable. Still, not having someone didn’t seem to be impeding us.

So what was our secret?

It was also an intriguing answer, because it appeared to take the form of “doing more with less.” Everyone always needed to be doing more with less. Their next question was, what were we doing to obtain this level of quality, speed, and predictability?

Most of our quality and speed came from TDD. Most of our predictability came from test coverage and Scrum-style velocity. But TDD would have been difficult, and velocity-based predictions would have been disappointing, if we hadn’t first rescued our code just enough to where we could incrementally improve its health over time. What was it that we were doing? Being skilled, disciplined, and patient.

Unable rightly to apprehend

I hadn’t expected this to be a surprising answer, so I was surprised by the responses it provoked. Faces that had been pumped full of anticipation deflated. “We can’t scale that,” said one. It hadn’t occurred to me that anyone could be hoping for easy actions and fast results to what I knew to be hard problems. Charles Babbage famously rebuked someone for asking an incoherent question about his computing machine; I was seeing what looked like an incoherent reaction to my answer about our software development machine.

Conclusion

How could I account for so rapidly having transmuted respect for our outcomes into disappointment in our methods? Not knowing, I had to wonder. Practicing TDD had expanded our sphere of influence greatly and made us more effective in many ways. Would the trend continue?

Posted Wed Jun 10 10:58:48 2015 Tags:

What I did

On Friday I attended Self.conference just long enough to take in Justin Searlsopening keynote, give my talk (sorry, intentionally no slides or recording), have an assumption-questioning lunchtime conversation with my friend David, and get to the airport. It’s not that I didn’t want to stay longer, but it had suddenly become more pressing that I go meet this fellow:

the nephew

No regrets about my prioritization decision, but also no question I missed out. Had I stayed longer, I would’ve had more conversations (dunno which) and attended more talks such as these:

(More slides)

Nonetheless, I’m proud to have played a very small part in a conference dedicated equally to developing software and developing humans.

What you might do

The organizers are seeking donations to help cover for this year’s sponsorship shortfall. If you’d prefer to wait and review the conference financials first, they’ll be made public shortly. But if you’re already sure you’d like to pitch in, you can.

I’m sure. I want the chance to experience what I missed.

Posted Wed Jun 3 12:52:09 2015 Tags: