Show your work

A presentation I gave last week sparked the need to reach back into personal history and ask when I first programed a computer. That would be high school. On an HP 9320 using HP Educational Basic and an optical card reader. The cards looked like this:

(Click to enlarge)

What occurred to me was that in the early days – before persistent storage like cassette tapes, floppy disks, and hard drives – a software developer could actually hold their program in their hands. Much like a woodworker or a glass blower or a baker or a candlestick maker, we could actually show something to friends and family! Woe to the student who literally dropped their program in the hallway.

Then that went away. Keyboards soaked up our coding thoughts and stored them in places impossible to see. We could only tell people about what we had created, often using lots of hand waving and so much jargon that it undoubtedly must have seemed as if we were speaking a foreign language. In fact, the effort pretty much resembled the same fish-that-got-away story told by Uncle Bert every Thanksgiving. “I had to parse a data file THIIIIIIIIIS BIG using nothing but Python as an ETL tool!”

Yawn.

This is at the heart of why it is I burned out on writing code as a profession. There was no longer anything satisfying about it. At least, not in the way one gets satisfaction from working with wood or clay or fabric or cooking ingredients. The first time I created a predictive inventory control algorithm was a lot of fun and satisfying. But there were only 4-5 people on the planet who could appreciate what I’d done and since it was proprietary, I couldn’t share it. And just how many JavaScript-based menu systems can you write before the challenge becomes a task and eventually a tedious chore.

Way bigger yawn.

I’ve found my way back into coding. A little. Python, several JavaScript libraries, and SQL are where I spend most of my time. What I code is what serves me. Tools for my use only. Tools that free up my time or help me achieve greater things in other areas of my life.

I can compare this to woodworking. (Something I very much enjoy and from which I derive a great deal of satisfaction.) If I’m making something for someone else, I put in extra effort to make it beautiful and functional. To do that, I may need to make a number of tools to support the effort – saw fences, jigs, and clamps. These hand-made tools certainly don’t look very pretty. They may not even be distinguishable from scrap wood to anybody but myself. But they do a great job of helping me achieve greater things. Things I can actually show and handle. And if the power goes down in the neighborhood, they’ll still be there when the lights come back on.

What’s in YOUR manual?

You go to see a movie with a friend. You sit side-by-side and watch the same movie projected on the screen. Afterward, in discussing the movie, you both disagree on the motives of the lead character and even quibble over the sequence of events in the movie you just watched together.

How is it that two people having just watched the same movie could come to different conclusions and even disagree over the sequence of events that – objectively speaking – could have only happened in one way?

It’s what brains do. Memory is imperfect and every one of us has a unique set of filters and lenses through which we view the world. At best, we have a mostly useful but distorted model of the world around us. Not everyone understands this. Perhaps most people don’t understand this. It’s far more common for people – especially smart people – to believe and behave as if their model of the world is 1) accurate and 2) shared with everybody else on the planet.

Which gets me to the notion of the user manuals we all carry around in our heads about OTHER people.

Imagine a tall stack of books, some thin others very thick. On the spine of each book is the name of someone you know. The book with your partner’s name on it is particularly thick. The book with the name of your favorite barista on the spine is quite a bit thinner. Each of these books represents a manual that you have written on how the other person is supposed to behave. Your partner, for example, should know what they’re supposed to be doing to seamlessly match your model of the world. And when they don’t follow the manual, there can be hell to pay.

Same for your coworkers, other family members, even acquaintances. The manual is right there in plain sight in your head. How could they not know that they’re supposed to return your phone call within 30 minutes? It’s right there in the manual!

It seems cartoonish. But play with this point of view for a few days. Notice how many things – both positive and negative – you project onto others that are based on your version of how they should be behaving. What expectations do you have, based on the manual you wrote, for how they’re supposed to behave?

Now ask yourself, in that big stack of manuals you’ve authored for how others’ brains should work, where is your manual? If you want to improve all your relationships, toss out all of those manuals and keep only one. The one with your name on the spine. Now focus on improving that one manual.

Autopilot Agile

There is a story about a bunch of corporate employees that have been working together for so long they’ve cataloged and numbered all the jokes they’ve told (and re-told) over the years. Eventually, no one need actually tell the joke. Someone simply yells out something like “Number Nine!” and everyone laughs in reply.

As Agile methodologies and practices become ubiquitous in the business world and jump more and more functional domain gaps, I’m seeing this type of cataloging and rote behavior emerge. Frameworks become reinforced structures. Practices become policies. “Stand-up” becomes code for “status meeting.” “Sprint Review” becomes code for “bigger status meeting.” Eventually, everyone is going through the motions and all that was Agile has drained from the project.

When you see this happening on any of your teams, start introducing small bits of randomness and pattern interruptions. In fact, do this anyway as a preventative measure.

  • One day a week, instead of the usual stand-up drill (Yesterday. Today. In the way.), have each team member answer the question “Why are you working on what today?” Or have each team member talk about what someone else on the team is working on.
  • Deliberately change the order in which team members “have the mic” during stand-ups.
  • Hold a sprint prospective. What are the specific things the team will be doing to further their success? What blockers or impediments can they foresee in the next sprint? Who will be dependent on what work to be completed by when?
  • Set aside story points or time estimates for several sprints. I guarantee the world won’t end. (And if it does, well, we’ve got bigger problems than my failed guarantee.) How did that impact performance? What was the impact on morale?
  • During a backlog refinement session, run the larger story cards through the 5 Whys. Begin with “Why are we doing this work?” This invariably ends up in smaller cards and additions to the backlog.

There’s no end to the small changes that can be introduced on the spur of the moment to shake things up just a bit without upsetting things a lot. The goal is to keep people in a mindset of fluidity, adaptability, and recalibration to the goal.

It’s more than a little ironic and somewhat funny to see autopilot-type behavior emerge in the name of Agile. But if you really want funny…Number Seven!

Agile in the Wild

There are some decidedly Zen-like paradoxes to practicing almost any form of agile methodology. People practice agile everywhere, yet they have a hard time finding it at work. It’s the most natural form of technical project management I’ve experienced, yet people seem determined to make it harder than it is and over-think the principles. And when they shift toward simplifying their agile practice, they go contrary to good advice that everything should be made as simple as possible, but not simpler.

So a challenge: Before the month is out, take a moment to reflect on some important task you completed that had nothing to do with work and see how many things you did reflect an agile principle or common practice. Maybe it’s work you did on a hobby or at a volunteer gig. Perhaps it involved some kitchen wizardry, a tactful communication maneuver with your children, or routine house maintenance. Did you iterate across several possible solutions until you found success? Did you decide to decide something later so that you could gather more information? Did you take a particular task to “good enough” so that you could complete a more urgent related task? And which of your insights can you bring into work with you?

In this article I’ll describe a recent experience with Agile in the Wild and the lessons that can be applied in your work environment.

(Click for larger image.)
(Click for larger image.)

The end result was a not-quite-bent-enough piece of wood (Westie terrier, “Rose,” for scale.) The wood needed to be steamed again.

(Click for larger image.)

Version 1 of the steamer was modified such that the drip pan was flipped (1) for a better seal on the kettle, metal piping (2) replaced the PVC, and a more flexible radiator hose (3) was used for easier positioning. Version 2 of the steamer was a significant improvement. I got better steam output from this rig so the lignin in the wood was a little easier to bend in a shorter amount of time. Most importantly, a throw-away jig (4) was built for much better clamping.

(Click for larger image.)

Must have safety feature: An anti-curious-dog flame guard made out of sheep fence (1). Curious dog (2) optional.

(Click for larger image.)

After bending and clamping in place the steam was removed, the plastic cut away, and the wood left in the shop until I had free time to unclamp the oak from the jig. With the jig I was able to clamp the wood at multiple places across the arc. And no worries about damaging the expensive walnut of the actual table top.

(Click for larger image.)

Back in the shop, the edge is glued, clamped, and left to set after dealing with an unexpectedly uncooperative bend that shows signs of having been cut from stock near a knot (1).

(Click for larger image.)
(Click for larger image.)

Agile Lessons

  • Get help. Someone already knows the solution you seek, or most of it anyway.
  • Short cuts are often the long way to get to where you are going.
  • The MVP: Goes together fast, is cheap, built just good enough to actually test in the wild (safely, I would add.)
  • Reuse existing assets that are adapted to suit the current need (Can equipment used for brewing beer be used in fine woodworking? Absolutely! All you have to do is think outside the brew kettle.)
  • The Jig: It isn’t part of the final product. In all likelihood it won’t ever be used again. Was it waste or an essential part of getting to the final product? Design flow diagrams and wireframes are analogous to jigs. You’re supposed to throw them away! Think how utterly horrific our final products would be if we included all the interim work in what we delivered to the client.