Thursday, October 01, 2015

Keynoting at ISTACon in November

I’m honored to announce I’m going to be keynoting at the ISTA Conference in Sofia, Bulgaria 18-19 November! This is exciting for me on a number of levels.

enter image description here

First, it’s my first-ever keynote, which is pretty exciting. I’ve never spoken to more than ~150 attendees, so being up front before 700-800 will be a new experience!

Second, I get to return to Sofia, Bulgaria, which is one of my favorite cities in the world. I had extraordinary experiences there when I worked for Telerik, and I’m looking forward to being back there.

ISTA’s organizers were kind enough to let me go a bit astray from “normal” keynotes. Instead of an hour talk I’ll be doing a much shorter session on the lines of a KalamazooX talk. My topic is “Why?” and I’m hoping to fire up attendees to ask “Why?” more often as we work to deliver value to our customers.

I’ll also be presenting my Leadership 101 workshop. This workshop’s from the heart, so it’s always a rewarding but exhausting experience.

ISTA’s registration is already open. I hope folks in the region will be interested enough to attend—it’s a great conference with a lot to offer! If you can’t attend please at least share the info to your friends, colleagues, and community members.

Please look me up onsite if you’re going to attend!

Thursday, September 03, 2015

Don't Ignore Big Deltas in Your Teams' Estimates

Estimates suck. They’re always wrong, and of course estimates somehow end up getting treated as exactimates, or worse yet, commitments.

enter image description here

I’m not here to tell you how to do estimates, or how to follow the #NoEstimates movement and not do estimates at all.

What I am here to do (well, in this article at least), is tell you to pay attention when you have wide estimate ranges within your team. It’s a situation that isn’t just an indicator of a skills gap. It’s a warning flag that maybe you’re missing something. (It’s also a great learning opportunity!) Regardless whether the range in estimates comes from junior to senior, or between similarly experienced folks, take some time to dive down into a conversation about the delta.

What’s causing the big disconnect? Is it indeed a skills/experience gap? Do the junior team members misunderstand the complexities involved? Take a few minutes and have someone more senior walk them through things—and make sure they get an understanding of what’s involved in this particular work item.

This quick learning moment doesn’t have to extend out to a huge training/knowledge sharing session. Keep it tight and focused; after all, the primary purpose is to get the estimating done. If needed, take the conversation offline so it doesn’t derail whatever meeting you’re in at the moment.

An even more interesting situation is when you have people with similar experience differing widely on work. Don’t simply take averages of the estimates and move on. Take time to explore what’s the rationale behind the extreme delta. In this case, you do want to spend as much time’s needed to clarify the delta.

Is the delta due to a lack of clarity around the work item? Spend more time getting the details around acceptance criteria, documentation, whatever’s necessary to ensure everyone’s on the same page.

Is the delta due to a disconnect in complexity of the work? If needed, whiteboard out workflows, data structures, dependencies, etc. until everyone’s got roughly the same idea of complexity involved.

Is the delta due to misunderstanding of the amount of testing involved? If so, move along, BECAUSE THAT NEVER HAPPENS. Hah. Of course it happens! This situation needs time to rectify, because the team has to make sure testing aligns with the information the business/product owner/customer needs to make effective risk/benefit decisions. Are the testers over-focusing on edge cases that don’t directly apply to highest priority risk/values? This can be a regular issue with less mature testers. Is the team missing critical integrations or dependencies that might impact how much testing is really needed? What about coverage matrices for things like browsers, devices, operating systems, etc.?

Work through the testing requirements, but ensure you’re focusing on what the business needs from you. Remember: The testers don’t assure quality, nor does the delivery team, frankly. The business/product owner/customer is the only one who can do that. The team is responsible to pass along the right information to help those people make informed decisions.

Got big estimate deltas? Make sure you’re using that as a trigger for further discussion!

How have you approached handling big deltas in your teams’ estimates? Let me know in the comments!

Wednesday, August 26, 2015

Sorry, I Can't Talk to You This Iteration

No, seriously, I actually heard that on a project once upon a time.

The client’s team had gotten far too focused on capacity and lost sight of delivery. Management wanted more stuff faster, so they focused on full utilization and commitment. As a result they were in a place where time for collaboration, knowledge transfer, and you know, teamwork had to be scheduled. Management had clearly lost sight that 100% utilization means no slack for conversations. They’d missed the problem that 100% utilization turns freeways—and software teams—into parking lots.

Intended or not, teams and individuals on the project ran with that mindset to an extreme. Collaboration and cross-team assistance fell off drastically, as did the sense of a shared goal: working software delivered to the customers.

Such an emphasis on capacity and commitment isn’t healthy. I’ll go so far to say it’s a cancer. Regardless whether you’re “agile” (whatever that means), waterfall, or something else, you must leave slack time in your schedule. Without slack you’ll never get your teams working on the most important aspect of any software methodology: continual improvement and adaptation.

Healing up this mindset and culture isn’t easy. It’s an issue with management’s pressure and unreasonable expectations. That can be a result of a lack of skills with the delivery teams’ ability to ship; however, honest change needs time for that change.

Generally management is open to discussions around impacts to delivery or business value. Remember, misguided as the decisions might be, they’re an attempt to meet deliverables and ship software. Frame your case in that context and you might have some luck.

Start gathering hard data around situations like:

  1. Work items blocked by inability to get time for discussions. Can’t get time with Team <X> to discuss the API work item you’re on right now? Note that and consolidate with other data.
  2. Work items slipping past the iteration. Are those blockages from #0 bad enough that you can’t finish your work? Make sure the reason behind it is clear to people up the chain.
  3. Lack of knowledge transfer. Shared codebases are critical, even on large projects. Can’t get time to understand critical aspects of what you’re working on? Document, escalate.

Make sure you’re approaching this from a positive, not negative, direction. Don’t even get out of bed if you’re planning on a “This is stupid and everyone sucks!” pitch. Instead, frame it as “Look, this is costing us <X> hours, <Y> blocked user stories, and <Z> <fill_in_blank/>.”

Additionally, come to the table with a suggested approach for fixing it. “Look, can we reserve some slack time each iteration for more ad-hoc discussions? Having some honest time for collaboration will help us prevent the <X> hours lost, <Y> blocked stories, and <Y><fill_in_blank/> we’ve seen the last couple iterations.”

Every team’s primary focus should be working software in production. Blocks to effective communication and collaboration are a direct impediment to that. Work to cure that cancer!

Tuesday, May 05, 2015

So Long Heartland

Back in the summer of 2001 my family (just three, back then) moved to Beavercreek, Ohio. For those of you who are, like me, math-challenged that’s 14 years. We’d moved here for my wife’s final assignment during her 20 years of service in the USAF.

At the time I was working as a customer relations manager for a small Department of Defense contactor engaged on a long-running program run out of Wright Patterson AFB. I was handling customer conversations and some project management, plus I was doing “testing” for the system we were developing.

enter image description here

Over those 14 years my family grew to four, we put 45 cubic yards of dirt in for flower beds, well over 100 cubic yards of mulch, we added on an 800 ft2 addition for my Mother-in-Law (hold the jokes. She’s awesome.), 1500 ft2 of laminate flooring, and 80 gallons of paint. Unlike other situations, those are accurate figures, not me exaggerating!

Also along the way I managed to hook up with the amazing Heartland’s amazing developer community. Yes, I know, I wrote amazing twice. It’s that amazing.

I was lucky enough to get engaged with the community here at a really interesting timeframe. In 2005 there weren’t any conferences being in the Heartland other than the occasional commercial thing like No Fluff Just Stuff. What was here was a nascent, primordial bubbling goo formed by some really smart, motivated folks who wanted to reach out to other like-minded folks.

I was fortunate to hook up with people like Drew Robbins, James Avery, Brian Prince, Josh Holmes, Mike Wood, and others who were starting to get various conferences off the ground. (I’m missing lots of people off that list. Sorry.) That group exploded out and created an incredible number of community events.

By 2008 you could, literally, hit a one-day conference at least once a month if you wanted to. Days of .NET, Code Camps, Give Camps, Days of Agile, and others had sprung up from Grand Rapids down through Nashville. Larger conferences like DevLink, StirTrek, KalamazooX, and of course CodeMash took off over the following years. User groups were springing up all over the place.

Fast forward to 2015: the pace of Code Camps, Days of .NET, etc. has died down a bit, but larger regional conferences like StirTrek, CodeMash, etc. have exploded. User groups have gone the way of tribbles and have spun off into an insane amount of local meetups, user groups, hangouts, whatever. I stopped trying to keep track years ago.

Heartland’s community is full of smart, passionate, welcoming folks who opened their arms, brains, and hearts to those interested in improving their various crafts, skillsets, and general outlook. These folks helped get me motivated to get out of the soul-crushing work I was involved with at the time. I trace a line from the awesome job I’m currently doing directly back to influences, motivations, and friendships I developed amongst Heartlanders over the years.

I can also point to at least three jobs I got directly because of my involvement with the Heartland community. I once got a job offer from a Heartland homie three or four days after I reached out. When I hung my shingle out earlier this year I had seven leads on independent contracts, five writing leads, and four job interviews—within four days.

Folks in this region are simply amazing. I’ve been blessed to have spent so many years here.

With all that said, it’s time for me and my family to bid adieu to the Heartland. My wife and I’ve always known Dayton wasn’t even close to our “forever home.” No mountains and too far from my family.

On 9 May my son, brother-in-law, and I load up a 27’ UHaul truck and minivan and head west for Ashland, Oregon. With two cats and two dogs in the minivan. Please send your prayers for what little is left of my sanity. The rest of my family will follow in stages, but we’ll be settled in our new home in early June.

I can’t list out all the people I really need to thank. There are hundreds of you, maybe even thousands. Literally. Those of you who’ve suffered through assorted tech crashes during my talks, those of you who’ve patiently listened to various rants, those of you who’ve made CodeMash so awesome, those of you who’ve lent me energy and strength at various dark phases of my life.

If you’re ever out in southern Oregon, please drop me a note either via mail ( or Twitter (@aJimHolmes). I’d love to meet up for a coffee, craft beer, or good glass of PNW vino.

To all I’ve met over the years: Thank you all. You’ve given me far more than I gave.

Monday, April 06, 2015

Visual Resume Template

Some time ago I posted about my visual resume. I think visual resumes are a great way to show off things you’re proud of in your career, so I started passing mine around together with my traditional resume.
Jim Holmes Visual Resume
More recently, someone asked if I’d put my resume out as a template, so I did! It’s a Visio file, and you can find it here on GitHub. I released it under Creative Commons CC0 which means, I think, you’re fine to do whatever you want with it.
Just don’t plagarize my stuff as your stuff. Other than that, I wish you well!

Wednesday, March 18, 2015

Changing Cucumber Fonts in Eclipse Editor

Problem: You’re writing Gherkin in Eclipse and you can’t figure out how to adjust font size in your Feature editor.

Solution: It’s actually in the Basic text editor. Window -> Preferences -> Appearance -> Colors and Fonts -> Select “Basic” folder in panel -> Text Font -> Edit.

Bonus: Make sure you’re using the Eclipse theme color plugin plus the Cucumber for Eclipse plugin.

Tuesday, March 17, 2015

Three Months with the Surface 3 Pro

I’ve had a Surface 3 Pro now for three months, and I thought I’d share my experiences with it for those interested.

TL;DR version: I hate it BUT I have some very specific use cases I bought it for—and it fails horribly at those. I know others who love their S3s, and there are a few things I do like about the system.

First off: My needs

I bought the Surface to handle loads of content production, authoring, and training when I figured I was heading out as an indie. I didn’t feel I needed a high-horsepower dev system, as that’s not my area.

Specifically, I needed a system that kicked butt at:

  • Running smaller-sized VMs
  • Video production
  • Writing
  • Portability
  • Light dev work

I purchased a top-of-the-line i7 Surface 3 Pro with 8GB RAM and the 256 GB SSD. I also sprang for a docking station and a few other odds and ends. Total cost was somewhere around $2,200 I think. (I’m on the road and away from my receipts…)

The Good

There are some things I really enjoy about the S3:

  • Form factor. Small, very lightweight.
  • Keyboard. Except for the trackpad (see below), I like the keyboard. I take my MS Ergonomic full-sized board along if I’m doing workshops or sessions where I have to code, but for general authoring and every day usage the keyboard/cover works really well. Great feel, good responsiveness.
  • Docking / undocking ease. Holy crap. I’ve suffered through decades of Microsoft’s crappy docking mess. The Surface 3 plus Win8.1 makes it a snap, literally. It’s a joy to not have to deal with the drama from way back.
  • Stylus. Freaking. Awesome. Great feel, extremely precise, great use of buttons on the pen. Kills anything I’ve used on the iPad. Did I mention it’s awesome?
  • FreshPaint. I badly missed Paper on my iPad. I fell in love with it for doing craay craay slides for demos and presentations. FreshPaint is nearly as good, although there are several icons/buttons that are a total mystery to me. The help for FreshPaint is non-existent, apparently.

The Bad

Here’s where the wheels fall off. Completely.

  • VM perf over USB3 is unusable. I lose horrific amounts of time trying to run VMs off an external USB3 drive—the same model I’ve had on other systems. It’s horrible. It’s unusable. Which means some of my demos requiring multiple VMs turn into a complete cluster fill-in-the-blank. I had better performance on Firewire 800 on an older MBP.
  • Power management. I hope the crew that designed power management on the Surface 3 gets infested with bedbugs and fire ants. The power management options are stupid, such that:

    • I can’t tell the system to stay awake while on battery, but turn on the screen saver. Utter fail when I need to leave the system on for long-running renders and uploads.
    • Hook up the S3 to my Bluetooth speaker, start music playing, system shuts down and goes to sleep at the hibernate timeout period. Apparently that timeout doesn’t monitor background system activity. Sigh.
    • Battery life is pathetic, even when I’m not running anything. Apparently there are a bunch of registry hacks and deep system tweaks I can do, but WTF? Seriously? Yes, I know, I’m holding it wrong.
  • The screen driver is tetchy and causes issues when I’m working in VMs. It also won’t let me properly use Telerik Test Studio on the native S3.

  • Sound output managment. Every time I plug in headphones I have to reconfigure the default playback device to play over my headphones. Same if I want to use an external Bluetooth speaker W.T.F?!? Crazy usability #EPICFAIL with much profanity.
  • My device died a horrible death a month after I bought it. Best Buy Geek Squad guy wrote “BIOS screwed up” on the RMA. BTW, this is the second Surface 3 we’ve had die. My wife’s bricked a couple months after we bought hers.
  • Wifi and bluetooth are tetchy. Dropped connections are far too frequent.
  • Touch screen experience inconsistent. Sometimes I click a finger into a field and it won’t recognize that I want to type.
  • Weird stuff when rotating (keyboard disabled, touchscreen weird)
  • Apps (other than FreshPaint) are meh

Do keep in mind my very specific use case. I know other folks who love their Surfaces. Good for them, and frankly I see some good use from this when watching Netflix or reading while on the road.

That said, for ME this is worst tech purchase ever. Over $2,200 with docking station and extras. Wish I’d gone with a completely different platform. :-/

Subscribe (RSS)

The Leadership Journey