Each quarter of the year Obtiva consultants gather for a personal development day that reinforces the values and culture of the company. In the first quarter the event is called ObtivaCamp and is focused on Practicing software development. Today was Obtiva’s inaugural ObtivaCamp. It was in the format of a Code Retreat facilitated by Corey Haines. Above are some sketchnotes I took during the day.

Overall the event was a success. Take a look at Corey’s Code Retreat page. If it looks good to you my advice is to go for it and call Corey to facilitate. He does a terrific job.

My sketch tools include an iPad, the Brushes App, and a Boxwave stylus. I particularly like Brushes App (vs. SketchBook Pro for example) because to draw small text on the iPad you have to zoom in and write really big letters and then zoom out to see how it all looks. Brushes App makes that zooming really easy with a double tap. Also I like that I can export Brushes actions to the viewer on my Mac and then upscale it. Even cooler is the ability to export to a Quicktime video from the viewer.

So, without further ado, watch me create the sketch in this video:

You may have noticed some contradiction in the talk regarding the concept of software development as manufacturing. I said that the software development process is not like a manufacturing process. To state it differently, software development is not a deterministic process, and the cost to repair a mistake or change direction is orders of magnitude less expensive in software than it is in manufacturing. However, the concept of flow, where we pay attention to batch sizes, queues, and feedback loops is something we can learn from. These concepts do come from places like Lean Manufacturing, however, there are even better examples from the telecom and network routing space. For more on the concept of flow I still highly recommend “The Principles of Product Development FLOW” by Don Reinertsen.

Here are a few bits of entrepreneurial wisdom from the panel discussion:

• Put together a team of advisors to help you with topics that are not your area of expertise.
• Are you thinking of growing by acquisition? Multiples on purchase opportunities are way down, from 13 times earnings before to around 8 times earnings now. It’s a good time to buy.
• What should you expect from your sales team? They should generate at least 2.5 times their salary in revenue to justify their place on the team.
• Don’t assume you don’t need help in your own area of expertise. Julie Guida of Marketing Werks said the company benefitted greatly by hiring a marketing company.
• Even if you think you are too small, consider opening offices in other geographic locations. Don’t underestimate the power of being close to your clients.
• There are a lot of good people looking for work now. Use the down market to find and hire good people.
• To retain great talent treat them well financially and support them, but still expect them to support the company during difficult times.
• To hire great talent treat prospective employees like clients and help them fall in love with the company.

At the beginning of the panel discussion Steven Rodgers, the Moderator, noted that entrepreneurs are often the ones who step up and create jobs when the economy falters. We should recognize and honor their contributions more. Those are wise words.

Image by contrapositively via Flickr

In a previous post I described my approach to project management tools. To summarize, I prefer simple tools that I can string together into an effective process for each project.

I should note that the Software Studio at Obtiva generally takes on 2-to-6 person projects. Studio clients are by definition off-site. We usually meet face-to-face with them at least once per iteration for planning. Otherwise we act like a virtual team using on-line tools so that the client can participate in the iteration as it progresses.

The following are 7 simple agile project management tools that we use for Studio projects:

Drawing – Whiteboard & Digicam – There is really no substitute for standing in front of a whiteboard drawing, pointing, discussing, etc. This is high bandwidth communication generally reserved for planning meetings and or developer design sessions. When we need to record for later we usually just pull out a digital camera and snap a photo to later upload to one of our online tools.

Modeling & Planning – Index Cards & Sharpies – Along with a whiteboard another tool that is indispensable during planning sessions is the humble index card and sharpie. Collaborative card modeling is a high bandwidth activity and nothing really works better than physical cards for getting the team up walking around gesturing moving cards, ripping them up, etc. There is no substitute.

Lists – Google Docs Spreadsheets – While index cards work great for face-to-face modeling and planning the downside is that they aren’t digital. When the client leaves our Studio we need a way to share that planning information with them so they can think about things while we work on the current iteration. This usually requires us to transfer some or all of the information on the index cards to a digital form, a list. We’ve tried a bunch of different tools for this, including agile specific applications and ticket systems, but we always seem to come back to simple spreadsheets. Online spreadsheets like the one in Google Docs work great. They are always available from anywhere. You always know that everyone is working from the most up-to-date version. And, within the constraints, the tool is flexible enough and rich enough to manage user story lists and provide some decision support very transparently to the team.

File Storage – Google Sites File Cabinet – As with any project we often produce various file based documents such as screen captures, mockups, written docs, etc., and we need a place to keep them. Google Sites File Cabinets are a good option for this because they are secured but always available to everyone on the team.

Presence – Campfire – We know for a fact that collocated teams and clients provide the best, highest-bandwidth communication (a huge factor for project success). One reason for this is because team members that  work in close proximity can overhear conversations and interject or help the team get to answers quicker even if they weren’t originally included in the conversation (see Alistair Cockburn for more on this). We replicate this type of overheard conversation virtually using a group chat tool. Currently Campfire is our tool of choice for group chat because it is web-based and easy for clients to learn and use. It even goes one better than face-to-face communication in one aspect; all the conversations are archived and searchable later. Campfire has become an indispensable tool for our Studio projects. (http://www.campfirenow.com/)

Discussion – Google Sites Blogs – For non-real-time discussion of issues or ideas it’s nice to have a threaded discussion somewhere that the team can go back and review. Any sort of forum software will work for this. We tend to use Google Sites Blog pages because it’s one less login to manage. We don’t use this tool extensively but it does serve a niche need sometimes.

Ticket Tracking – Lighthouse – In software development projects there always comes a time when major feature development is done and the team focuses on lots of little nits. At this point user stories just don’t fit the tracking need and we’ve found that ticket tracking fits the workflow better. Because I am a fan of lightweight easy tools we’ve been using Lighthouse for ticket tracking lately. I’ve seen some new competitors in this “easy ticket tracking” space lately so I would encourage you to survey the competition. (http://lighthouseapp.com/)

Email – JUST SAY NO! – Finally, when it comes to project communication we try to avoid email. Why? Well for a lot of the reasons noted above. Email often excludes a part of the team that might have the answer. Email isn’t easily searchable by the whole team, including clients. Even individuals can lose track of an important project related email amongst all the other information that comes through their inbox. So my advice to project leaders is to discourage or ban the use of email for daily project work communication and encourage the team to use centralized online communication tools with searchable archives like the ones listed above. And don’t forget, nothing can replace the high-bandwidth communication that happens in front of a whiteboard or a table full of index cards and sharpies.

Do one thing and do it well

(Wikipedia)

When it comes to managing agile software developement projects, I prefer simple tools. Sure, I’ve tried numerous monolithic project management applications over the past 16 years. They do it all. But I keep coming back to a set of simple tools that do just a few things well. In fact I prefer tools that aren’t project management specific at all.

Why?

First, project management applications are often heavily focused on management decision support. This seems dead wrong to me. Projects are delivered by project teams, not management. I’m not saying that management reporting is bad, just that enabling project team process is so much more important that everything else should fade into the background. For example, decision support features, if they exist at all in a project management application, should ideally be entirely hidden from the project team. In other words, all features that the project team uses should directly connect to the work of delivery and any decision support features should be completely invisible to the team. Most project management applications don’t follow this principle and I just can’t get past that.

Second, to offer a rich monolithic project management application that people will pay for one must add a significant number of features and cover a significant number of project processes. This inevitably leads to an application that reflects a particular methodology. I’m not saying that methodology is bad, just that consistently implemented techniques are so much more important for project success. In other words, smaller tools that enable techniques allow me to tailor the methodology to the project. With most project management applications I can’t do that.

Third, project management applications often include too much structure. A few years ago I had the displeasure of working with a ticket system that had a crazy state machine built in. We had a spaghetti graph showing how it was configured and it was just scary to look at. Of course the “flexible” and “configurable” controlled workflow was a selling point to management (and SOX auditors), but in essence the system just got in the way. I’m not saying that structure like workflow is bad, just that staying out of the project team’s way is so much more important. I would rather manage structure the good old fashioned way. If a project management application requires lots of structured process I would rather not use it.

So, what do I use?

Currently I use a set of simple tools that I can string together in a way that works best for the team: web-based spreadsheets and documents, group chat, threaded discussions, a simple ticketing system, and web-based document repositories. And lately I have focused my attention on learning techniques to more effectively use physical tools like whiteboards and index cards. All these tools do very little, but they do it well, and I stand in between and integrate them into a useful process.

So generally I would say I follow a sort of Unix Philosophy of project management tools. For you Unix geeks out there, I’m the pipe (|). I use simple tools that do a few things well and string them together into a process that works. Obviously, integrating the tools by hand is time consuming, and APIs and automation in between could free me up to do more for the business. However, given the size of our company and our projects I think the tradeoff is worth the benefit, for now. The approach has been tremendously successful for the agile software development projects that we deliver and it can work for you too. So don’t be seduced by big monolithic project management applications. Just be the pipe.

Guidelines to Create Your Own Personal Marketing Guide

The purpose of the Personal Marketing Guide is to introduce your professional self to your friends and family. Here are some basic components to include.

Contact Info

Put your contact information in the header just like on a resume so your friends and family can help hiring managers connect with you.

Cover Letter

On the first page start with a letter to your friend or family member. It doesn’t need to be formal. Just write a few paragraphs about your current situation so they understand what you’ve been up to and why you are looking for work. Make sure you end the letter with a request for *only* the name and phone number of appropriate hiring managers who may be interested in your skills and experience. It’s also good form to let your friend or family member know that you aren’t asking for an endorsement, just a contact. And of course thank them in advance for any help they can offer.

Instructions

One caveat about using a Personal Marketing Guide is that your network may not realize that it is only for them. You probably don’t want this document in the hands of a hiring manager. I’ve found that it is best to spell this out clearly at the top of the second page. Here are the instructions I have used in the past:

PLEASE NOTE: THIS DOCUMENT IS NOT A RESUME. This document is intended to provide friends and colleagues with information to help identify the types of companies and hiring managers that I hope to connect with. My resume will be made available to hiring managers under separate cover.

Objective

In the objective section briefly describe the position(s) you are looking for. On my guide this was limited to one short sentence.

Target Market

In the target market section describe your target geographic location(s), target industries, and target organization size(s) (small, large, global, etc.).

Overview

In the overview section describe, in layman’s terms, what you do. Keep in mind that your friends or family probably don’t have any understanding of the terminology of your profession or industry so make sure you keep it jargon free. Also briefly describe your recent experience, again keeping the language clear and jargon free. This section should be a couple of paragraphs max.

Recent Positions

In this section list 3 to 4 recent positions and companies. You don’t need to provide details. Here you can use the official title as it might help your friend or family tell someone exactly what your recent titles have been and exactly where you worked. I usually limit this to title and company name.

Skills and Experience

Finally, provide a categorized bullet list of skills and experience. Each listed item should be just a couple of words. It’s okay to use jargon here if you can’t use clearer terms. My guide included lists under the following categories: project management, business, process improvement, industries, and technologies. Use categories that make sense for you.

It is okay to use jargon in the Recent Positions and Skills and Experience sections so that your friends and family can quickly answer specific questions like: Where has he/she worked before? What were his/her title/position? Does he/she have experience with …? etc.

Conclusion

I have used a Personal Marketing Guide for two job searches over the past 4 years and received positive feedback both times. Moreover, both times I found my new job by networking.

Your goal is to help your network identify hiring managers who may be interested in your skills and experience and to get their name and phone number. Once you have that it is your job to contact the hiring manager and send your resume.

Give the Personal Marketing Guide a try. I hope you’ll find it as useful as I did.

(I learned how to use this tool from Ed DeVries at LHH. Thanks Ed.)

You can find the project here: http://github.com/twebb/sprint/tree/master

Well, in January 2008 I came across a video that opened my eyes and reinforced my admiration for great singers. In A Master Class with Barbara Cook a number of aspiring young singers undergo a remarkable transformation under Barbara’s tutelage in front of a live audience. The transformation she achieves with a few of them will blow your mind and the central lesson she shares is be authentic.

The main thing to learn is that what the world wants is you. You are enough. You are always enough.
- Barbara Cook
(Via Howard Reich – Chicago Tribune,
Cabaret queen’s lessons for life)

That’s a great lesson for singers and I think it’s also a great lesson for all of us.