Category Archives: Learning

Response Unicorn Isn’t Responsive (When Your Team Doesn’t Get “Agile” or “Lean”)

In response to Agile: 3 Signs That You May Be Drinking Unicorn Blood by Joseph Nielsen. Joseph is a friend and former co-worker who’s reviewed my stuff in the past, and we collaborated on the concept for this post. I’m just a year late in publishing it.

Whatcha Mean We Wanna Be Agile? What The Hell Is Lean?

Having spent at least half of my career on teams with ad hoc organization and work practices, this is a question I once asked. It was my first time at Agile Roots in early 2010 when I knew I wanted to be Agile. I mean, I understood the value of some of the tools and practices often associated with Agile. Like several people from my company at the time, I had caught the “vision” and thought bringing back some of these tools and practices would make our organization Agile.

I was a development team lead at a previous employer at the time and was utterly unprepared for the level of resistance we would receive from both upper management and individual contributors on my team. Knowing what I know now about change and why people find it scary, I’d recommend my younger self to read the book Fearless Change: Patterns For Introducing New Ideas or a similar work. Nevertheless, I (and several others) pushed forward with our “agile rollout.” We created physical kanban boards on every empty wall in sight and held standups around them. In the meantime, the company was hiring traditional PMO project managers who were trying to put it all into MS Project, and some folks were trying to get traceability by plugging the results of standup into electronic kanban boards using Team Foundation Server.

Rightly, many folks were questioning the approach and overall vision. Developers just wanted to go back to having their 30-45 minutes being spent in standups back. Management wanted PMO-style project traceability, and accuracy be damned. Analysts wanted to build their requirements and throw them over the wall to developers. QA testers and dev wanted to interact as minimally as possible.

They were all quoting Carly Simon whether they knew it or not.

Are you seeing some problems?

We didn’t get buy-in.

We didn’t have a concrete strategy for implementation.

Most importantly: WE WEREN’T HAVING RETROSPECTIVES. For some misguided reason, we made the same mistake I’ve seen so many others make: we thought standups were the key, not retrospectives. To be honest, I’m not even sure we knew where to start.

I’ve heard this called frAgile. At any rate, eventually something had to win out, and it was the waterfall/ad hoc approach. We took down all the boards and ended all of our agile experiments at the direction of leadership. I don’t blame them. The whole situation was a hot mess.

Other Ways To Do It Wrong

I had seen the light, and therefore, the next company I worked for wasn’t adamantly against Agile. I made sure of it. However, that company is no longer in business. No, I don’t think it had much to do with their agile adoption or the semblance of it they had. This group had many of the basics of Scrum in place, even if they got there partly by accident.

They would pick up bits and pieces and bolt them on until, at a certain point, they had standups, planning meetings, reviews with stakeholders, and a leader huddle which sort-of worked like a scrum of scrums. But they were estimating work in hours, they didn’t organize cross-functionally, stuff was “thrown over walls” for others to pick up all the time, and THEY WEREN’T HAVING RETROSPECTIVES.

You might ask, where did the good practices come from? The folks in charge had those ideas. If an idea didn’t come from someone in charge, it probably wasn’t an idea worth having. All fine and dandy, but you can imagine the teams didn’t feel much autonomy (a key motivator from Daniel Pink’s Drive). They certainly weren’t coming up with a lot of great ideas on how to be better.

I came in and still had my Agile Roots-colored glasses on. Everything I wanted to do was related to getting folks thinking about continuous improvement, continuous learning, and reflecting on what we were doing and experimenting to see what we could do better. (By the way, I believe that as an Agile organization, those are the main components you MUST HAVE to get to a thriving place.)

At any rate, my enthusiasm was– out of place, and my leaders reminded me on several occasions that I should mind my position and keep my head down.

So I did.

They promoted me for it. Twice.

With a little more clout, I picked my battles, and where possible, I tried to get the folks I worked with to think differently. We were starting to see some progress. Developers were getting excited about our work again. They were getting back the passion for this amazing job we do. By this time I was the software architect for all the teams, and I was unhappy. Even if folks in the org were starting to catch the vision, upper management was not. I believe they thought we had our working system and didn’t need to try to make it better. Two years was an awfully long time to see as little progress as we had, and I felt like I was still dragging leadership along kicking and screaming.

Additionally, the company was struggling financially (and worse than I knew). When I announced my intent to start looking for another job, the next day I was asked to put in my notice after having been promoted during that same calendar year. They couldn’t afford me if I weren’t in it for the long haul.

So I tucked my tail between my legs and decided to do better at picking my next employer. I wanted a place where Agile was already a reality, or at least where a culture of learning and improving wasn’t just “this silly idea Will has.” Three weeks later I was starting work at what I hoped would be the right place. The lesson, as far as I was concerned at the time, was that bottom-up influence doesn’t work for Lean-Agile adoption.

The Grass Was Greener (Purpler)

HealthEquity touted their culture when I was interviewing, and I DID NOT buy into it at first. My previous employer was ranked in the top 50 for corporate culture in the nation more than once by Forbes. “Culture” was no longer a brand of kool-aid I drank. I guessed the purple drink was probably laced with cyanide or strychnine.

I did know three things about HealthEquity:
1. A friend of mine already worked there, referred me, and spoke highly of the place.
2. The director I’d be reporting to was new to the company, and he seemed to share some of my values and was open to new ideas.
3. The company was offering competitive wages including stock options. I didn’t assign a mental value to the stock options (they had none), but I figured if they were incentivizing folks by giving them a stake in the company, that probably wasn’t all bad.

It was enough. Now I’ve worked for HQY almost double the amount of time I’ve ever worked anywhere else. We’ve been through good times and bad times and great times.

When I started, there was no SDLC at HealthEquity. Stakeholders would sit next to developers and tell them how to program. Developers would push code directly to production and had admin access to the production database. We had a QA manager (in a QA department of one), and he ended up doing DevOps and release management as a full-time job because no one else was doing it, and the company assigned him the “quality issues” they were having with releases because that’s when everything broke.

Work was very ad hoc with a tendency toward waterfall. I don’t remember my actual response when I was finally allowed to contribute effort toward a production project that wasn’t a bug, I know I was ecstatic after the months in purgatory. I’m not sure if I let the “excuse me” out when my director asked me to create a comprehensive design for an entire project that looked like something that would take months to complete before I wrote a single line of code.

Of course, I tell you this to supply a baseline. HealthEquity is now one of the premiere agile shops in Utah. How did we do it? RETROSPECTIVES. Partly.

It Matters Who Buys In

The company hired a new CIO/CTO about three months after I started. Her role was to bring us to some semblance of order, so we could scale predictable teams and get the quality problem under control. I think it was her second month when we had some ridiculous number approaching TWENTY urgent production releases because each successive release to production either didn’t fix the problem we were trying to fix or they caused a cascading issue so drastic it required another urgent release.

The CIO/CTO was patient and prescribed a strict diet of agile conversion and a focus on quality. The quality staff ratio improved to one tester for every two developers in short order. A director of PMO with a strong Agile SLDC background was brought in. Our tooling and work pipelines were updated and organized. We organized into cross-functional teams of dev and qa. Then came the consultants.

To their credit, the consultants did a great job setting a baseline for what Agile should be while training us on the specific process of Scrum. The sessions were filled with retrospectives and lean coffee. I was in heaven. Yes, there were a few folks who were not pleased. Mainly those who’d been with the company for some time. They didn’t take long to self-select out to new jobs once the future of HealthEquity technology became clear. The baseline was set, and that was one of the keys.

The consultants, I think, were a critical factor. It showed everyone two things:
1. Leadership was serious about this agile thing because they were taking us away from the constant pressure to deliver more features so we could learn about it.
2. As a company and a team, we were willing to put our money where our mouth was. Hiring consultants is in no way cheap.

Is this the end? Have we achieved “AGILENESS LEVEL 5000”? No. Will we ever? Probably not. The secret true agilistas know: there is no such thing. There is only review and improve. At HQY our technology leadership (and even our CEO) understands this. We give our teams room to experiment, fail, improve, succeed wildly, and be better tomorrow than we are today.

The goal of this phase of adoption was to set the baseline with a consultancy group, create ground rules, then unleash the continuous improvement and learning. The consultants were brought back on site multiple times to iterate. Over time, folks began to catch the vision. We hired in-house agile coaches to take over the continuous improvement. These are people who could be consultants in their own right, but wanted a 9-5 at a local company. The dedication to doing nothing halfway drove home the idea that HealthEquity is in the lean-agile thing for the long term.

Why Is It Awesome?

At HealthEquity, teams work together with leadership to take action on feedback and retrospectives. At first, I remember being surprised when issues were actually addressed. I’ve never worked somewhere so responsive. In previous organizations, near revolt was sometimes required to make any meaningful change. Here, we adapt, adjust, test our assumptions, and try something new when we don’t get the result we hoped for. Again: retrospectives. But the source of our willingness to experiment and take action to improve comes from the top down. If your organization’s leadership doesn’t believe in it, and you do– maybe it’s time to start looking at better options.

Like Joseph wisely quoted when he read this “love is a battlefield”. Struggling and improving together is the point; it is the destination. Today, we are working toward a low WIP-limit team collaboration approach and building out the quality and tooling to support Continuous Delivery. Will that be the end? No. Our teams will not settle. They will continue to find ways to improve. It’s in our DNA.

Let’s Retro This Article, Shall We?

What went well:

  • My reviewers were fantastic, and the article wouldn’t be half as well written or have as many good images/memes without them (THANK YOU, Joe, Katie, Britton, Caulin, Matt.)
  • It’s always a little dicey supplying personal details in an article like this, but I think it adds some credibility and people seem to like it.
  • Writing about this helped me increase my understanding of the patterns of a successful agile rollout.

What didn’t go well:

  • The speed with which I completed the article. MONTHS.
  • I let it block other things I’ve intended to write.

What could improve:

  • It could have maybe been broken up into a couple of articles– I waffled over this a lot. So looooong.

I’d love to see your retrospective items in the comments, fair reader.  Also, why not check out my other Agile articles. See you next time.

Kata Cups: Solving Kata Problems Since 2014

First: credit for this concept goes 100% to Llewellyn Falco. I was running one of my favorite Javascript coding exercises in 2014ish at a Utah Software Craftsmanship meetup, and Llewellyn not only showed up, but he also solved the problem I was having with my presentation style.

The Problem

Who’s run a guided code kata for more than three people?

Need a definition for a guided code kata? Start here, then add the idea of one person either displaying steps to follow and/or performing the steps on a large screen in front of several people. Guided katas are commonly performed at user groups, lunch learnings, or at a local coding dojo meetup.

Back to my original question: who’s run a guided kata for more than three people?

Still reading? Then you probably relate to the problem. The problem is:  how can you tell when a reasonable percentage (or 100%) of the room is ready for the next step?

In my case, I was leading a guided kata for a room of around thirty people. Even with about half the room doing the exercise in pairs, I was spending a lot of time asking, “Who needs more time?”.

The Solution (hint: it’s kata cups)

Cut a notch in two sides of some paper cups, and ask people to put them on their laptop screens when they finish the current step of the kata. When a significant agreed upon group of folks are ready, call out “Cups down!” and move on to the next step.

Simple.

When you don’t have any cups handy, try having everyone fix a sticky note to the top of their laptop. Post-its work in a pinch, but the cups are more reliable– and fun.

The use of kata cups has spread throughout the office at work. It’s fun to see something so simple aid in the success of a lean-agile culture. So many things we do are about visibility and collaboration and finding the right solution just-in-time. Kata cups are no exception.

Legacy Code Kata v3.0

You’ve been patient. Some of you have been patient. Last week on Thursday night, I presented Legacy Dependency Kata v2.2 at the SLC .NET User Group Meetup. You’ll notice the name change since then.

But wait– don’t know what a code kata is? Start here.

I’d like to give a quick thank you to the crowd that night and the one the day before at HealthEquity during one of our Lunch Learning sessions. You all are fantastic. Thanks for the great feedback!

What’s different? Not much, to be honest. Also, in some ways, a lot. But what I realized as I was going through the slides one final time, was this: this IS a major revision. I just didn’t realize it while going through all the multiple iterative changes.

What hasn’t changed? Legacy Code Kata 3.0 is still a code kata about dealing with dependencies in legacy code and getting it ready for unit testing. It still uses the same seed code as previous versions, and you can find that here on GitHub.

Changelog

So, what makes this version so great? Let me lay it out for you:

  1. Lost the lame presentation theme. I thought I accomplished this with v2.0. NOPE. You’re welcome.
  2. The intro slides have been honed down to only those 100% essential, and they were also prettied up, and some new notes added.
  3. Added the Kata Barometer (patent pending (not actually (maybe))). At any time you always know what state your tests and build should be in.
  4. Broke up quite a few slides that were too complicated and/or the font was too small to read effectively. Much more Kata Cup friendly now. What’s a Kata Cup? Maybe in a future post. Stop changing the subject!

If you want to see for yourself why this version is so much better, check out the old versions: Version 1.0 or Version 2.0.

Here it is.

Legacy Dependency Kata v2.0

Well, well, well. Look what the samurai dragged in. An updated version of my Legacy Dependency Kata. I’ll have to update the Coding Kata Resources page.

50795_01_kurosawas-classic-seven-samurai-gets-stunning-4k-remaster

I’m not proud to admit that there even was a v1.0 at the moment. Let me explain.

Just over two years ago, I was experimenting with writing katas, presenting at code conventions, and running a coding dojo. It turns out. I wasn’t super fantastic at any of these things. Nevertheless, I wrote a kata, ran it a few times with the kind folks in my dojo, and proceeded to share it with the delightful folks at Utah Code Camp 2014. Reviews were mixed, but overall I felt good about it.

Fast forward to the present. While planning the lunchtime learning schedule for our recent SAFe Program Increment, there was an opening, and I, ever so graciously, decided to run my Legacy Dependency Kata for folks who may not have had the chance to see it before. Upon thoroughly embarrassing myself with some of the crappiest kata slides in existence (slides even I couldn’t completely fathom), I recognized that my life would be forfeit if folks were forced to do the kata again with the same slides the following day.

I dashed to revise the slides and spent many hours on the task. When I presented the kata on the second day, it was a much more successful attempt. I’d go so far as to call it a version 1.7. I spent some more time and enlisted the advice of the ever-gracious and capable Kaleb Pedersen in finalizing v2.0. The source code is still the same. Legacy code problems from 2 years ago are still very similar to what they are today.

coughnounittestabilitycough

I think the new slides do their job. Could this kata still be better? Without a doubt. Please submit your recommendations in the comments or feel free to yell at me on Twitter. I’m sure I deserve it for something.

Without further adieu, I give you Legacy Dependency Kata Version Two.

Seed code is still on GitHub:
https://github.com/KatasForLegacyCode/kCSharp/releases/tag/Step0

The Pursuit of Simplicity

Recently I read Seven Brief Lessons on Physics by Carlo Roveli. True to its title, the book is brief, and clocks in at a scant eighty-one pages. Its beauty is in the nearly poetic brevity and the expressive nature of the word choices the author (and translators) use. Unlike massive scientific tomes on particle physics I once attempted to read as a 12-year-old boy, Roveli’s book is written in a way I could have understood even as a young boy.

The book brought me a remembrance of the elasticity of young minds with its references to young physicists like Einstein, and his solving massive problems with simple solutions at a very young age. The book inspired me to write, and this is the result.

Fractal_tree_bbc

Anecdote Time

When I was a first-grade elementary school student, I recall having a tough time memorizing multiplication tables as students were taught to do at the time. Ever precocious, I wanted there to be some rhyme or reason, a pattern even, to the way we determined the values of these simple mathematical expressions. No, I was told, you just have to add the number you are multiplying by to itself the number of times the multiplier expresses.

For a young, and frankly lazy, Willy Munn, this was an annoyance at best for a number like one, two, and three; and completely unbearable for the silly number nine. You see, not being able to use a calculator or a multiplication table, and being required to show my work meant writing out nine addition problems just to “show my work” and get an acceptable grade.

My young brain started looking for a better way. It wanted to enable the laziness my heart so desired. It wanted to find a way for me to skip writing out these problems and allow me to go back to reading or playing with Lego blocks or watching the Superman movies I taped onto VHS from TV. I WANTED some rule as simple as “1 times anything is the number being multiplied” or “10 times anything is the number being multiplied with a 0 tacked onto the end”. I started to see patterns (we are talking about math after all, which is nothing without patterns). A solution for the ridiculously tedious number nine came first.

Looking at the following multiplication table, I unconsciously looked for patterns I could exploit. What patterns do you see?

1*9=9
2*9=18
3*9=27
4*9=36
5*9=45
6*9=54
7*9=63
8*9=72
9*9=81
10*9=90

I noticed the following in this approximate order:

Reversed Pairs of Numbers as Results
This was the first thing I noticed. 18 and 81, 27 and 72, and 36 and 63 all the results on opposite ends of the table form numeric palindromes. Even 09 and 90 technically work.

Everything Adds Up to Nine
Next, I realized that the first and second digit of every result always add up to 9. This seemed like something exploitable, and I saved the knowledge for later use.

First Digit Is The Number Being Multiplied By Minus One.
Eureka! I had a formula (even if I didn’t know that’s what it was called). I could take any number one through ten and subtract one from it for the first digit. Then I could subtract that number from nine to get the second digit. Simplicity itself!

I took my solution to Mrs. D, my first-grade teacher, for confirmation. I just knew she would be so happy and proud that I had found a better way to do multiplication by nines.

My youthful supposition couldn’t have been farther from the truth.

A study in human nature, being an interpretation with character analysis chart of Hoffman's master painting "Christ in the temple"; (1920)

Mrs. D. assured me that this was not the proper way to do the math and that I must write our all of my answers as she had taught. Needless to say, if young Willy Munn was a thing besides lazy, he was stubborn. I dug in my heels, so to speak. I refused to do this work stating that I would sooner die than do unnecessary work after I had found a better solution. Predictably, Mrs. D marched me right down to the principal’s office and demanded that he deal with my insubordination. She suggested corporal punishment if necessary.

The principal of my elementary school, Mr. F looked at me with kind, wise eyes, mostly gray hair, and just a quirk of a smile on the edge of his lips, and asked me to explain my method to him. I was nervous. I didn’t know what this corporal punishment was, but it sounded serious. With sweaty little palms and a mildly shaky voice, I explained my idea for the number nine. Mr. F asked some thoughtful questions and proved my hypothesis on the blackboard in his office. Then, to the joy of my young heart, he said the words I had so desired to hear from Mrs. D, “Willy, it looks like you’ve come up with a better way to solve this problem. At least for you.” Then the golden words of freedom, “Mrs. D, since this proves out, it shouldn’t be necessary for Willy to write out all of his multiplication solutions should it?” Mrs. D grudgingly agreed with her boss, although I’m fairly sure she held a cold, dark place in her heart for me for the rest of the year. In retrospect, maybe I shouldn’t have challenged her so directly, but I was 6 and thought the world revolved around me.

Mrs. D grudgingly agreed with her boss, although I’m fairly sure she held a cold, dark place in her heart for me for the rest of the year. In retrospect, I shouldn’t have challenged her the way I did, but I was six and thought the world revolved around me.

I went on to “discover” patterns for other simple multiplication problems that saved me a bit of time over the years, and even eventually memorized all the basic times tables. For several years, I got away with doing all of my math problems in my head and never showing my work. This irritated my teachers to no end and probably is what made learning manual Calculus feel like one of the most tedious tasks I’ve ever undertaken.

Many years later, while attending Southern Utah University, I learned additional math practices in my Discrete Mathematics class that used similar patterns and approaches to my early experimentation. Fun realization, that.

The Point (There Is One)

I knew, even as a youth, I had spent more time working on this solution than it would have taken just to write out the problems as I had been asked.

Today, I recognize my solution as less simple from the Mrs. D’s viewpoint. She was giving students one tried and true way of solving all multiplication problems. While it wasn’t easier for me to achieve my work, it was certainly simpler to teach. Just because there is a pattern or formula, doesn’t make a solution better based on that merit alone.

A fractal bacteria colony may BE simple once you understand it, but at first glance, it seems strange and complex.

fractal_bacteria_colony
Fractal Bacteria Colony

All anecdotes aside, the pursuit of better, simpler solutions is one that I’ve been chasing from a young age. It is the same pursuit of any scientist including the computer scientist. Let’s not forget this as we write code. Our ultimate goal should be the simpler solution because it will lead to better, more maintainable code. It will save time overall even if there is an opportunity cost up front.

We must remember that what is simpler from our particular point of view may not make sense from another’s perspective. A simple solution is only as good as our colleagues’ ability to grasp it.