Guild Blogs

I haven't posted much about my enjoyment of motorcycles, but yesterday I took the next step in my ongoing series of motorcycle experiences.

My new bike is a 2005 Suzuki DL1000 otherwise known at the V-strom. I'm looking forward to getting to know it a lot better. The previous owner put a lot of aftermarket farkles on it including heated grips (incredibility useful as it was 40F on the way home) and a custom seat which seems great so far.

For the last few years I've been riding this 1998 Ducati ST2, which has been a wonderful bike, but as I get older the position gets more uncomfortable the longer I go. And lets just say it is a tad expensive to maintain.

Back in the day I rode one of these to and from work. Things have sure changed.

Jason Goldberg has a great post on some of the things he learned while CEO of Jobster.com.

1. The CEO's job is to create value.
2. Try to ride some powerful existing waves vs. just creating new waves.
3. Technology companies are all about the product.
4. Related to #3, the rapid iteration model (ship early, learn from usage, adjust) works well for consumer services but works not as well for B2B services.
5. Hire people who are passionate about the specific problems you are trying to solve.
6. You must get close to your users and customers and live their personas.
7. The value of your company is directly related to your capital efficiency.
8. In the early days, I highly recommend that you force your startup to be resource constrained.
9. Don't listen to outsiders who tell you to go faster and ramp sales and marketing.
10. Avoid field sales in favor of telesales.
11. Once you are in the market and have established some measurable and repeatable levels of success, #11 negates #8 on this list.
12. Have fun.

Planning on starting your own company? Here are some good points to consider from High Tech Strategies - Ten Reasons High-Tech Companies Fail

• Lack of Market Focus
• Excessive Pace of Product Improvement
• Incomplete Products
• Undifferentiated Products
• Channel Mismanagement
• Failure to Establish the Right Competitive Barriers
• Using Price Alone To Drive Market Transformation
• Improper Use of Advertising
• Misinterpretation of the Technology Adoption Lifecycle Model
• Irrelevant Market Research

Jeffrey Phillips wrote a nice post on Accountable for production not attendance. In it he argues that most knowledge workers should be treated like virtual workers – they should be held accountable for their production, not their attendance. The implication is that the results of the work is far more important than when or where they work. This is something I have given a great deal of thought to and agree with in principle. However, the focus here is on the individual. What if the individual works on a team?

Teams and times
Generally I find there is a happy medium when the team is allowed some flexibility in the individual schedules while maintaining some amount of schedule overlap so that there is a guaranteed time when everyone one the team is present. In my experience this is typically 10am – 3pm. For highly interdependent work I have seen team members on healthy teams adjust their individual schedules to overlap significantly so as to not impede individual tasks purely because of individual schedule preferences.

Teams and locations
Location seems less flexible to me. Certainly technology exists to allow teams to access all the resources they may need from far flung locations, but sometimes you need more that access to just electrons. Just ask someone who needed a flaky server rebooted and couldn’t get in contact with someone who could actually flip the power switch. Admittedly access to physical devices varies by team. My current teams deal with lots of hardware add-ons and regularly visit “the lab” to ensure the product is working as expected. Whereas in my previous position the entire team could have been airlifted to Fiji and it wouldn’t have mattered much (other than their tans).

Teams need to work together
Now teams could be distributed or virtual, but I believe that teams work best co-located and face to face. The team’s output is still of primary importance, but because they are working together the where and the when become important as well. It is harder to work together if part of your team is either at a different location or a different shift or both. And if it is harder to work together the output suffers and the results are what really count.

I attended AONW last year and had a fabulous time. It was great to reconnect with some of the local practitioners and have some really interesting conversations and be introduced to new idea. If you can make it I would highly recommend attending this year. Remember, attendance is limited to the first 100 people, so sign up soon! Look me up and I'll buy you a frosty beverage of your choice.

Here is a flyer for your office

I mentioned in my No More Iterations post that we didn't really know how support requests were going to affect the overall system. As is often the case I didn't have to wait long to find out.

Within days of moving to the limited WIP approach we got a raft of support requests, several of which turned into "must fix now" types of issues. Since we had just switched, we absolutely didn't have a slot on the board (in fact we had 13 stories for a 6 slot WIP).

Since these urgent requests had to be completed "right now" we decided to go with an "expedited story" concept. An expedited story essentially trumps all other backlog and work in process (WIP) and jumps to the head of the line stomping willy-nilly all over the other in-flight stories.

Obviously we don't want to have a lot of expedited stories so we discussed having a special slot just for expedited stories that would remain empty most of the time, but would also restrict the amount of thrashing the team would experience. However, based on my experience urgent requests tend to come in waves, and telling the business that our process doesn't allow us to help more that one customer at a time is professional suicide. What we are doing is examining all the urgent requests to see if they are truly urgent, or if they could wait a few days. If they can wait we put them on the backlog and process them normally.

To help us understand what is going on over time we are going to track the number of expedited vs. normal stories as well as doing some root cause analysis so we can prevent as many expedited stories as possible in the future.

Travis has a great post on why It's Not OK To Skip The Standup.

I've decided to try out this twitter thing. Follow me.

One of my staff (Aaron) found this great post from David Bock called the 7 Question Project Health Check.

The only thing I'd add is start working on this today!

If you want to know why, start adding up the cost of not doing it. How long will it take you to recreate your build server if it dies? I've seen everything from 1 hour to 3 days or more. Assuming $100/hr burden rate and a team size of 5 that can result in a $100 cost (1 person, 1 hour, nobody is blocked) to $12,000 (all 5 people are blocked for 3 days).

You can imagine how the costs can escalate if your source code is sitting on a file server somewhere or even worse on the programmers box.

Now go calculate your opportunity cost. At one company I worked at the finance department calculated the opportunity cost for the development department was $550 per hour per person! Show that number to the CEO and the head of IT and find out how quickly support requests get resolved.

One final note: if you are relying on your people working overtime to overcome these types of issues consider how you might act differently if you had to pay for that overtime out of your own pocket.