Agile Learning Labs

Paper Prototyping

LinkedIn has a cool feature that let's you ask a question of your whole network. This morning, someone in my network asked this question:

Tools for visualising interactive prototypes? What do you prefer?

Powerpoint, ConceptDraw, Omnigraffle, Flash, Ruby on Rails?

We are reviewing the tools we are using to help visualise interactive storyboards and concepts for our clients. What are other people using? How important is it that the tool supports experimenting with real data and conditional branching in order to explore with the development team the consequences of their design decisions?

My reply:

Consider Paper Prototyping.

It is low cost, easy to do, and will quickly teach you how a real user will react to the system. With a paper prototype, a human acts as the computer, so your prototype can support some very sophisticated logic without the need to create code. Modifications are trivial, encouraging experimentation, discovery and improvement. I was skeptical at first, but after using it a few times I have become impressed with the power of this tool.

Photo courtesy of Nertzy

Practice Practice! Practice!!

This coming Tuesday, I’ll be facilitating the first meeting of the Bay Area Engineering Managers Support Group. The event will start off with a short workshop focused on one of the key criteria for having successful meetings. Today was the day I practiced the workshop with a live studio audience.

Overall, it went well, but there were some bumps. There was a ‘bonus’ section that I thought I could add on to the end of the workshop to present some closely related material. It seemed like a good idea at the time, but when I did it live, the ‘bonus’ material didn’t flow. Conceptually, the additional material was just a bit too far from the core material and required the participants to change gears in way that was distracting. This was not what I wanted to happen at the end of the workshop, so I pulled the material. My workshop will go smoother, and the participants will have a better and more useful experience because I did a dress rehearsal.

The same idea of a dress rehearsal works extremely well for presentations. If you are going to give a presentation, the single best thing you can do is practice it a few times. First, go through it out loud (really, out loud) by yourself. Make sure that the length, pacing, and transitions seem good. Next, you want to get as close to the real thing as possible. Practice in the same room that you will be presenting in. Use the exact same equipment that you will use on the big day. Get some friends, a mentor, or your manager to listen to your practice session and give you feedback. Doing this will make you much more confident on the big day. The presentation will go smoother and your audience will have a more positive opinion of you and the material you are presenting.

Want some help addressing the challenges of managing engineers? Check out the Bay Area Engineering Managers Support Group. It’s free!

Compliments – Positive Feedback

Compliments and criticism are the two edges of the feedback sword. Today, The Chief Happiness Officer’s Blog explains that to be effective, compliments must be specific. This generalizes well to ‘feedback must be specific’. In particular, you want to clearly describe the behavior that you observed. For instance: “Bob, I see that while you were fixing that bug you also added several new tests and refactored the module.” Now that Bob knows exactly what you are going to compliment him on, tell him about the impact this will have: “That will really make it easier for people to work in that module in the future, and probably prevent some bugs too!” At this point, if we were delivering criticism, we would request a change in behavior. Since we are giving a compliment, we can simply say thank you: “I really appreciate you doing that. Thanks.”

You can find more on feedback here.

A Different Kind of Tolerance in the Workplace

Dannyman pointed out this quote from William L. McKnight, past Chairman of the Board at 3M.

As our business grows, it becomes increasingly necessary to delegate responsibility and to encourage men and women to exercise their initiative. This requires considerable tolerance. Those men and women, to whom we delegate authority and responsibility, if they are good people, are going to want to do their jobs in their own way. Mistakes will be made. But if a person is essentially right, the mistakes he or she makes are not as serious in the long run as the mistakes management will make if it undertakes to tell those in authority exactly how they must do their jobs. Management that is destructively critical when mistakes are made kills initiative. And it's essential that we have many people with initiative if we are to continue to grow.

This idea applies to the manager leading a small team, not just to the CEO. While giving guidance is necessary, controlling all aspects of how your team members work is not. Nobody wants to be micro-managed.

The other bit in there is tolerating mistakes. There are two broad categories of ‘mistakes’ that your people will make. The first type isn’t really a mistake at all, though you will think it is. They will choose to do things differently than you would. Very often, our instinct is that different is wrong, or at the very least, not as good as the way we would do the thing. After all, you are the manager, the leader, and the expert. Right? Remember all the times your boss wanted you to do things some way that was clearly not as good as the way you wanted to? Now that you are a leader, work hard not to be that boss.

The second type of mistake that your people will make is a mistake. It can be hard to tell this type of mistake from the first kind until the results are in. When these mistakes happen, err on the side of tolerance. Help the person to examine the mistake and learn from it, in a way that is supportive. Good people don’t like to fail. The pain of the failure will be punishment enough for them.

My First Meeting at Geekaplex

It was a bad day at Geekaplex. A star developer’s computer had crashed hard, taking a week’s worth of new source code with it. The big boss was furious! How could it be that there was only one copy of the code? I spoke up, “We need source control, and a backup system.” The big boss looked at me and said: “OK, then get some people together and make it happen!”

I was fresh out of college and this was my first gig. I knew that I didn’t have the knowledge or clout to make this happen on my own, so I called a meeting. I sent out an invite to all of engineering: “Let’s get together and talk about source control and backup.”

Meeting day came and about half the engineering department showed up. I was a bit disappointed at the turnout; didn’t they know how important this was? After waiting a while to see if more people would come, I started. “I think everyone heard about what happened last week. I think we need a source control system, and a backup system too. Who wants to start the discussion?” Surly Jim snorted. Several people chimed in to agree that we needed source control and backup. A few were worried that using source control would slow them down or get in the way. Billy told a story about the time his previous company’s source control system crashed and only then did they discover that the backups were all corrupt. Ken said that to be elite, we needed to run Submarine-Version on Linus.

The meeting rambled on for quite a while, and I started to feel like it wasn’t getting anywhere. Laptops started opening. Spalding started coding. Kathy and Chris were obviously IMing, and a few people seemed to be reading email. Eventually, some people just got up and left. Those who stayed seemed to be getting more and more impatient, Surly Jim in particular. Finally, he burst out “Why are we all here? What’s the point of this meeting?” The room got very quiet, and then Socrates spoke up: “I think we have done all we can today. Let’s wrap things up for now.” Everyone, including me, was relieved. As people shuffled out, Socrates stayed behind.

Socrates wasn’t his real name, of course, but that’s what everyone called him. According to talk around the office, he had worked at PARC, Apple, and Atari back in the day. He had been a founding engineer at All Your Base, and as the company grew, he went from writing their first games to running the development group. He left shortly after the company was sold to EvilEmpireSoft.

“What do you think of your first big meeting?” he asked. “I feel like I just wasted everyone’s time.” I bemoaned. “It’s good that you see that. They’ll forgive you, once.” He paused, and then asked, “So, what will you do differently next time?” I said that I wouldn’t invite surly Jim, that’s for sure. “Actually, he may have helped you the most, as he raised a key question. What was the point, or more precisely, the goal of that meeting?” I thought about it for a minute, and then said that it was to talk about source control and backup. “Well then, you should be happy with the meeting. We talked about those things for some time.” Now it was my turn to snort. “Sure we did, but we didn’t get anywhere!”

Socrates then asked me where I had hoped to get. I replied that I had hoped that we would walk out knowing what source control and backup systems to adopt. “So, you wanted the goal of the meeting to be choosing source control and backup systems?” “Yes, I suppose that is what I was hoping for.” I replied. After a thoughtful pause, he said, “That’s actually a great goal for a meeting, much better than your original one.” That made sense. He went on, “Your first goal wasn’t a total stinker. It had one of the important qualities of a good meeting goal: at the end of the meeting you can easily determine if the goal was met. You simply ask the question: Did we meet the goal of talking about source control and backup systems. The question lends itself to a clear yes or no answer. Some goals are too vague or general to be even that useful. For example, what if your goal had been to improve software development practices here at Geekaplex? How meaningfully could you answer the question: did this meeting improve our software development practices? You really couldn’t tell if the practices improved until some time after the meeting.”

OK, so according to my original goal the meeting was technically a success. Still, it wasn’t a good meeting. According to my revised goal the meeting had failed. This wasn’t surprising, given that I hadn’t really known that it was my goal.

The meeting may have crashed and burned, but at least I was learning something from the experience. If I was to avoid wasting people’s time, I need to have a clear goal for any meeting that I call. The goal needs to be something that I can measure the success of the meeting against. At the end of the meeting, I want to be able to ask: “Did this meeting meet the stated goal?” For that matter, before calling a meeting I could ask myself “Will a meeting be able to meet this goal?” Had I asked myself this question at the outset, I probably wouldn’t have called this meeting, and wasted so many peoples’ time.

If you want to stop wasting time in meetings consider our class Stop Wasting Time in Meetings!.

Complaints!

Heads up! The Chief Happiness Officer is urging people to complain at work. His point is that complaining in a constructive way can make the workplace better. Fair enough, but what if you are a new manager and you are the one listening to all of these complaints?

I once had a direct report that was constantly finding things to complain about. He was well-intentioned, smart, and one of the most productive engineers on the team. The things that he was complaining about were all things that could, in fact, stand some improvement. He thought that by pointing out everything that could use fixing, he was doing his part.

Next time he came to me with a complaint, I asked him what he thought could be done to improve the situation, and specifically what could he do to help implement a fix. He happily went into problem solving mode and generated several potential solutions. We then discussed the merits of each and compared the costs to the benefits. We chose a course of action and each of us committed to taking some specific actions to improve the situation. After that session, he almost always came armed with potential fixes to go along with his complaints.

It’s OK to complain. It is often much more useful to propose a solution, especially one that you are willing to implement.

Feedback

I just read this article at cio.com. It had some excellent advice about how to give, and how not to give, feedback to others in the workplace. Feedback is one of the most powerful tools in a manager’s toolbox. Use it early; use it often. It is far better to give regular feedback than to save it up for performance review time.

The author, Esther Derby, recommends a multi-step approach to giving feedback that is similar to that recommended by the guys over at Manager Tools, though a bit more flexible.

The steps include:

The Opening – Basically letting the person know that you want to give them some feedback and finding out if this is a good time. Of course, you should pick a time that you think is good for them before making your approach; check their calendar!

Sharing What You Observed – This is all about reporting the facts of the behavior that you are giving feedback on. Doing this without coloring it with judgment can be tricky, but is very important. At this stage it is better to say “Tom, I noticed you surfing the web during Bob’s presentation today.” than something like “You were disrespectful toward Bob this morning.” It is much easier for Tom to dispute whether or not he was being respectful than his web surfing. You really want to get agreement that the behavior occurred.

Describing the Impact – Here you might describe how others where distracted by his surfing, and that it undermines Bob and the information that was being presented. This step may not even be needed, as many people will quickly grasp the problem with their behavior. Tom might say, “Gee, I didn’t realize that other people would notice. I guess I was a bit of a distraction.” This may be as far as you need to go.

Request a Change – Tom may volunteer to change his behavior, or at least acknowledge the problem in a way that implies he will change. If he does not, then request some specific change such as leaving the laptop behind at these types of meetings.

Finally, it is worth noting that feedback can be positive as well as negative. Human nature being what it is, people tend to be more receptive to positive feedback. Use it! Reinforcing the good behaviors is just as important as changing the bad.