Category Archives: Software Career

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.


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.

A Tech Lead Is Not A Manager: Influence vs. Authority On Agile Teams

I previously wrote about how I worked on an agile team as a tech lead. The article focused on the things I recommend. Today, I’m going to take the opposite approach and share what to avoid: the misuse of authority including mistaking an influencing role for an authoritative one.

You can read the original article here.

Roles, Roles, Roles

On agile teams, a Tech Lead is far more like a Software Architect or an Agile Coach or a Product Owner or an Engineer than a Manager, Director, or another role with people reporting directly to them. You don’t have AUTHORITY as a Tech Lead, your weapon of choice is INFLUENCE. Of course, even people with authority should rely on influence as much as they possibly can. Authority is a tool in the toolbelt of some roles, and those people must use it sparingly. Autonomy is too important to take away from creative workers (and Engineers are indeed creative).

At times authority must be used by people in what I like to call “dark side” roles. Managers, Directors, Veeps, etc. must at times use the stick instead of the carrot. Usually, this is reserved for extreme cases when a team member is refusing to follow company policy or is threatening or endangering someone. In a positive culture, these things should seldom IF EVER happen.

One of the things I love about the organization at my current company, HealthEquity, is the culture of influence. Influence is the currency of the day at all levels of leadership, and it’s used efficiently and effectively.

What Does Misuse Of Authority Look Like?

Some key things to look out for: body language, word choices, and the audience. Watch for words like these coming from your mouthhole:

But, I’m the Architect/Manager/Director/Scrum Master/Tech Lead/etc…

…you have to do this.
…this is the only option.
…because I said so.
…it’s my way or the highway.
…eat crap and die.

Absolutes and personal attacks/insults are not going to work. They may sometimes achieve the immediate effect you wanted, but it’s going to come back to bite you in the end.

Avoid negative feedback in a group setting at all costs. If you MUST provide negative feedback (and yes, sometimes we must) always, ALWAYS, do so in a private 1:1 situation. Involve your people leader if you aren’t comfortable one-on-one.

Instead, look for ways to encourage, build-up, support, and assist people in doing what you believe should be done.

Shameful Anecdote Time

Once, in an earlier decade of my life, I was an inexperienced young team lead. I had responsibility for a developer who was undertaking a critical task. The task wasn’t moving along the way my manager and my manager’s leader hoped it would. There was some time sensitivity involved, and I was asked to research the issue and get things moving along. I did some investigation and found that the developer was spending a lot of time (over 50%) not engaged in his work.

I’ll admit it; I was frustrated.

Instead of following the advice I’m giving in this article, I decided to walk right up to this person’s cubicle and ask how the work was progressing. Nothing particularly wrong with the approach, although in hindsight, I should have known the discussion was likely to become sensitive. I should have invited the developer to a private location to discuss one-on-one.

Anyway, when we spoke, the developer told me how well it was going and how hard he was working and how he’d have this already late project completed just as soon as he could, but not for at least a few more days. When describing the work remaining, I felt it was completely trivial. It could have been completed THE NEXT MORNING.

I won’t go into detail, but I lost my cool. I felt pressured and I let the pressure rule my emotions. My voice rose high enough for at least neighboring cubicles to hear, if not more. I told this developer that he would finish this work by the end of the next day or there would be hell to pay.

I’ve never seen someone’s face go from zero to pure unadulterated hatred so quickly.

The developer finished the required work on my timeline, but I had ruined a relationship and completely demotivated my co-worker. As kind, cheerful, and pleasant as I could be, it never made up for my error. The individual became a habitual underperformer, and eventually was let go by our manager.

I’ve always wondered how the situation might have gone if I knew then what I know now. Would I have pulled this individual aside privately? Would I have offered my help or another’s on the team to push through the last bit of work? Would I have asked more about the situation and sought to understand why he was underperforming in the first place?

I’d like to think I would have. I’d like to think I’d have given less weight to some of the authoritarian “truths” I’d been exposed to growing up.

Avoid False Truisms Of Authoritarians

Avoid being taken in by the truisms of autocratic leaders like Bonaparte and Hitchcock. Do not let their philosophies influence your leadership style.

“Men are moved by two levers only: fear and self-interest.” -Napoleon Bonaparte

“If an actor comes to me and wants to discuss his character, I say, ‘It’s in the script.’ If he says, ‘But what’s my motivation?’ I say, ‘Your salary.’” – Alfred Hitchcock

The work we are doing in any creative or thought-related organization requires 100% of the team’s buy-in, commitment, and enthusiasm to be as effective as possible.

Leaders don’t and can’t have all the best ideas. Create psychological safety for people you work with to aid their growth and contributions.

Authoritarian leadership styles have little or no place in Agile organizations.

In closing: I recommend avoiding the “command and control” mentality in favor of “inspire and innovate”. Tech leads (and technology leaders in general) aren’t running military operations; we are engaged in creative endeavors.

Agile Teams Don’t Always Have Tech Leads, But When They Do…

I queued this post last year when I was a Technical Lead for an outstanding scrum team at HealthEquity. The role was new for me here, although I’ve had leadership roles at several companies over the years.

A Little Background

Our team consisted of six people who had never worked together directly. We not only found a way to meet the requirements of the project, but we also did it on time, on budget, with little overtime, and quite a lot of team fun.

At any rate, the team was very successful, and its success was noticed. It resulted in considerable renown for the team. Credit where it is due: the team’s success belongs to the entire team. My role certainly wasn’t more significant than any other. If anything, it was less important.

I’ve been asked by several people how we did it. My answer, as always, is that we have an awesome team. As a contributing member, I shared some of the load. Maybe my philosophy as a tech lead within the team helped as well. I’d like to think so.

agileTeamsDontAlways

My Tech Lead Philosophy

Top Tier Things To Not Forget

  • Principle #1: Respect the opinions of everyone. We are all professionals.
  • Principle #2: Make other team members’ jobs easier.
  • Principle #3: A tech lead isn’t the only person who has great ideas.

Also Good To Remember

  • Patience. Patience. Patience. Patience. Patience. Patience.
  • Give guidance by asking questions. It isn’t always possible, but it usually is.
  • Free team members to focus on sprint work by being the first point of contact.
    • I choose to address this by sitting at the entrance to our team area.
  • Encourage team members to learn by taking tasks that challenge them.
  • Take sprint tasks that don’t interest other team members when possible.

Probably Best Not To Do This Stuff…

  • Dictating solutions and stifling creativity.
  • Taking all the fun tasks for yourself.
  • Interrupting people unnecessarily.
  • Wheaton’s Law: Don’t Be A (Jerk).

Obviously, I’m not perfect in any of these things. I do find that having the philosophy helps point me in the right direction. I hope it helps you as well. If you’d like to read more on this topic, I wrote a follow-up article in 2017 about Influence vs Authority on Agile Teams.

Interested in technical leadership and not sure where to start? Lead some coding katas for your team.

As always, hit me up on Twitter with questions or comments. Until next time.

Learn Like A Viking

My friend Ron Coulson (who I’ve known practically forever) has challenged himself to write a poem a day this year. He is well underway. This is #63 of 366, because, you know, leap year.

I’ll be the first to admit I’m no poet, but the subject matter here is near and dear to me — learning! I also enjoy a good metaphor and the Viking theme here is vivid and wonderful. Overall, it struck me as fantastic and I thought I’d like to share it with you all. Ron generously agreed. I hope you enjoy it as much as I did!

drinking-horn

Untitled

Let us devour knowledge in a way
That would make vikings cringe
Let’s gorge ourselves until we
Vomit certainties no one can dispute
Let truths drip from our chins
As the spittle of enlightenment
Lands in our opponents eyes
Raise your mugs, my friends
Then chug down life’s lessons
Until we are drunken sages
Then sleep
Then do it all again

-Ron Coulson (2016)

If these words have inspired you to learn, check out the new page I’ve added to the blog where I’m attempting to keep track of some of the best coding katas. Try one out. Let me know if you have favorite katas you’d like to see there.