Wayne Allen's Weblog

New Bike!

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.

12 Learnings From My First Turn As Startup CEO

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.

Ten Reasons High-Tech Companies Fail

Production vs. Attendance on Teams

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.

Agile Open Northwest 2008 - Mar. 18-19 in Seattle, WA

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.

Expedited Stories

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.

It's Not OK To Skip The Standup

Do You Twitter?

$1,000 of Free Consulting Advice

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.
 

30 Second Estimating

• Story size was difficult to estimate and kept crossing iteration boundaries.
• The programmers really didn't see the value of estimating stuff they weren't familiar with and in our planning poker session gave out lots of ? and 100 cards.
• We were spending to much time researching the time it would take to fix a bug that we weren't going to work on for several weeks.
  

After reading posts by David Anderson and Amit Rathore I started to examine why we were estimating, how much time we were spending at it, the psychic cost, and the results. The results were not encouraging.

Not surprisingly the reason we were estimating was to help the business prioritize stories. If stories X and Y both had the same value to the customer, but story X cost 10x more than story Y (where cost in my world = time) then the business had more information to base their priorities on.

The next question was how much time and effort we were putting into estimates. It turned out that we had two extremes. Either we spent 2-3 minutes estimating a story, or several hours researching a defect (another name for a type of story), but not much in-between.

The psychic cost seemed to be directly related to the time spent estimating. The quick estimating (which used planning poker) often had a background rumble if "I don't really know" which caused some resentment when the estimators had to eventually pick a number. For the more detailed research the task switching had a level of frustration built in, but by far the frustration was that once the detailed estimate was created the work itself was almost complete. Instead they had to task switch back to the planned tasks resulting in more time wasted.

Our results weren't spectacular. The stories seemed to get either 100 points or less than 5. The new unknown work was 100 and the previously researched defects were less than 5. I'm not a big believer in tracking actuals, but it was clear that each 100 point story was not taking about the same amount of time. The defects were typically completed in about the time estimated.

Given this information one could easily conclude that we just needed to do more research so that the new features could be estimated more accurately. But wait a minute, why are we doing estimates in the first place? Are we estimating to create an accurate budget, or to price a bid? In our case we are not. This isn't to say that some people need to do these things, but we don't. Rather we are estimating to provide prioritization information.

I started to wonder if we were trying to be more precise in our estimates than we needed. Enter the concept of t-shirt sizing. Each story could be estimated as a small, medium or large story.

After a few discussion we determined that our smallest stories (mostly defects) really took no less than 3 days from start to finish. So I rounded up to a week and called that a "Small" story. The next boundary to identify was the "Large" story. We decided to call anything that takes more than 1 month a large story. So anything that was between 1 week and 1 month was a "Medium".

I chose the week and month boundaries because they are easy to communicate and part of our everyday language. Remember that the estimates are going to be used by non-technical managers for prioritizing so units like ideal days and gummi bears just get in the way.

Because we now have 3 simple possible outputs from the estimating process I didn't want to spend lots of time coming up with small, medium or large. Accordingly I set the upper limit on research time to 30 seconds. Why 30 seconds? Because for the most part 30 seconds is enough time to develop a gut feel and a gut feel is close enough for the intended use.