A Code Camp Every Week

You’ve asked.

At least a couple of you did!

Here are the basic principles of the HealthEquity approach to lunch and learns. This article is the super abbreviated version of a 10,000-word epic I’ve been writing for ages.
Me when I realized no one wants to read a 10,000-word epic article.

Why do I care? Why should you?

Folks outside HealthEquity might consider this part of the secret sauce of our organization. Any team/company in the world could take the same approach, and we wish they would. As an industry, everyone benefits from more engaged, better-educated teams.

I don’t remember the first time I saw the following set of questions, but they are deeply ingrained in my approach to leadership. What could be worse than an entire staff of expert beginners?

“What happens if we spend time, effort, and money growing and coaching our team members and they leave the company?”

“Isn’t it worse if we don’t make those investments and our team members stay with the company forever?”

-Someone I Paraphrased

I want to build on this micro-focused concept of individuals working for a single company and expand it to the macro level. Let’s be honest with ourselves, in this world where technology people are in perpetually high demand, folks often switch jobs every few years. Initially, my goal was that folks wouldn’t leave our team, or at least when they do, their new employers would take notice and see a pattern of excellent people coming from HealthEquity. Also, I wanted folks would have fond memories and recommend us as a place for their friends to work. I realize now, this was driven by ego, and it was too narrow a scope for the vision we really need.

We need to be thinking about the success of our industry as a whole. To that end, I propose the following:

Continuous Learning Manifesto
Focus on doing what is right for our team members, companies, and customers, by looking for ways to continuously measure and improve our learning and share our findings with the world at large.

Stepping off the soapbox now…

Preaching is not the point of this article. Let me share the cool stuff we’ve been doing.

Some of my co-workers love lists, so I’ll use a list to illustrate the cycle we’ve been through.

  1. We realized we could improve and asked for feedback.
  2. We used the feedback data to create a plan to improve.
  3. We acted on the plan.
  4. We built feedback into the program.
  5. We continued to listen and act on feedback.

The short version is: we retrospected.

Here’s what we ended up with. A multi-track “lunch learning” program for seven out of every ten weeks 4 times yearly. 56 total days a year!

I’ll say it again. MULTI-TRACK SESSIONS SCHEDULED 2 DAYS A WEEK 28 WEEKS A YEAR.

You’re probably saying, “That’s crazy!” Originally, I might have agreed, but we’ve been doing this for 3 years running. We’ll kick off our 4th year this month (February 2019)!

Here’s the quick version of what we do (yeah, another list):

  1. We pay for lunch.
  2. We facilitate our educators.
  3. We retrospect individual sessions and the program as a whole.

Where we started.

In the beginning, our lunch and learns were just like yours. Sparsely attended, often complained about soapboxes for management and the elite of our organization. We had to figure out how to democratize the process.

Several members of our teams responded to our early efforts to move from “all video, book, and preach” to something new. We were doing one thing a day three days a week, and everyone was expected to attend unless they had more important work. Anyway, the feedback was this: “Why not do something where there are different options for different people who want to learn different things? Multi-track-style!” I was floored. I once helped organize a small tech conference, and it was a ton of work! There was no way to make this happen, or so I thought.

Here’s an anonymized schedule from mid-2016.

Taking things one step at a time, we surveyed for interests and found that people wanted to learn about some specific things. Then we put out the word to everyone working in tech at HealthEquity. We had plenty of volunteers! For a time, I took on scheduling rooms, building a schedule for ten weeks, running retrospectives, helping presenters, and teaching a few things here and there.

From the beginning in 2015, we also opened up Intro to Coding in C# classes to the entire company, and even managed to promote several motivated individuals into our technology group as part of the effort!

If it seems like all of this was an epic amount of effort, you’d be right. But we spread it out over time and learned as we went, so it was never too much to handle at once. Eventually, as we retrospected, we found ways to streamline. As things streamlined, we expanded outside the technology group to the entire company in 2018 including plenty of non-technology topics!

What’s next?

We’re still evolving, and now we’re creating tools to assist with our practices. I’ve intentionally left a lot of detail out because I know not everyone is interested in it. Like I said in the beginning: no one wants to read a 10,000-word epic. I’m warming to the idea of calling this concept “Lean Learning”. What do you think of that?

If you have questions or want to hear more about HealthEquity’s Lean Lunch Learning program, hit me up on LinkedIn ( https://www.linkedin.com/in/williammunn/ ) or in the comment section below. I’m more than happy to help you get a similar program started, or tell you reasons why you should work at the greatest HSA company in the world!

4 Workplace Strategies to Increase Your Mental Wellness

Hey all, Will here. I’m going to try something new and host a couple of guest posts on a topic that is often overlooked on software development teams: workplace health and wellness. The amazing Cayleigh Stickler graciously wrote these last Fall, and I’ll be sharing them with you here during the deep winter of February.

I cheated and have been following some of this advice since I got the articles. Now you can too. Enjoy!

———

Stress and work may feel like they go hand-in-hand. After all, there are project deadlines, pressures to come up with creative ideas, and collaborating with coworkers—not to mention handling customer service issues and complaints. It can feel overwhelming, but before you rethink your career choice, consider how improving your mental health will also improve your work life.

Strategy 1: Recognize the Risk Factors of Workplace Stress

It’s easy to confuse workplace pressure with workplace stress. Pressure is normal in any job. It’s what drives us to meet deadlines and perform well.

Workplace stress, on the other hand, can be debilitating and affect our physical health if left unchecked for too long.

workplace stress.jpeg

The World Health Organization (WHO) outlined several risks factors for occupational stress, such as:

  • Low levels of reward for jobs
  • Unclear direction/instructions for projects
  • Little support from managers and colleagues
  • Lack of control in projects
  • Performing tasks that aren’t matched with skills

The key in this is communication with your superiors and colleagues. It can take practice asking for what you need, so start small. Take one thing that’s stressing you out and start there. Once you become comfortable stating your needs, you can speak up more often before it becomes a problem.

Strategy 2: Go the Distance

Remember when the mantra was to get at least thirty minutes of exercise a day to stay healthy? That’s now being shown it isn’t the whole story. Those of us who have sedentary jobs are still at an increased risk of premature death and other health complications like heart disease—even if we exercise regularly.

Instead of throwing in the towel and skipping the gym altogether, find ways throughout the work day to stand up and move around. Setting small breaks throughout the day, in combination with regular physical exercise, can be enough to counteract the fact we need to sit down for long periods of time.

Every hour, you should get up at least once for five minutes. This will not only help your physical health, but it’ll help you refocus and give your brain a break for a few minutes so you can come back to your task with a fresh mind.

coffee work.jpg

Here are some ways you can get up to move around:

  • Send your print jobs to a printer further from your desk
  • Take a water or coffee break—and stand while you’re drinking
  • Talk to a colleague face-to-face instead of sending an email
  • Take a lap around the office

Some of these techniques work in multiple ways. If you walk to talk to a colleague in person, you’re not only forced to get up, but you’re strengthening an interpersonal connection.

Strategy 3: Start Small and Build Up

Wellness is a choice, but it also comes from the types of habits we choose. Habits are ingrained in us, so you might not know what types of work habits you have until you sit down and take an inventory.

notepad notes.jpeg

For the next week, keep a notepad and pen next to you and jot down what you do throughout the day and when you do it. After the week is finished, evaluate and find any common patterns. Find the stuff you want to change (like checking your email a hundred times in an eight-hour work day), but also find the stuff you want to keep doing.

Here are more ways starting small habits to make large changes can work for you:

  • Create a routine and choose which habits would be best for the morning, afternoon, and before you leave for the day
  • Choose tiny habits that challenge you and make you happy
  • Be intentional about your new habits by habit stacking—linking your new habit to an existing habit, such as drinking your morning coffee

When you feel more in control of your day and the flow of your work zone, you’ll feel more empowered and confident.

Strategy 4: Take an Inventory of Your Sensory Input

Sometimes there really is just too much on our plates, and we have to power through. If you can’t manage a five-minute break to release some stress, here’s a thirty-second technique that helps bring you back to the present and out of your spinning mind.

meditate.jpg

It’s called grounding. Simply take a deep breath and inventory of all the sensory input you’re currently receiving, then work on decreasing the stress in your body. The stress in your mind will follow, and you’ll have a clearer focus on your task.

  • Touch: How does your back feel against your chair? Your fingers on the keys? Your feet on the floor?

  • Sound: What noises do you hear? Click-clacking of keys? Laughter from the break room? Whispers in a neighboring cubicle? Your racing heartbeat?

  • Sight: What do you see? Your computer? Cluttered notes on your desk? Motivational Post-It note or poster on your wall?

  • Smell: What do you smell? Burning popcorn? Coffee? Someone’s tuna sandwich from lunch?

  • Taste: What do you taste? Mint from a stick of gum? Lingering aftertaste of coffee? Do you have dry mouth and need a drink of water?

The goal is to jump off the hamster wheel in our mind and come to the present moment. Mindfulness practices like this one are good anytime, but they’re especially effective when you’re stressed. If you make mindfulness one of your new habits, you’ll be able to reach for this tool when you need it the most.

Working on mental health shouldn’t be something you do when you’re already at the edge. It’s something that can and should be worked on every day. At work, we might not have time to do an hour-long yoga routine, but there are strategies we can take advantage of to help keep us clear-headed, motivated, and confident in ourselves and our work.

What are some strategies you use to increase your mental wellness throughout the day?

—–

Cayleigh Stickler is a single mom of two toddlers who wears many hats as a content marketer, fiction editor, and mountain adventurer. She loves using her psychology degree and passion for holistic wellness to inspire and help people define what healthy means to them. When she isn’t wrangling her two toddlers, she is available for writing services.

Why Should You Prepare Lightning Talks and Wildfire Talks?

I can hear you now: “Isn’t it sufficient to have talks? Why define special types?”

“Why prepare ANY talk?”

“Ugh!”

Well, I’ll tell you, but first a touch of background.

It was probably five years ago when I discovered the concept of a Lightning Talk during a Utah Software Craftsmanship meetup. Some research tells me the idea has been around in some form or another since 1997 (Wikipedia).  I think Lightning Talks are great for a variety of reasons, but they don’t fit every situation.

During a retrospective of a couple of different Lightning Talk sessions we held at HealthEquity, feedback came up that some of the topics could have used expanded time and attention. We came up with a concept that, while also not new, we dubbed Wildfire Talks. Wildfire Talks are equivalent to a TED Talk in many ways. They deliver a short, poignant message and should meet the same criteria of a TED Talk, but aren’t branded and are usually only given in person.

You may have guessed, one of our goals in technology at HealthEquity is to develop leaders. We consider our senior individual contributors to be leaders in their own right. Public speaking and the art of persuasion is part of the gig in leadership, so we use these types of talks as an easy entry point to help folks learn.

Lightning Talks

If you aren’t familiar with Lightning Talks, they normally aren’t planned and scheduled. They are five-minute talks, and they are sometimes added to an existing meeting or meetup. I’ve also facilitated sessions composed entirely of Lightning Talks.

In both cases, every presenter for the session is already a member of the audience/meeting.

How does the audience benefit? I’m glad you asked! The format lends itself nicely to helping folks get exposure to a wide variety of interesting information in a quick format themed around a shared interest.

What I love most about Lightning Talks is the no-pressure approach to introducing people to public speaking. For someone who is nervous, five minutes is often long enough for the jitters to subside. They are also informal, so presenters can experiment with presentation techniques and find the methods they prefer.

The facilitator can smooth the way for Lightning Talks during your gathering.

To begin, set expectations for the audience by announcing you will open the floor up in increments of 5 minutes.

Audience Requirements for Lightning Talks

  1. Volunteer to speak.
  2. Applaud after every talk.

Folks volunteer (an important distinction for Lightning Talks) to talk about something within the bounds of a guiding statement the facilitator provides. An example guiding statement could be: “All talks should be related to new developments in technology released in the past ten years”. With the above guiding statement, talks could be about 3D Printing, Internet of Things, your favorite development tool, a cool new piece of hardware, how Bitcoin works, a new programming language, etc.

Presenter Requirements for Lightning Talks

  1. Introduce yourself.
  2. Stay on topic within the guiding statement.
  3. Slides/screen sharing is optional (and should only be used as punctuation).
  4. Gracefully end after 5 minutes including Q&A (signaled by the facilitator).

Optional

You can ask for audience ratings/comments (stickie notes work well for this) for presenters who would like them. It’s an excellent opportunity to get some feedback for those who want it, but don’t collect the data if the presenter isn’t interested.

 

TRANSITION

Wildfire Talks (or TED Talks)

Wildfire Talks are the evolutionary step from Lightning Talks toward a full 45-55 minute talk. In contrast to what we sometimes see from longer form talks, the intent is really to make one point and make it well.

A good rule of thumb is to follow the advice of Talk Like TED by Carmine Gallo: focus on delivering something emotional, novel, and memorable wrapped in a clear beginning and end.

Unlike with Lightning Talks, Wildfire Talk presenters are asked to speak in advance. Each talk is approximately fifteen minutes, and although some people can get up and wing it for that amount of time, they would often be even better with a little preparation. When a facilitator selects Wildfire Talk presenters, they will want to choose people who’ve already mastered the Lightning Talk format.

Wildfire Talks can add detail and are often a more useful tool to convince people to consider something they might have been on the fence about before. Slides and screen sharing remain optional, but if you do use them, make sure their purpose is to give the presentation pop and drama, not as a checklist of things to present.

As a facilitator, if you are organizing a series of Wildfire Talks, consider narrowing the focus more than you would for a session of Lightning Talks. In four fifteen-minute sessions, you could have talks about:

  1. .NET is the Premier Open Source Framework
  2. Why are Some Development Shops Switching to F#
  3. Best New Features of C#
  4. Strategies for Writing Threadsafe Modern OOP Code in .NET.

Presenter Requirements for Wildfire Talks

  1. Introduce yourself including your qualifications to speak on the topic you’ve chosen.
  2. Stick to the single topic, don’t stray off course.
  3. Keep slides minimal and relevant.
  4. Stick to the 15-minute timeframe. The facilitator will keep time and give notice.
  5. Say what you’re going to say, say it, and say what you said (summarize, explain, summarize).

The audience must clap (they’ll want to).

I hope this is helpful. Five years ago, I wouldn’t have been able to guess what a Lightning Talk was if you’d asked me. After giving a few of them, I had more experience in front of technical crowds and was able to see some patterns in my presentation style that worked well (and some that didn’t).

The Wildfire Talk concept was born of retrospective feedback after I facilitated an hour-long session of Lightning Talks at HealthEquity. I believe the benefit here, is focused learning for both the audience and the presenter. It still isn’t a huge time commitment, but the presenter can focus on getting better at delivery of content, and the audience gets the additional info they craved after a lightning talk on the same topic.

I hope you’ll take the opportunity to practice presenting.  Public speaking has been called one of the biggest fears of humankind. Take the small steps of learning to present Lightning Talks and Wildfire Talks, and you’ll gain competence much faster than you think.

Now. Keep your best talks on standby so you can trot them out the next time someone asks for speaking volunteers. You’ll be glad you did. You’ll spread learning about a topic you believe in. You leader, you.


Unit Test When? Why?

The topic of when to unit test came up in a recent discussion with some people who are smarter than me. I’d just finished listening to a great presentation on Software Gardening. I hadn’t considered the option of Test First as I’ll describe it below. I’m not promoting the concept, but I thought it was interesting. Also, I’ve done what I’m calling Test Now, but I’ve never really heard it referred to as anything but another breed of Test After. The distinction is meaningful, and I think it deserves to be called out. I’m going to go out on a limb and make the assumption that you understand the importance of unit testing if you are reading this.

Why have this discussion? Because we want to be lean and do the minimal amount of large-scale rework. Also, because we want to understand the benefits and downfalls of each approach. In theory, there will be “best” options for a given set of circumstances. Let’s see what happens.

The Test When Continuum

I’m introducing the Test When Continuum as a way to help explain the commonalities and differences of these various test practices. The way I’m considering them is by the absolute amount of time between writing unit test code and production code.

Assuming we have a story or feature with 10 testable units taking one unit of time to complete each, we get the following dataset.

Given the assumption that testing beforehand is always best, and the data above, our test continuum looks like this:

Test First

First off, I misspoke when I said I’ve never heard of this approach. It was proposed by the software architect team at one of my workplaces in the hazy days of the distant past. I just hadn’t heard it called Test First Development, or if I did– I blocked it out. At any rate, in this particular gig, there was a lot of top-down design (or there was meant to be). The proposal was, if the architects wrote unit tests for their platform features up front, developers could just code monkey up and make those tests pass.

I was still learning at the time, and the idea seemed intriguing, if slightly wrong, and I couldn’t figure out why. For whatever reason, my Spidey-sense was tingling. I chose to ignore it, and as it happened, the architects didn’t have the time or discipline to take this approach either. So no harm was done.

Looking back, I’m sure my feeble brain was trying to tell me a few things:

  1. Throwing design over the fence with a set of requirements creates pretty much every problem we see in waterfall-type project management of software. Stage gates, anyone?
  2. Even if the developers had taken requirements and written every test possible, the approach
    • Doesn’t allow any flexibility in design when discovery happens mid-development
    • Creates a false imperative to stick with the original design no matter the cost
  3. There had to be a better way.

Consider your tests as eggs and the code as the critters inside the eggs, and I’ll drop some amazing English idiom on you.

Test Driven

Commonly referred to, by me at least, as the Holy Grail of testing. It solves all of the problems above. Does this mean the world should just give up every other type of development and convert to TDD (yep, this is just a link to the Wikipedia article on TDD)? Under the right circumstances, maybe!

I’ll say this: the test-driven approach leads to the best and most solid code I’ve seen in most cases. If you are doing Object-Oriented Programming (not your second semester college professor’s OOP, but modern OOP favoring SOLID, composition over inheritance, minimal state, and immutability), and you follow Red/Green/Refactor creating the simplest tests and bits of code to make them pass, then you refactor responsibly with the guidance of a skilled coder, you’re probably going to produce SOLID and clean code. There are additional benefits like semantic stability I won’t get into in detail.

Test Driven works well in most general cases as long as you are operating in a greenfield/new code environment.

Test Now

What’s this? Another made up name. I’m on a roll today with the Test When Continuum and Test Now. I must be a writer to make up so much garbage.

I feel like any kind of testing done after a material code change is always referred to as “Test After”. Let’s change this because there are varying strengths and weaknesses in the approaches.

The idea of Test Now is that after we complete a small, testable unit of code, we immediately write a test and make it pass. Then we look for opportunities to refactor our code and tests. Simple. Very similar to TDD, but perhaps with a couple of benefits under certain circumstances:

  1. You’re working with people unfamiliar/uncomfortable with TDD and they are driving.
  2. Your environment is exceedingly brownfield or “legacy” (existing code without tests and hard to test).
    • I know what you’re gonna say: “Just read Working Effectively With Legacy Code by Michael Feathers and all of your problems will be solved!” (Fantastic book by the way.)
    • The problem is, getting good at TDD takes time, practice, and diligence under the best of circumstances. Now we’re going to add learning how to effectively test legacy code to the workload at the same time. It’s a difficult thing to ask. The skills are important, and prioritizing what is most important can be difficult. I can’t tell you what would be best for your team.
  3. Your organization has just bought into the idea of Test After, and you want to move a step in the right direction.

Test Now gives quite a few of the benefits of Test Driven and is a nice place to stay for a while, but stick with those TDD katas. Keep practicing. Learn from Michael Feathers. In the meantime, Test Now is the second “Lean”est approach on our Test When Continuum.

Test After

Similar Test First in more ways than one, I’ll use another egg idiom to make the point. Testing after a feature or story is complete results in an “all your eggs in the same basket” scenario. Untested production code is fragile. All it takes is a couple of false assumptions. Maybe a sub-optimal design choice. Next, your tests are revealing the need for a systematic overhaul of the feature or story. At best, you hobble along and put tech debt stories in the backlog to fix it up later. Hopefully, you have time to get to them.

Conclusion

If you hadn’t guessed, I favor testing as close as possible completing increments of code. Before the code is written when possible– and after when it makes sense. General benefits are flexibility and usually better design.

My gratitude to Ben Davidson, Craig Berntson, Kaleb Pederson, and Dwayne Pryce for their eyes and time reviewing this article!

Here’s an updated Test When Continuum:

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: The Surprising Truth About What Motivates Us). 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.