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

New Business Cards

I wasn’t liking my business cards.

So Hillary and I spent a couple of hours on OvernightPrints.com today and came up with something that I like better.

What do you think?

Managers Support Group – Report

“It’s so great to hear that I’m not the only one dealing with this problem!” said one engineering manager after another had shared a problem they were having getting non-technical upper management to understand the time and complexity issues of software development.

The discussion was lively and time ran out long before we had covered all the topics that had come up. The topics discussed included:

• Finding time to ‘get work done’ amidst constant interruptions
• Protecting the team’s work flow from outside interruption and meddling
• Finding focus, how to choose what to pursue and what to let go
• Dealing with ill-defined goals
• Dealing with morale busting bureaucracy and ‘HR’ influence

The night started out with a mini-workshop in which the participants took a hard look at the reasons meetings get called and identified the good from bad, from the ugly. As Socrates taught me, every meeting should have a goal that is:

• Measurable, obvious when met
• Attainable
• Understood and shared by all
• Meaningful, has clear benefit

When a group meets around such a goal:

• The meeting has focus
• The meeting can be short; no need to drone on after the goal is met
• Attendance tends to improve
• Attentiveness tends to improve
• Attitudes and morale tend to improve

Next month we will have a new mini-workshop and more discussion and group support for the issues that you are facing every day. Join our meetup group!

Dilbert on Efficient Meetings

Is the Dilbert approach to efficient meetings better than mine? I have no opinion to share.

Support Group Meeting Tomorrow!

The Bay Area Engineering Managers Support Group will meet tomorrow (Tuesday) night in Palo Alto. The evening will start off with short interactive workshop. Tuesday’s workshop will focus on one of the easiest ways to improve the effectiveness of meetings. Next will come a facilitated discussion in which participants can share issues that they are facing at work and get feedback, tips, and advice from the group. The event is free. We still have room for a couple of more folks to join us. Please RSVP at meetup.com or by leaving a comment on this blog post.

This is not about Dilbert

Scott Adams, of Dilbert fame, shares the secrets of good writing. OK, he doesn't share all the secrets, but a few really good ones. Do they apply to business writing? Yes. Take a couple of minutes and go read his post.

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!

To Script, or Not to Script?

Catching up on some old blogs, I ran across this. I like Neal’s calculus for figuring out when it is worth scripting a test.

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.

Is it Time to Quit Your Job?

The Chief Happiness Officer has a good post today on knowing when it is time to quit your job.

If you are unhappy in your job, go read it. No really, stop reading this and go read it. OK, since you are still reading this, I’ll give the upshot of his article, but really the whole thing is worth reading.

• Give up the idea that you can know for sure whether or not it’s time to quit. It’s always going to be a leap.
• Listen to your intuition. Your gut may know before your mind.
• Remember what quitting can cost you - but also remember what staying in a bad job can cost you!
• Remember that the longer you stay in a bad job, the harder it gets to leave.
• Most people stay too long in bad jobs - mostly because they fear the uncertainty that comes with quitting.
• Most people, once they’ve quit, find that their situation improves. Maybe not immediately, but certainly after a few months.