Monday, June 22, 2015

Insincerity and Process

I read a lot of disappointed tweets, reddit posts, etc about agile development processes, especially since the whole Take Back Agile thing started.

There is an honest perception that all of agile development is disingenuous, deceptive, insincere.

I build my own perceptions on my own history and observations, too. I have to be reminded that we all experience life differently. As a consultant, I have seen all the dysfunctions that others have seen, but I have also seen agile projects done well.

When I talk about the joys of TDD , it conflicts strongly with others' experience of forcing test coverage numbers.

When I talk about pair programming and mob programming, it conflicts strongly with their experience of freeloading peers or "in cubicle-audits."

When I talk about BDD, it conflicts with their experience of tail-end test automation.

When I talk about using Big Visible Charts to aid focus, it conflicts with their experiences of managers using charts to embarrass, blame, or otherwise coerce people to work harder.

When I talk about self-organizing, it conflicts with their experiences of people dodging responsibility, of managers assigning tasks, and frequently of the dubious practice of ranking developers.

Having experienced heavily Tayloristic "faux agile" processes that clearly contradict the principles of the agile doctrine(s), they see the entire Agile Manifesto as a tissue of lies -- a con game used to trick developers into accepting a process that does not favor or benefit them. It looks like a lie.

It seems that lousy fake-agile processes are an effective inoculation against real agile.

Neither the naysayers nor the pundits I know are being dishonest. We are just talking past each other because our experiences are different.

Most people (managers and developers alike) need one good experience of "real agile" with openness and transparency and the safety it provides, and they'll change their mind about the whole game.

Barring that one good experience, Agile will continue to be the word that represents the oppressive, dystopian experience they've had so far and all the pro-human statements of the manifesto will be nothing more than bait-and-switch advertising.

I'm sorry that it's come to that. How can I help?

Tuesday, June 16, 2015

Male Privilege

The part of male privilege I enjoy is the part where people don't act like that it's my job to be "hawt" and fit and styled to visually conform to current "universal" standard of physical hotness.

I can be quirky and paunchy and wear comfortable clothes and nobody throws a fit or calls me names. I can have a tooth gap and like being bald on top, and even have a wild eyebrow now and then and it does me no harm.

I don't have to earn an audience with my looks, or demand that people take me seriously. 

If I get a hair cut and dress up nice, nobody calls me a whore, nor is a stranger likely to feel entitled to have a grab or fondle.

I'd like to extend this from male privilege to human privilege, but I don't know quite how. 

I would like everyone to enjoy it as much as I do.

Wednesday, June 10, 2015

My Life On The Road

Let me tell you the two weirdest things about being home when you are a "road warrior:"

Directions:


I've lived in this area almost 10 years and don't know more than five or ten roads by name. I can barely get around without GPS.

People describe places by approximation to local landmarks and I have no idea what they're talking about. When they talk about intersections it usually means nothing to me.  I've probably seen more of Europe than Lake County.

I know how to get to a few restaurants and stores, my house, and the local airports. Otherwise, it's all unknown territory. I'm a stranger everywhere, but I'm pretty used to being a stranger.

I think I've approached living in this house the same way I approach living in a hotel when I'm out on a gig, learning only enough routes and places to meet my needs while I'm there.  Roads I don't take, I don't know by name and don't know where they go or what they run past. Here to church. Here to lunch. Here to airport. That's it.

You know where Joe lives? By the golf course and the ball park?  No. No I don't.  I have no idea where that is.

Human Connections 


I don't know any local people other than my immediate family and those who go to church with me. Being gone 50%, and having an unpredictable schedule makes it hard on new friends. Usually the second time you turn down an invitation due to being out of town, they quit inviting and find other people to invest their time in. No blame, it makes sense. Other people have more of a shared connection to the area and the people in it. Travelers are disconnected from people.

I meet hundreds of people a month, but I rarely recalls their names and faces, let alone associate them with events and activities. I pass through as a benevolent (I hope) blur or activities and information. A kind of friendly ghost.

I have great friends here, in small and very committed numbers. As an introvert, maybe that suits me better than a large number of acquaintances. I also have very good relationships with people in the industry who share my lifestyle. There are very good souls out there flashing from business to business and convention to convention. I am proud to know them.

Even coworkers: I see them on my large flatscreen monitors, hear their voices on speakers, see their words on forums and emails, and sometimes get to do work with them when neither I nor they are out of town dispensing wisdom and insight.  But we maintain our relationships in bitesized pieces: a conversation here, and email there, a reminder or a photo from time to time.

Sometimes people talk about local people and events, and it reminds me that I don't really live here. I'm far more a citizen of the internet and the world than of my address.

I did meet one neighbor twice.  Once when my buddy knocked his mailbox down accidentally, and once when he helped me pull a friend out of a ditch during a snow. I have never known his name. I don't know if he still lives in that house across the street.

But it's cool, too


It's weird, but it's also pretty cool. I've seen the Great Wall of China, the great cities of Europe, including London, Edinburgh, Paris, Munich, Budapest and more. I've seen the mountains in Switzerland, Germany, Scotland, New Zealand and more. I've heard more accents, eaten more things, met more people, learned more things than I ever dreamed possible.

It's an amazing ride.

I don't know if it suits me, or it changed me to suit it.

I have to remind myself that the people around me experience life very differently than I do, especially the ones who grew up here as children and are still connected to family and childhood friends they see every week or every month. Some of them are with their spouses and children every single day, for better or worse.

I'm happy for them, and for me.

Wednesday, May 27, 2015

Writing the BDDs... Good Lord, NO!

Listen, you know how it is if you go out to eat and your friend has a big ole chive stuck to a front tooth and you are thinking that you don't want to embarrass your friend by pointing it out, but you also don't want him to walk around looking goofy and let people poke fun at him behind his back? You have a decision to make.

Because I love you and I care about your reputation and your perception in the world I have to tell you something. You sound like a hick. Not a southerner or a mountain person, a hick from some software jerkwater. It's when you say you are "writing the BDDs."

You are not writing the BDDs. BDD is a process. It's not the kind of noun that takes a plural... well, here let me illustrate:

Imagine I told you I was going to "code my programmings?"

How about "I locked my keys in my driving?"

Or possibly "I got a stain on my wearings!"

How bout this one, "Waiter, will my cooking be ready soon?"

Seem odd?

BDD is Behavior-Driven Development. It's a process, not a physical thing.

There is only one of them, that I know of. If there was another, it would probably have a differentiating name. It's a process you use to produce specifications.

If you use a gherkin-like language, you probably save the specifications in .feature files.

You can write specs.
You can write .feature files.

You write each of them, ideally, shortly before you write the code that will make the specification pass (when run as a test).  Writing the behavior-based test is a collaborative, exploratory-thinking exercise. It precedes coding. Heck, it generally precedes scheduling code to be written. BDD describes the collaboration and conversation and the process, the files are calls "specs" or "specifications" or "feature files."

BDD is to spec file as factory is to car.  You're not out driving your factories, you drive a car.

The specs (or feature files) are the residue from having done BDD.

In some cases, feature files are written without any BDD being done at all. You might write the code, and then write some specs (feature files) afterward to use as integration tests or system tests. You might even feel free to call them "gherkin tests" or "integration tests" or even "story tests" -- I'm not here to judge you.

But you are not writing the BDDs.

When you say you are going to "write the BDDs" you are using the words entirely wrong, and with a very puzzling plural.

You're going to sound goofy around anyone who actually uses BDD as a process.

You are not going to sound like a Behavior-Driven Development professional. You will sound like you picked up the acronym from a blog post and don't know how to use it.

I don't want that for you.

I suggest that you "talk the talkings right so your soundings aren't strange" by dropping "BDDs" from your vocabulary.

Nobody wants to sound like a software hick.

Not that there's anything wrong with real hicks. Some of my best friends are hicks. I used to be a minor-league hick myself. I'm not judging you, here.

Tuesday, May 19, 2015

This is NOT the End.



This is not the last sprint. There will be more after this. You don't have to have everything this week, and it's more important to deliver than to have every possible feature crammed in. Also, there isn't a good reason to not retrospect or plan if we're going to keep working.

This is not the last test.  There are cases not covered yet, and the solution isn't complete. That's fine. We can write another test and then add the code to cover it. Working incrementally means we often have work in some in-between stage. Let's just get this test working, and then write the next. Programming, says Michael Feathers, is the art of doing just one thing at a time.

This is not the last change. We could try to cram it in like it is an unexpected interruption and a special occasion, but it's not. Changes continue until the last user deletes the last version of the software from the last machine where it is installed. Probably better that we make changes like this easier to implement and easier to fit into the schedule.

This is not the final refactoring. As much as we'd like to pretend that the code can be finished once and for all, it's just not true. This is not the last change, and not the last sprint, so the design will have to continue to evolve. If one refactoring makes it temporarily worse, that's okay. Sometimes it's like cleaning the garage in that you have to make it a bigger mess before you can get it cleaned up. So, code goes through stages and steps and evolution. It's okay.

This is not the last project we'll do. This is not the time to stop learning. There are plenty more where this came from. Even if some aspects of this project are awful, it won't last as long as you and I do. Even if it is great, there are still things to learn. We can't act as if all of the future depends on this one, because it doesn't.

You are not the last person who can take on work. You have competent colleagues, all competent to various degrees and in different areas, but there is a lot of overlap. You don't have to always say yes, or promise that you will personally do all the work. You can share work assignments, and you can defer to others. Take care of each other and yourself.

This isn't the only day.  Tomorrow will have new work, and new problems, and priorities. We don't have to have everything perfected and perfectly buttoned up today. We can lean from today and pay it forward as long as there is still a tomorrow. There has always been a tomorrow for almost everybody almost everyday. Forgive what it is, but use some of it to make tomorrow great.

This isn't the only job. As much as we might want this gig to go on forever, odds are it won't. After 36 years I've outlived so many companies I worked for, but the people there are now in other jobs and so am I. The people and the skills you are blessed with and develop are so important. Your longevity in this field depends entirely on the number of people who want to work with you. Be kind. Be helpful.

This isn't the only thing we'll have to learn. The need to learn is relentlessly ongoing. We might as well get used to the idea and embrace the dreadful constancy of it, so that it becomes instead a kind of never ending adventure. We need to love learning, and keep learning, and keep shoveling out room for our curiosity. We can afford to have the next big lesson come only to find us unreceptive. Open up, it's okay.

The whole world is still incredibly incomplete and moving. This is not the end.

Friday, May 8, 2015

The Company: Can we talk about it?

We talk a lot about changing cultures. There's a lot of inspirational, humanistic content in agile conferences and forums and books and blogs. We tell our success tales in front of rooms of people in both corporate gigs and public conferences, and even as some are applauding, we see people crossing arms and lowering their gaze and some even blushing or flushing.

Inspirational stories are great, but not everyone is getting inspired. Some are getting frustrated, depressed, or even offended. The stories don't ring true to everyone, these storytellers seem to see the world through rose-colored glasses.

There is an elephant in this room.

In most software organizations the overt goal is to produce and release valuable code to customers, as early and often as possible. However, if you ignore what you hear and look at what people actually do, the organization is not fully focused on delivering valuable code.

In fact, many of the things they do seem to be focused on preventing the release of code. In The Systems Bible John Gall noted "systems oppose their own best function."

The real primary goal in most organizations?  To preserve and enhance your position within the organization.

I know that it is not very politically wise to talk about this, but can we?  After all, most software organizations can tolerate defects, late releases, and even product failures. But you can get fired for asking the wrong questions or criticizing key policies, or overstepping your authority or even as a result of someone else's play to acquire the influence that you currently enjoy.

Nobody wants to get fired. Most of us can survive it, and might even land a more lucrative job elsewhere (provided we don't get that dreaded negative reference) but it's a given that we want to keep our job and maybe only leave it through promotion.

Not everyone wants promotion, but everyone wants to gather more respect, autonomy, and compensation. To do that, we have to preserve our place in the hierarchy, and improve it if we can.

It's not really a negative thing, but if we try to ignore it then we can't take advantage of it.

I suspect it can become a positive force in our world. For instance, at Industrial Logic we have been creating an organizational directive to call out hazards and risks so that we can resolve them.

To be a good Anzeneer is to call out latent conditions that harbor risks and hazards to our members and customers.  Our place in the world now is to create more safety. The culture is open to questioning habits and policies and choices.

Maybe your covert primary goal can become overt, and actually work in everyone's favor at your company.

Can you talk about it?

Saturday, April 18, 2015

Bonus for Productivity?

The Whole Idea Is A Little Insulting


Scholtes' /The Leader's Handbook/ says that motivation through reward is insulting -- it assumes that you have been withholding effort all this time, waiting for someone to offer you an incentive to actually do your work.

Hadn't really thought much about it before.

But yes, it does assume you have effort on tap that you're not applying to your work.
And yes, it is a little insulting.
And yes, you could intentionally hold back until offered another bribe (but just enough not to be punished).

Everyone wants a little more money, but P. Scholtes notes that it's out of alignment with the idea of humanitarian management who realize that the employees are their greatest asset.


Not Only That, But It Doesn't Work



Likewise, Daniel Pink reports that rewards for knowledge workers tend to have the opposite effect of that intended. It might not be a good idea for programmers and managers in non-manual-labor fields.

Pink does mention that the system works great for physical labor.

Then How Do We Reward Team Members? 


At Industrial Logic, we have bonuses.

We have a health-n-safety bonus which we spend making our lives better. Some pay gym memberships. Others buy standing desks or treadmills or bicycles to help them keep fit.  It's not guaranteed every year, and the amount reflects profitability or generosity instead of performance.

We also sometimes have a profitability bonus, split evenly across the board, to celebrate another great year. We don't count on them, but they've been helpful to us as well.

The bonuses don't buy loyalty or effort. They're congratulatory and helpful rather than transactional.

Do you have any stories to share about your great (or awful) bonus system?

What do you feel about what Pink and Scholtes have to say about knowledge workers and bonus programs?