Feedback Please (but really, go away)

Yes, it’s the end of 2016 and forms like this really do exist.

What’s your take — do they want my feedback or not? The size of the buttons are telling, I think.

That, and the absence of an attachment option. I mean, describing technical issues is always better in text than with a screenshot, right?

Recruiters – Get Agile!

sleepy-dog800

Above: Me after reading your exhausting list of job requirements.

Please. Enough of the the laundry list taken from the practice manual. These copy-and-paste job req’s are enough to make me ill. Wait, is that part of the test? Are you proving that I can stave off sleep long enough to read all 60 bullets and respond to your boilerplate ad?

KNOWLEDGE vs. SYNTAX

Look. The people you really want on your team are not spending their days memorizing the “numerous well documented patterns and techniques for filling in the intentional gaps left in the Scrum approach.”

That’s syntax. That’s like advertising for a programmer and saying, “familiar with many clever ways of creating a conditional loop.”

Agilists reach for tools and techniques when we need them – as the need arises. The whole idea of “maximizing the amount of work not done” is that you don’t waste time doing things you don’t need yet. That includes memorizing pages from a book just so you can impress an HR screener.

My copy of Agile Retrospectives lists eight ways to gather information. Do you think there are less than eight more available with a quick Google search? Your “patterns and techniques” bullet might was well say, “Working knowledge of Internet search engines.”

LONGEVITY vs. EFFECTIVENESS

Does your requirement of “at least two years” in the role really tell you anything? Wouldn’t you like to know if those two years were effective?

Why not skip that one and use this in the interview:

“Describe some of your favorite Retrospectives. What activities did your team enjoy and what experiments came out of them?”

If I crushed that question in an interview, would it matter that I had 6 months or 6 years of experience? Maybe I’m the kind of person who has run a tight continuous feedback loop for the last year and my team experiments resulted in a huge productivity boost, or reduced team churn, or created a leap in trust and transparency. On the other hand, maybe I’ve only led one Retrospective in the last year and it bombed. Your “two years” criteria tells you nothing about my effectiveness. Only about my ability to stay hired.

GET AGILE

How about this: Maximize the amount of bullets not fired so we can all get to the interview stage. Start thinking like an agilist instead of someone writing a Scrum book.

Think MVP: What are the minimum skills we need in this position? How would we prove that the candidate has them so we can get someone good instead of someone who can cram well before a test?

Conduct a job requirements Retrospective. What is the quality of the product (candidate) I’m shipping (hiring) as a result of the material presented?

Maybe you find yourself in Mark Twain’s situation:

“I didn’t have time to write a short letter, so I wrote a long one instead.”

I get it. We’re all busy. As I’m writing this, I’m choosing to delay the six things on my written to-do list.

But let’s not bullshit each other. We prioritize every day. We do what we think is important and defer the rest.

We also make judgments about others based on the effort we perceive from them. We regularly judge a product or service company by the responsiveness (or lack of) in their sales department. First impressions matter.

THE QUESTION

If your company can’t find the time to write a creative, enticing job description… why would we as candidates assume that you’ve taken the time to do other important things like articulate your mission, define a good strategy, staff appropriate to the demand, or create a healthy culture?

Photo credit: Kerry Lannert 

Stalled Stories

When I arrived at a startup software division, the story-writing process was virtually stalled. A young woman with a strong personality and backed by the authority of her executive father was vying for control with the more experienced Pharmacy Technician that was charged with supplying User Stories to the development team. The female tech, acting in the Product Owner role, liked the younger woman and even considered herself the junior’s mentor, but the tug-of-war against the stronger personality impeded progress.

As someone with significant project scar tissue, I was inserted as Sr. Business Analyst and was able to help them break the logjam. To the younger woman, I became the keeper of the product backlog and her story reviewer. She could submit detailed written stories of interest that I could include in the product backlog. To the more experienced tech, I became a sounding board for her more verbal approach to story writing. She wanted a partner to bounce ideas off of and someone to validate her own thinking before submitting a story in writing.

What made me effective in a situation where two others were stalled? I respected and agreed with both of them and refused to lock horns with either party. Instead, I offered gentle suggestions here and there, allowing each of them to write stories from their own perspective. I have learned that it is much easier to say ‘yes’ to feature requests than argue about them up front. Customers have limited budgets and limited time. In the end, it is these larger constraints that determine which features get included in a product. The most valuable features tend to bubble up in the list of priorities and get worked on. The least valuable often sink down and fade into oblivion. After all, a product backlog does not have to be empty when the project is done.