Category: Life

I recently resigned from the company I had been employed by for over 5 years. The reason? It was time.

During my tenure1 I had the opportunity to re-define my career several times within the organization in a way that added value and kept life productive, challenging, and rewarding. Each re-definition involved a rather extensive mind mapping exercises with hundreds of nodes to described what was working, what wasn’t working, what needed fixing, and where I believed I could add the highest value.

This past spring events prompted another iteration of this process. It began with the question “What wouldn’t happen if I didn’t go to work today?”2 This is the flip of asking “What do I do at work?” The latter is a little self-serving. We all want to believe we are adding value and are earning our pay. The answer is highly filtered through biases, justifications, excuses, and rationalizations. But if in the midsts of a meeting you ask yourself, “What would be different if I were not present or otherwise not participating?”, the answer can be a little unsettling.

This time around, in addition to mind mapping skills, I was equipped with the truly inspiring work of Tanmay Vora and his sketchnote project. Buy me a beer some day and I’ll let you in on a few of my discoveries. Suffice it to say, the overall picture wasn’t good. I was getting the feeling this re-definition cycle was going to include a new employer.

A cascade of follow-on questions flowed from this iteration’s initial question. At the top:

Why am I staying?

Is this work aligned with my purpose?

Have my purpose and life goals changed?

The answers:

The paycheck

No.

A little.

Of course, it wasn’t this simple. The organization changed, as did I, in a myriad of ways. While exploring these questions, I was reminded of a story my Aikido teacher, Gaku Homma, would tell when describing his school. He said it was like a rope. In the beginning, it had just a few threads that joined with him to form a simple string. Not very strong. Not very obvious. But very flexible. Over time, more and more students joined his school and wove their practice into Nippon Kan’s history. Each new thread subtlety changed the character of the emerging rope. More threads, more strength, and more visibility. Eventually, an equilibrium emerges. Some of those threads stop after a few short weeks of classes, other’s (like mine) are 25 years long before they stop, and for a few their thread ends in a much more significant way.

Homma Sensi has achieved something very difficult. The threads that form Nippon Kan’s history are very strong, very obvious, and yet remain very flexible. Even so, there came a time when the right decision for me was to leave, taking with me a powerful set of skills, many good memories, and friendships. The same was true for my previous employer. Their rope is bending in a way that is misaligned with my purpose and goals. Neither good nor bad. Just different. Better to leave with many friendships intact and a strong sense of having added value to the organization during my tenure.

The world is full of opportunities. And sometimes you have to deliberately and intentionally clear all the collected clutter from your mental workspace so those opportunities have a place to land. Be attentive to moments like this before your career is remembered only as someone who yells at clouds and tilts at windmills.

Somewhere along the path of studying Aikido for 25 years I found a useful perspective on the art that applies to a lot of skills in life. Aikido is easy to understand. It’s a way of living that leaves behind it a trail of techniques. What’s hard is overcoming the unending stream of little frustrations and often self-imposed limitations. What’s hard is learning how to make getting up part of falling down. What’s hard is healing after getting hurt. What’s hard is learning the importance of recognizing when a white belt is more of a master than you are. In short, what’s hard is mastering the art.

The same can be said about practicing Agile. Agile is easy to understand. It is four fundamental values and twelve principles. The rest is just a trail of techniques and supporting tools – rapid application development, XP, scrum, Kanban, Lean, SAFe, TDD, BDD, stories, sprints, stand-ups – all just variations from a very simple foundation and adapted to meet the prevailing circumstances. Learning how to apply the best technique for a given situation is learned by walking the path toward mastery – working through the endless stream of frustrations and limitations, learning how to make failing part of succeeding, recognizing when you’re not the smartest person in the room, and learning how to heal after getting hurt.

If an Aikidoka is attempting to apply a particular technique to an opponent and it isn’t working, their choices are to change how they’re performing the technique, change the technique, or invent a new technique based on the fundamentals. Expecting the world to adapt to how you think it should go is a fool’s path. Opponents in life – whether real people, ideas, or situations – are notoriously uncompromising in this regard. The laws of physics, as they say, don’t much care about what’s going on inside your skull. They stubbornly refuse to accommodate your beliefs about how things “should” go.

The same applies to Agile practices. If something doesn’t seem to be working, it’s time to step in front of the Agile mirror and ask yourself a few questions. What is it about the fundamentals you’re not paying attention to? Which of the values are out of balance? What technique is being misapplied? What different technique will better serve? If your team or organization needs to practice Lean ScrumXPban SAFe-ly than do that. Be bold in your quest to find what works best for your team. The hue and cry you hear won’t be from the gods, only those who think they are – mere mortals more intent on ossifying Agile as policy, preserving their status, or preventing the perceived corruption of their legacy.

But I’m getting ahead of things. Before you can competently discern which practices a situation needs and how to best structure them you must know the fundamentals.

There are no shortcuts.

In this series of posts I hope to open a dialog about mastering Agile practices. We’ll begin by studying several maps that have been created over time that describe the path toward mastery, discuss the benefits and shortcomings of each of these maps, and explore the reasons why many people have a difficult time following these maps. From there we’ll move into the fundamentals of Agile practices and see how a solid understanding of these fundamentals can be used to respond to a wide variety of situations and contexts. Along the way we’ll discover how to develop an Agile mindset.

Looking at the growing stack of draft posts, I see about a dozen on the subject of mastery. I feel I have a lot to contribute to this subject, particularly in regard to Agile practices. And yet, I hesitate due to a sense that I still have more to learn before I’m in a position to teach on the subject. In no small measure this hesitation is counseled by having met and studied with a great many truly masterful people across a wide variety of human experience.

Emily was one of those masters.

Not only was she a master of Aikido (6th degree black belt and Sensei at Nippon Kan), she was a master jeweler. She designed and made the wedding rings for both my first and second wife along with several beautiful pendants and a set of ear rings for one of my nieces. I never had a personal jeweler before Emily and shall not have another before my time is finished on this earth.

For all her skill and mastery, she very much understood the importance of service. There was no task that needed attention at the dojo or in preparation for a seminar that was beneath her rank. And I wonder how many patrons to Domo restaurant knew they had their order taken and served by a 6th degree black belt.

Emily had already achieved the rank of black belt by the time I began practicing at Nippon Kan in 1989. My very early memories from practicing with her are of her patience and ability to skillfully instruct a 6’5″ oaf like me in the ways of Aikido – both on and off the mat. I don’t know if Emily even weighed 120 pounds, but that never stopped her from putting my sorry ass on the mat or sending me over her shoulder. Even so, I never matched Emily’s skill, even on my good days.

Those mastery related posts will have to wait a while longer. And in the wider view, my respect for those whom make claim to be masters without having done the work and earned the title have lost a little more of my respect.

When my experience with scrum began to transition from developer to scrum master and on to mentor and coach, early frustrations could have been summed up in the phrase, “Why can’t people just follow a simple framework?” The passage of time and considerable experience has greatly informed my understanding of what may inhibit or prevent intelligent and capable people from picking up and applying a straightforward framework like scrum.

At the top of this list of insights has to be the tendency of practitioners to place elaborate decorations around their understanding of scrum. In doing so, they make scrum practices less accessible. The framework itself can make this a challenge. Early on, while serving in the role of mentor, I would introduce scrum with an almost clinical textbook approach: define the terms, describe the process, and show the obligatory recursive work flow diagrams. In short order, I’d be treading water (barely) in endlessly circuitous debates on topics like the differences between epics and stories. I wrote about this phenomenon in a previous post as it relates to story points. So how can we avoid being captured by Parkinson’s law of triviality and other cognitive traps?

Words Matter

I discovered that the word “epic” brought forth fatigue inducing memories of Homer’s Iliad and Odyssey, the Epic of Gilgamesh, and Shakespeare. Instant block. Solution out of reach. It was like putting a priceless, gold-plated, antique picture frame around the picture postcard of a jackalope your cousin Eddie sent you on his way through Wyoming. Supertanker loads of precious time were wasted in endless debates about whether or not something was an epic or a story. So, no more talk of epics. I started calling them “story categories.” Or “chapters.” Or “story bundles.” Whatever it took to get teams onto the idea that “epics” are just one of the dimensions to a story map or product backlog that helps the product owner and agile delivery team keep a sense of overall project scope. Story writing progress accelerated and teams were doing a decent job of creating “epics” without knowing they had done so. Fine tuning their understanding and use of formal scrum epics came later and with much greater ease.

“Sprint” is another unfortunate word in formal scrum. With few exceptions, the people that have been on my numerous scrum teams haven’t sprinted anywhere in decades. Sprinting is something one watches televised from some far away place every four years. Maybe. Given its fundamental tenets and principles, who’s to say a team can’t find a word for the concept of a “sprint” that makes sense to them. The salient rule, it would seem, is that whatever word they choose, the team fully understand that “it” is a time-boxed commitment for completing a defined set of work tasks. And if “tide,” “phase,” or “iteration” gets the team successfully through a project using scrum than who am I to wear a the badge of “Language Police?”

A good coach meets the novice at their level and then builds their expertise over time, structured in a way that matches and challenges the learner’s capacity to learn. I recall from my early Aikido practice the marked difference between instructors who stressed using the correct Japanese name for a technique over those that focused more on learning the physical techniques and described them in a language I could understand. Once I’d learned the physical patterns the verbal names came much more easily.

Full disclosure: this is not as easy when there are multiple scrum teams in the same organization that eventually rotate team members. Similarly, integrating new hires with scrum experience is much easier when the language is shared. But to start, if the block to familiarization with the scrum process revolves around semantic debates it makes sense to adapt the words so that the team can adopt the process then evolve the words to match more closely those reflected in the scrum framework.

Philosophy, System, Mindset, or Process

A similar fate awaited team members that had latched onto the idea that scrum or agile in general is a philosophy. I watched something similar happen in the late 1980’s when the tools and techniques of total quality management evolved into monolithic world views and corporate religions. More recently, I’ve attended meet-ups where conversations about “What is Agile?” include describing the scrum master as “therapist” or “spiritual guide.” Yikes! That’s some pretty significant mission creep.

I’m certain fields like philosophy and psychotherapy could benefit from many of the principles and practices found in agile. But it would be a significant category error to place agile at the same level as those fields of study. If you think tasking an agile novice with writing an “epic” is daunting, try telling them they will need to study and fully understand the “philosophy of agile” before they become good agile practitioners.

The issue is that it puts the idea of practicing agile essentially out of reach for the new practitioner or business leader thinking about adopting agile. The furthest up this scale I’m willing to push agile is that it is a mindset. An adaptive way of thinking about how work gets done. From this frame I can leverage a wide variety of common, real-life experiences that will help those new to agile understand how it can help them succeed in their work life.

Out in the wild, best to work the system and process angles if you want meaningful work to actually get done.

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.

The challenge was how to put two 90 degree bends across a 10 inch arch in a 12 foot long, quarter inch thick piece of red oak (1) for the edge of a breakfast nook table. To do this I had to work out a way to bend long pieces of wood without having to mess with the need for a super extra-large steam box. The idea came from a shipwright named Louis Sauzedde. His trick is to use heavy poly tubing(2) to steam-bend wood in place rather than use a traditional steam box. The advantage is that the wood doesn’t cool when transferring from a steam box to a jig and, best of all for small shops, you don’t have to take up space storing a large steam box. Version 1 of my steam kettle was built using an outdoor propane burner (3), a re-purposed brew kettle (4), an oil drip pan (5), PVC piping (6), a radiator hose (7) for positioning, and the unfinished table top (8) as a jig.

(Click for larger image.)

#6 was a mistake. The PVC worked, but didn’t hold up to the heat. It didn’t exactly melt, but it definitely didn’t hold shape over the hour long steaming process. #8 was a big mistake. Concern about damaging the walnut top made set-up longer than it needed to be and I couldn’t get the clamps where I needed them. I was trying to take a shortcut and not hassle with making a proper jig. Oh, and another piece of important advice. Always, always, ALWAYS be wearing a good pair of work gloves (1). All parts of the steam system – burner to kettle to steam pipe to radiator hose to poly tubing to wood – are HOT and more than likely something will slip during clamping and you’ll have to grab hold. Not much fun with bare hands.

(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.)

A day to set, a lot of edge routing, and a bit of sanding shows the end result: Near-perfect 90 degree bends. I was also able to remove a little bit of twist that was occurring in the wood thanks to the better steam output from Kettle 2.0 and the use of multiple smaller clamps across the arc. The final unfinished result shows a tight fit between the edging and the table (1).

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