You’re missing something, and it may kill your project.

Reports that say that something hasn’t happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns — the ones we don’t know we don’t know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones. – Donald Rumsfeld

A few months ago, we began to replace software some of our staff use on a daily basis. It’s the first step in a process that will completely overhaul our system, but we wanted (and needed) to start small. We picked a small-ish piece of functionality that 3 or 4 people may use during a given workday, and set about re-creating the functionality to fit into our new browser-based architecture. Interviews were done with the users to collect feedback on…usability (of course). “Hey user, you’ll notice the steps in the process are the same, but the flow has improved, right?” We worked and tweaked and followed our style guide.

The end result? Nailed it. Not only was the new product (initially) met with adoration from the users, but it was a tight, textbook example of how to deliver using Scrum. From design to integration, this shiny new piece of software replicated existing functionality, improved the user experience, and moved us one step further away from an aging legacy system (which, all things considered, has performed more than admirably). Once we moved the product into production, it was smooth sailing.

Except that it wasn’t.

We missed something. Well, actually we missed a few somethings.

In our diligence in examining the product we were replacing, we forgot to ask some questions. The backlog was there, with plenty of well-defined stories fitting into a handful of epics. We built what we were supposed to build. But we failed anyway. We recognized our mistakes and fixed them quickly and with relatively little disruption, but still, we didn’t hit the mark.

Why?

wires
This is why.

This thing right here? It’s nasty. It’s an absolute mess. Not only that, it’s dangerous. Seriously. People die on a regular basis in poorer cities across the world where you find things like this. When I say “things”, I mean “solutions”. Yes, it’s dangerous, but it was done because there was a need that was not being met any other way. In the case of this mass of wires, people needed electricity and they weren’t able to get it by calling up the electric company. And the designers of the original system certainly didn’t plan in a way that accommodated the needs of the people in the neighborhood. So the people took matters into their own hands and created this monstrosity.

But if it’s the difference in creating this beast or going without electricity, you create the beast.

That’s what we missed. We are replacing functionality that has existed for over a decade. Let’s assume the people designing the original solution got everything right 11 years ago. No, really. Not a single misstep in design or creation. Even in that scenario, changes to business, or changes to process flow have the capacity to destroy the viability of the solution. In our case, we had a well-designed product that adapted well to the changes we’ve faced over the years, but there were still problems from time to time that simply couldn’t be addressed by the product. So our employees did what most people tend to do. They created hacks. Workarounds. Solutions.

We learned something valuable. When replacing an existing system or piece of functionality, it’s not sufficient to replicate what was already there and add in the new features. You need to account for the ways people are working around a solution that no longer meets all their needs. The workarounds won’t always be obvious. They’ll rarely be documented. But trust me. There’s a giant ball of something hiding from you. It may not kill dozens of people each year, but ignore it and I can promise it will make a few lives very miserable.

If It’s Important, Write It Down

“Words are pale shadows of forgotten names. As names have power, words have power. Words can light fires in the minds of men. Words can wring tears from the hardest hearts.”
― Patrick Rothfuss, The Name of the Wind

 

There are certain values in Agile that highlight the need for genuine communication. In fact, 3 of the 4 principles listed in the Agile Manifesto relate directly to quality communication:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

They are born out of decades of a document-heavy software development process and serve to inform and remind us that there is nothing wrong with written words, so long as they don’t serve as a replacement for conversation.

At some point however, no matter how good your conversations are, there are some things that need to end up on paper. Even the Agile Manifesto ended up in writing. 🙂

Paper (written here to include actual paper as well as electronic communication like email and websites) is indispensable. Written words show commitment, and give opportunity for reflection and improvement. It was not good enough for colonial leaders to send a representative to recite a speech to parliament. No, Thomas Jefferson wrote the Declaration of Independence. There may have been a time when some spit and a handshake got work done, and I think it would be great to be able to effectively operate that way again, but it’s not the world we live in. If you disagree, tell me about the last time you took a full-time, salaried job without something in writing. In our world, if it’s important, you write it down.

I’ve taken the informal route plenty of times. Sometimes it’s fine. But then there’s the time I got fired for following an unwritten, but verbally approved, procedure. I waited patiently for my district manager to speak up and confirm that I had acted with his approval. The silence was deafening.

A little over a year ago, when our software development teams were getting underway, in earnest, with Scrum, there were some rumblings that made their way to me. It boiled down to our (verbal) commitment to use clean code in our development process, and the fact that, quite simply, the devs did not believe us. Sure, clean code is great, but what happens when we hit our first big deadline? Are you going to hold the line and say we’re doing things the right way, even if it means another few weeks and few thousand dollars? Or are you going to say we have to cut corners and get the job done?

I didn’t blame them at all. It really wasn’t a reflection on our organization, as most of our devs at that point were fairly new. It was a natural reaction to them having been in those situations before, and being told to cut the corners and do it “dirty”. The solution seemed pretty easy at the time, and results so far show that it was the right call. I wrote our Product Development Principles. It’s a light-weight, one-page document that says “here are some things we’re committing to, and we’ll stick to these things no matter what”. Nothing controversial, really. User Acceptance Testing. Involved Business Owner. Building new products based on strategic executive direction and vision. And Clean Code. The Bob Martin version, just in case anyone had an idea about what Clean Code is that may differ from our intentions.

It was not only the right thing to do, it worked. Our teams needed to believe that we, as an organization, will do what we say, and so we gave them a piece of paper and said “we’re committing to this and you can hold us accountable”.

What aren’t you writing down? And why? Here are some reasons that immediately came to mind when thinking of why something isn’t getting put down on paper:

  • You’re lazy.
  • You don’t want to be held accountable.
  • You don’t really believe what you would write.
  • You don’t really know what you believe.

 

Not in a habit of writing down your daily tasks? Do it.

Have someone who needs some reassurance that you’ll do what you say? Put it on paper.

Your organization doesn’t have a formal, written purpose/mission/vision/values statement? Seriously? Go write that thing. This moment. GO!

Professionals & Goobers: The New Personality Test

“Spit all over someone with a mouthful of milk if you want to find out something about their personality fast.” – Jenny Holzer

From onlineslangdictionary.com
It started as an impromptu exercise, mostly aimed at cheap laughs. I was waiting in a conference room for a meeting to begin when Emmet (fake name) walked in. Emmet is great. He’s a lot younger than me, but we mesh really well and I love working with him. He’s a professional. I…I am not. I’m a goober. And I said so. “We’ve got a good balance right now, Emmet. You’re a professional, I’m a goober. Next person who walks through the door will tip the scales.”

I didn’t really have to explain what I meant. He got it. And so we waited. A goober arrived, followed by three professionals, giving the goobers a deficit, but I knew who we were still waiting on. The last two in the room were clearly goobers, bringing balance to the force. Or at least to the meeting.

Myers-Briggs, Pace Palette, DISC, ad infinitum. Personality tests are a pretty common business tool, and they can be a lot of fun. We use them on my team. There are 22 of us. On the Pace Palette (no relation), we’ve got 18 greens and 4 reds. Our Myers-Briggs results tip heavily toward the INTJ type. For a group of software devs and business intelligence folks, that is not surprising. But what about Professionals and Goobers? I don’t have a standardized test (yet), but an eye test tells me we’ve got 14 Professionals and 8 Goobers.

What about your organization? Don’t wait on my computerized test. The eye test is really all you need. If you’ve been in the business world long enough, you know exactly the types of people I’m talking about, and will almost immediately be able to separate them accordingly.

The bottom line? You need both. No, I didn’t say it would be nice to have both. I said you NEED both. Look at what professionals have done to HR over the last decade. The only thing that will save an HR department from collapsing in on itself from the weight of self-importance and needless regulation is a decent percentage of goobers (min 30%). Another reason it’s important to have goobers in the HR department is because professionals tend to hire professionals. If you are going to get a good blend of the two for your organization, you need a few goobers on hand to make sure professionals are not stacking the deck.

Goobers can thrive and add value almost anywhere. The best CEOs are often goobers. The only exception may be your accounting department. Perhaps it’s best if we leave that strictly to the professionals.

Some Christmastime Database Humor

And who doesn’t love some database humor at Christmas? A few days ago, @withoutgorms posted this tweet:

He’s making a database,
He’s filtering twice
SELECT * FROM customers WHERE
behaviour = Nice
Santa Clause is Coming to town.

When this was shared with our Business Intelligence Analyst, he had the following reply:

This is followed by Santa swearing loudly because some of the children have no primary address marked, while others have multiples. The zip code field allows letters which breaks his WHERE clauses (see what I did there) that use integers. Anyone with a Naughty date prior to 5/19/2004 is automatically set to that date and he can’t see exactly how long they’ve been naughty. His Naughty Reasons table only allows 1 very poorly defined reason per child, and their Naughty record is deleted if they ever become Nice again. Figuring out how to see the behavior that Referred the child to the Nice list requires joining 7 different tables across multiple databases that have the same fields named differently, and his stupid elves have added dummy children to the production databases for testing purposes and have neglected to remove them. Poor Santa.

It’s ok. You can laugh AND cry. We do.

Why I Play Games At Work

A game of hidden identities.
Avalon: The Resistance


“I have worked in lots of places as a consultant and what I have seen in the last few years is truly alarming. No one takes lunches, no one…”
– comment from NYT article “Why You Hate Work”

 

“I like to move things forward over lunch.” It’s one of the first things my boss said to me when I started my new job a little over two years ago. I nodded. And at the time, I think I agreed. “Of course”, I thought. “Why not use that time to get a little extra done. Maybe relieve a little bit of pressure later in the week.”

Not long after, having given up a number of lunches to the demands of work, I was more stressed than ever. Around that time, a co-worker looked at me, surmised my frayed state, and gently said “Dana, work will take everything you give it.” It was an eye-opening moment. Since then, I’ve come to realize a lot about myself. I love my job. I love working hard, and I don’t mind long hours. But there are times in my day that I need to carve out that belong to me and me alone. Lunch, I decided, is one of those times.

Before I talk about the games, I want to say I understand not everyone is like me. My boss thrives on the work. He would be stressed out if he took his lunch hour to play games or go on a long walk. There are plenty of people who would rather eat at their desk while they work. I don’t judge. I’m completely ok with that.

We play games. People in my department, people from other departments, people I manage. Every day. There are some days I absolutely have to give up to an emergency or urgent deadline, but those are rare, and people know I am fiercely protective of that time. But whether I am there or not, that conference room will fill up with 8-10 co-workers ready to play. We’ve had as many as 16 show up, and the group continues to grow, slowly but steadily. Once everyone is in place, we begin, and the game is almost always “Avalon: The Resistance”. It’s a hidden identity game. There are good guys and bad guys. People get sent on missions. Bad guys try to sabotage the missions. Good guys try to find out who the bad guys are before it’s too late. Aside from the pure enjoyment and team building, it’s not completely without value to know how your co-workers react to being falsely accused, or mistrusted for no good reason. Or how they lie. 🙂

Beyond the stress relief, fun, and relationship building, there’s another reason I play. Recently, I was visiting with a software development partner in Chicago. They have a wonderful space downtown, and one of the rooms is designated as the nap room, replete with a sturdy oversized hammock and a door for privacy. The door, according to the CEO, was an important part. It’s an intentional separation from the work going on just outside. And their people use it. I also had the opportunity to visit a large state of the art facility in Indiana last year. They had an incredible workout space, a few nap rooms, game rooms, and a basketball court. And the whole area was a ghost town. It’s not just about saying you value something. It’s not just about creating the space. If employees are afraid to use the space, or embrace that cultural ideal, then they’re probably not going to. The other reason I play is so my employees know that fun is not just lip service. They know they’re free to use their time (and it IS their time) as they see fit. If they want to use it to work, so be it. But I’m in the other room, and I’m a bad guy this time, and I’m going to fool these poor suckers right up until the very end.