Wayne Allen's Weblog

Oregon Motorcycle Tours announces their 2010 Tour Schedule

2009-11-02T20:54:00Z

2010 Schedule

Twist of the Wrist II Now on DVD

2009-10-14T17:02:00Z

New Tires, Self Mounted

2009-08-10T20:44:00Z

After the Oregon Desert Tour it was definitly time for a new rear tire. My 2001 Ducati ST2 came to me with an inexpensive tire with OK performance and I wanted something like I had on my 1998 ST2. I also wanted to tackle doing the work myself. After spending hours pouring over the internet I ordered a Diablo Strada Rear Tire.

The only things that had me worried as a first time tire changer was breaking the bead, seating the bead and balancing the tire. My original KLX 250S tires were not balanced and I didn't want that feeling on the ST2. I ran across Dyna Beads as an alternative to stick-on weights and I was sold. Other various sites and youtube videos convinced me that I could break the bead without expensive equipment and that my compressor was more than capable of seating the tire.

Here is the bike with the tire removed. No big surprises here except the shop manual doesn't say what size the axle nut is (30mm) and I had to go buy one.

I thought about building a home-made bead breaker, but I found that my largest C-clamp would fit around the tire and it worked great for breaking the bead.

Here you can see the end results next to the old tire - definitely time for a change.

Total time to change the tire was about 3 hours. Mostly because I was being careful and it was about 98F. I expect next time it should take me about an hour. The Dyna Beads seem to work great.

Software Engineering: An Idea Whose Time Has Come and Gone?

2009-07-21T19:30:00Z

Tom DeMarco, arguably one of the key thinkers when it comes to how we develop software has been reflecting.

My early metrics book, Controlling Software Projects: Management, Measurement, and Estimation (Prentice Hall/Yourdon Press, 1982), played a role in the way many budding software engineers quantified work and planned their projects. In my reflective mood, I’m wondering, was its advice correct at the time, is it still relevant, and do I still believe that metrics are a must for any successful software development effort? My answers are no, no, and no.

-- http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0709/rW_SO_Viewpoints.pdf

If that doesn't rock you back on your heels, then you need to re-read that paragraph.

Next you need to go read the whole article (2 pages).

As someone who prefers the agile approach I have been pushing the value based approach over the control based one for nearly a decade now. But to see someone like Tom question publicly what he (and we) have been doing for the last 30 years makes me respect Tom even more, and give me hope that as an industry we are heading in the right direction.

What metrics should you track?

2009-07-21T17:50:00Z

Jack Milunksy of Brightspark and AgileBuddy was reacting to a Agile Project Management forum topic on metrics.

Jack was of the opinion that:

the more one spends time tracking metrics, the less time there is for development

While I have some sympathy for this point of view having worked for larger organizations in the past, I have come to realize that you do need some type of metric that is understandable to the rest of the organization. All the other departments in your organization have an overriding single number that describes how they are doing, why not software development?

As I mentioned in my No More Iterations post, throughput is my metric of choice. The cost of collecting this metric is so low that it doesn't matter.

Now I have been asked to provide all sorts of low level metrics in the past not knowing how they were going to be used. I was not inclined to cooperate in those cases since the time required to collect them was never going to be offset by any value coming back to my teams. And this is most likely what Jack is protesting.

I like being proactive and providing a metric I think is useful, rather than waiting for someone who doesn't really understand software development ask me to have my teams track actual effort against estimated effort in units of 0.1 hours (really I have been asked to provide this!).

SPIN Kanban Talk

2009-06-12T22:12:00Z

My talk at the Rose City SPIN last night went very well. We had a small core of dedicated people. Lots of good questions and we could dive into the specifics. Thanks to Rhea for doing a great job organizing the event.

You can find my presentation here.

I also wanted to provide some links to some of the books and sites I referred to during the talk.

Ride To Work Day is June 15

2009-06-12T21:58:00Z

PADNUG Talk: Kanban presentation

2009-03-04T23:11:00Z

My talk at PADNUG last night went very well. We had standing room only, with many new faces. Rich and Jason run a great meeting - thanks guys.

There were a few requests to post my "slides" which I have done. Be sure to check out Prezi, the company who is making this cool presentation tool.

I also wanted to provide some links to some of the books and sites I referred to during the talk.

Update 3/28 - I forgot to give credit to Karl Scotland for a couple of the diagrams - Sorry Karl!

How to install Sybase’s ODBC driver on Ubuntu Linux 8.10 for ASE/IQ/Replication Server/SQL Anywhere/etc

2009-01-14T23:51:00Z

It is always interesting how when you are working on a problem, someone else in your sphere is solving almost the same problem. Jason posted yesterday about installing ODBC on Ubuntu for Sybase which was one of the challenges we had as part of my previous post about getting Sybase's ODBC/JDBC bridge working in our multi-platform environment..

Sybase JDBC Craziness

2009-01-14T00:24:00Z

Say you're working on an enterprise class system. Developers work on Windows and Linux. Servers run Linux. Not so unusual.

Now enter Sybase SQL Anywhere. Aka Sybase ASA or iAnywhere.

First off there are 2 different JDBC drivers. JConnect (jconn3) and the iAnywhere JDBC driver (jodbc). It turns out that only the iAnwhere driver actually works with the high availability option (although not documented).

Also it turns out that the iAnywhere driver is really an ODBC bridge and you have to specify another driver in the JDBC URL.

While a little confusing at first due to the lack of documentation eventually you can dig up an example.

jdbc:ianywhere:driver=SQL Anywhere 10;dbn=mydatabase;eng=myserver;

Everything works and you move on with life.

Except that eventually you want to deploy your new code to the server. BAM nothing works. All sorts of errors about no suitable driver found.

After thrashing around for a few days you discover that the JDBC URL must be different on Linux! (this is the only page on the Internet that specifies this).

jdbc:ianywhere:driver=libdbodbc10.so;dbn=mydatabase;eng=myserver;

Of course your application now works on Linux, but not on Windows.

Now if I were writing my own code that needed to talk to the database there wouldn't be much problem as I can use one of several techniques for figuring out which driver I should be using.

However, this URL used to configure some enterprise reporting tool which uses that same URL whether doing local report development or running from the server.

So now I have 3 options.

Install the reporting server on every developers workstation.
Stand up a Windows version of the reporting server.
Create ODBC DSNs on all affected systems.

While option #1 is enticing (I like developers to have a local copy of all dependencies if at all feasible). Feasibility plays into the picture here because of license costs.

Option #2 is certainly doable, but I am not a big fan of adding the overhead of administering another server and keeping it in sync with all the others.

Options #3 is simple and works well. However, DSNs represent another thing that needs to be set up on every developer and qa system. This also breaks my rule of being able to check out the source tree and go, even on a new computer (for reasons of continuous integration and easy new team member set up).

Ultimately we will go with #3 because it is low cost in dollars, and low cost in time (we'll write an Ant target to do the DSN setup).

Now wasn't that easy? It only took 3 days to work through in real time.

Agile Open NW 2009

2009-01-13T18:23:00Z

Agile Open NW 2009 has been scheduled for Feb 10-11, 2009 at the Ambridge Event Center in Portland, OR.

I'll be there again. If you are anywhere near Portland and have an interest in all things agile, this is a can't miss opportunity.

Agile Open Northwest, an alliance of agile practitioners in the US Pacific Northwest region, presents Agile Open Northwest 2009.

We invite you to our third annual conference. Our first conference in Portland brought together members of the Northwest Agile communities. We held our second annual event, Agile Open Northwest 2008, last year in Seattle and enjoyed another great success.

Please join us this year as we host 100 experienced, collaborative, committed agile practitioners from the Northwest U.S. (and beyond) in tackling the issues around our theme "Agile for Real."

Your commitment to arriving at the beginning and staying until the end both days will ensure we build on conversation after conversation as we engage important questions like:

What is agile really?
What does agile development look like in the real world?
Who practices agile philosophies, methods, principles or practices in the Northwest, and what's the impact?
What does agile or agility look like in organizations?
What new technical challenges face agile?
How does agile co-exist with project management, process control and other governance structures?
How do we adapt agile practices to our organizations without diluting them?
Can agile methods work in big, risky projects? How?
When distributed teams use agile approaches, what changes?

When an organization chooses a transition to agile, what really changes?

The Northwest has a wealth of practitioners with years of real-world experience with agile methods and self-organizing teams. Agile Open Northwest offers an opportunity to strengthen our community of practice and co-create the future for agile development in our region. Feel free to browse the list of currently registered participants.

Your hosts designed this event to allow practitioners like you to meet in self-organizing groups where we can share our latest ideas, challenges, hopes, experiences and experiments. We follow an Open Space format to foster collaboration and allow the conference to take its direction from the participants themselves.

What: An Open Space event discussing agile practices and techniques.
Where: Ambridge Event Center, *new* location near the Convention Center and Max line, 1333 NE MLK Blvd., Portland Oregon
When: February 10 and 11, 2009
Who: Anyone with some degree of experience in agile methods.
Cost: $125 per person, including lunch both days

A comment from a previous attendee:

"These two-day Agile Open Northwest conferences are an extremely good value. ..[Y]ou learn directly from practitioners in the agile community what works and what doesn't. I attended the first two of these conferences, they were stunningly good... loads of practical, useful stuff and stimulating discussions." -- Ian Savage, PNSQC Program Chair

Speaking about Lean Software/Kanban at PADNUG on Mar 3, 2009

2009-01-13T16:57:00Z

I'm be speaking at the March 2009 Portland Area .NET Users Group (PADNUG) meeting.

I'll be covering a different project management approach to product line development that includes:

Reduced meetings
Clear priorities
Minimal multitasking
No estimating

Screaming Yellow Duc

2008-10-31T20:29:00Z

Yes another motorcycle post.

After riding the other bikes this summer there was just something missing from the KLX 250. Primarily my wife. We were both missing the enjoyment of heading out for an hour or two on the weekends or a warm evening riding tandem. We know this might be an issue we we purchased the KLX, but figured we'd save up some money and deal with it next summer.

Fast forward to the present. I'm hanging around the dealership waiting for the service department to put some new tires on the KLX. The showroom is completely dead and I didn't bring anything to occupy my time, so I'm wandering around admiring the bikes. One of the salesmen strikes up a conversation as they are likely to do. Eventually he gets around to asking me what kind of bike I'd be interested in if I was really looking.

I'm honest with him. I say I'd be interested in something for riding 2 up. I've been here a few times and know they don't really have much in that category, but I've got time to kill and salesmen always have a bunch of good stories. He takes me through their limited inventory - a FJR, and a Concours. Both are nice bikes, but I'm not really into buying new off the showroom floor.

He detects my lack of real interest and asks what I'd really want. I say I'd be really interested in a Ducati ST4, knowing that the local Ducati dealer has this market pretty wrapped up. To my amazement he says hesitantly I think we have one of those.

I'm stunned for a moment. Then I come back to my senses. Most Ducatis are sports bikes, not touring bikes, it is extremely doubtful they really have what I'm looking for. Nevertheless I follow him outside where some of the used bikes are on display.

We walk down the line of bikes and by this time I'm not expecting much, but then I see it. A 2001 Ducati ST2 in yellow! Now ideally I would love to have on in Ducati red, but at this point I don't really care to much. It has only 5,500 miles and the price is reasonable, but not amazing. I hem and haw. He asks me how much I'd be willing to pay. I tell him a ridiculously low number. At this point he reveals that it is a consignment bike and if I want we can write up an offed. What the heck, I've got time to spare and worse case I go home with nothing.

While we're writing up the offer my wife shows up (she was going to take the old, but still serviceable KLX tires home). I give her the tour and the salesguy finds the key so we can listen to it. It sounds fantastic with the Fast By Ferracci carbon fiber pipes on it. She is excited, I'm excited. We talk, we decide how much we'd really be willing to pay. The salesman comes back with a counter offer and is willing give up the consignment fees.

We now own a nice yellow 2001 Ducati ST2.

The next weekend wasn't so nice but a few of us went for a ride anyways. We got wet, but had fun just the same.

Interestingly each one of us owns a different kind a bike, a standard, a cruiser, a dual sport and a sports bike.

Evolution of a Kanban board

2008-10-30T22:08:00Z

In No More Iterations I showed our 1^st attempt at a kanban board. Now that we have a little more experience I'd like to show you where we are now and where we stopped on the way.

Here is where we started. Columns for backlog, blocked, in progress and done. Notice the large number of items "in-progress" even though there are only 7 people on the team (can you say multi-tasking?). In fact this was pointing to the fact that developers were building stuff faster than QA could consume it. One bottleneck identified.
	Here is the same board a few weeks later. Note the new column for blocked work in process (WIP) and that the number of in process stories has been reduced significantly. The number of completed stories increased dramatically. We accomplished this by focusing on getting stories done rather than just doing "work". That meant of course that programmers helped out with QA type tasks. It also meant that programmers had time to do some of the environmental cleanup activities that everyone always wants to do, but never has time to do them. Turns out we had time, we were just covering it up with other work An interesting side effect was that developers were not used to having "idle" time and this was very disconcerting for many weeks. It seemed like they were waiting for the other shoe to drop - i.e. some manager was going to come in and yell at them for not working as hard as possible.
This is a task board the team put together to identify the tasks required to complete the stories in the WIP. The idea here was to let other people know what was remaining to be done so that team members could help each other out or at least not step all over each other.
	Here is the next evolution of the task board. The WIP stories are listed down the first column and the various internal states are the remainder of the columns. The sticky notes are the actual tasks that need to get done (color is meaningless).
Here is a combination story task board from a different team. They chose to run the stories across the top row with spots for Backlog, WIP, Blocked and Done. The WIP stories get moved down to head the row just like the other team did. For this team they did use color and sticky dots to indicate various items, but honestly I've forgotten what them meant.

So where are we now? Interestingly things have been going smoothly for awhile so I had to wander over into the team spaces to be sure I remembered correctly. If you've followed along above you may have noticed that the boards got more complicated as we went. Since then we've been simplifying. Also we've gotten used to working this way and it turns out that if you work on a limited number of things, minimize multitasking and talk to each other there isn't much need to use up a big whiteboard with sticky notes.

That's right - we no longer have a kanban board. Now that isn't to say we've abandoned the concepts, we've just determined that we don't need the big visible board.

Currently tasks are being tracked in Extreme Planner and stories are being tracked in a spreadsheet by the project manager.

I use a parallel spreadsheet without all the gory details to help the stakeholder prioritized work, see what is in process and what various releases might look like.

In a way I schedule the entire department on a single 8.5 x 11 piece of paper that has its roots in our very first kanban board.

Throughput vs. Velocity

2008-10-23T21:56:00Z

Throughput and velocity are ways of measuring how fast a team can do work. Knowing how fast a team is going allows the team and their stakeholders to know when something is going to be done.

What is Velocity

Velocity (http://www.extremeprogramming.org/rules/velocity.html) is a commonly used metric for teams using Extreme Programming or Scrum as their guiding principles for software development. Velocity is a unit-less measure that tells the team how much work they should take on each iteration or sprint.

A simple example of calculating velocity:

At the first sprint planning meeting the team estimates the top 10 stories and believes that they can complete 6 of them in the next 2 weeks based on the following estimates.

Story	Points
A	3
B	5
C	1
D	5
E	2
F	1
Total	17

At the end of 2 weeks stories A-E are complete and F is started, but not complete. This teams velocity is 16 point per iteration, or about 32 points per month. Note there is no credit for partially done work. The next iteration the team estimates stories until they have stories that add up to 16 points. At the end of the iteration they measure what was actually completed and repeat until the project is done.

Velocities cannot be compared across teams because velocity is derived from estimates created by the team and since no team estimates the same way it is impossible to compare them.

Velocity is also not a productivity metric. Wanting to see the velocity have a constant increase is like asking to increase the speed of light. Velocities do vary over time due to various factors (like the fact that software is complex), but tend to stabilize if the work and personnel are not fluctuating too much.

What is Throughput

Throughput is not commonly used in software development, but is becoming more prevalent with the introduction of lean concepts. Throughput is most common when using a kanban scheduling board (http://blogs.consultantsguild.com/index.php/wayne/2008/02/01/no-more-iterations) to help manage the delivery of stories.

Throughput is the number of things that can be done in a given period of time.

A simple example of calculating throughput:

The team pulls the highest priority item off the backlog and works on it until they are done. They note when they started the story and when they finished it. They do this over and over until the project is over. Every month someone summarized the information about the stories that were completed.

Story	Started	Competed	Duration
A	Jan 1	Jan 4	3
B	Jan 4	Jan 12	8
C	Jan 12	Jan 13	1
D	Jan 13	Jan 25	12
E	Jan 25	Feb 3	9

This team completed 4 stories in January so their throughput is 4 stories per month. Each story takes on average 6 days to complete with a standard deviation of about 5 days. So 90% of stories are completed in 6 days +/- 5 days. With additional data the standard deviation should tighten up unless you have large variance in story size on a regular basis. Even though story E was started in January we don't count it because it was not completed in January. It will go into February's stats.

Since throughput relies on actual start and finish times we can derive a predictive measure for forecasting without any estimating.

Note that duration ignores the fact that some days are weekends.

Like velocity throughput is a team specific number and cannot be compared across teams.

Challenges with Velocity

Velocity is based on an abstract unit such as Story Points (http://en.wikipedia.org/wiki/Story_points) that are not always easy to explain to stakeholders (or even the team sometimes). Stakeholders often want to know how many days a story point represents. Since story points are relative to each other there isn't a direct mapping, although many team do grudgingly come up with an equivalence. To get around this some teams estimate in ideal or engineering hours. Unfortunately the same questions get asked. "How do I convert your funny agile units into days?" See also http://www.think-box.co.uk/blog/2006/02/ideal-time-vs-story-points.html

Velocity also requires the team to spend time estimating the stories. I'm not sure I ever met a developer who enjoyed estimating and even with planning poker (http://en.wikipedia.org/wiki/Planning_poker) most team member do what they can to get out of the estimating meeting yielding less than useful results. One team I know of estimated everything as "?" once they got tired.

As in all estimation the results are only as good as the information at hand. When you are estimating something you've never done before the accuracy can be all over the place.

Challenges with Throughput

The big knock against throughput is that it requires you to have relatively similar size stories in your backlog. This is true to a point. If your stories are not of a similar size your standard deviation will be larger leading to a larger range in your completion date predictions.

Which to Use?

In my context (stable teams working on product lines) I prefer the kanban/throughput combination. We don't have the dreaded planning meeting and we are still able to tell our stakeholders how many stories they should plan on having in the next release.

If you are currently using velocity it is very little overhead to start tracking throughput as a way to double check what your velocity metric is telling you.