Wayne Allen's Weblog

SPIN Kanban Talk

Wayne Allen — Fri, 12 Jun 2009 22:12:00 GMT

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.

Software by Numbers: Low-Risk, High-Return Development
Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results (Coad Series)
Lean Software Development: An Agile Toolkit (Agile Software Development Series)

Ride To Work Day is June 15

Wayne Allen — Fri, 12 Jun 2009 21:58:00 GMT

PADNUG Talk: Kanban presentation

Wayne Allen — Wed, 04 Mar 2009 23:11:00 GMT

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

Wayne Allen — Wed, 14 Jan 2009 23:51:00 GMT

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

Wayne Allen — Wed, 14 Jan 2009 00:24:00 GMT

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

Wayne Allen — Tue, 13 Jan 2009 18:23:00 GMT

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

Wayne Allen — Tue, 13 Jan 2009 16:57:00 GMT

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

Wayne Allen — Fri, 31 Oct 2008 20:29:00 GMT

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

Wayne Allen — Thu, 30 Oct 2008 22:08:00 GMT

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

Wayne Allen — Thu, 23 Oct 2008 21:56:00 GMT

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.

Corey Ladas explains Scrum-ban

Wayne Allen — Thu, 21 Aug 2008 16:28:27 GMT

Cory has a great post titled: Scrum-ban | Lean Software Engineering. In it he describes how a team can take advantage of kanban within a Scrum environment.

While I am sure that there will be those who insist that Scrum doesn't need to be improved, there are those of us who learned Scrum, practiced Scrum and are aware of it's limitations and want our teams to get even better.

Personally I like kanban for the context I work in. When I explain how we develop software I always try to make sure the other person is aware of the context I made my decisions in and how in other contexts I would not make the same decision.

For instance we do not estimate each individual story (although for a short period we did 30 second estimating). We have collected enough data about our performance that we know how many stories per month we complete (~10). Part of this context is a stable team that knows the software and a mature product.

Back in the day I lead contract teams doing work for state and local government. In that context I would go back to estimating because the contracts tended to be fixed price and the team was pulled together just before the project started. Different context, different practices.

Another New Bike

Wayne Allen — Thu, 07 Aug 2008 18:56:00 GMT

Previously I posted about my new V-Strom which is a nice bike. However, after taking it on something more difficult than gravel roads and compared to my wife's Honda CRF150 I knew I needed something much lighter, more dirt oriented, but could still be ridden on the street.

After much research I initially narrowed it down to the Kawasaki KLR 650, Honda RX650L and the Suzuki DR650. The KTM and BMW were out of the picture because of cost. My lingering concern was the weight of the 650s.

So what did I buy? A Kawasaki KLX250S!.

Why did you buy such a small bike after owning (and enjoying) those liter street bikes? Well, basically it was time spent riding the CRF150. I knew that the 250 would be able to take me anywhere I wanted to go, and it easily does the legal speed limit. What more do you need? (well actually I'm saving my pennies for a Ducati ST4 for my wife and I to do 2-up riding.)

The “Why To” Manual

Wayne Allen — Thu, 07 Aug 2008 17:36:53 GMT

Hank Wallace turned me on to a post by Allison Shapira where she summarizes a key point from Rob Walker's writeup of the Blue Man Group - the "Why To" manual.

This "Actors' Journal" is not so much a how-to manual as a why-to manual; it's not about stage directions, but rather tells the story of the show step by step, from the point of view of the Blue Men. As a decoding and deconstruction of Blue Man's at-times baffling, even mystical behavior, it's a fascinating document, thick with references to everything from Being There to George Bernard Shaw to Robert Motherwell to the caves of Lascaux. Some explanations are straightforward — "The Blue Men are not aliens" — and others are more subtle, as when the trio's harmonic "three as one" relationship is described in terms of "blesh," a mix of blend and mesh borrowed from Theodore Sturgeon's science fiction novel More Than Human.

What would a "Why To" manual look like for a development team?

Miško Hevery on Writing Testable Code

Wayne Allen — Thu, 07 Aug 2008 16:40:31 GMT

Miško Hevery has written a great summary of some basic coding rules for testability in his post Writing Testable Code.

I love this quote because every time I introduce unit testing to someone who has an existing code base you can see this in their eyes:

"I understand how to write tests for your code, but my code is different"

He goes on to list the rules most often broken by developers that make unit testing hard in his top ten list:

Mixing object graph construction with application logic

Ask for things, Don't look for things (aka Dependency Injection / Law of Demeter)
Doing work in constructor

Global State

Singletons (global state in sheep's clothing)

Static methods: (or living in a procedural world)

Favor composition over inheritance

Favor polymorphism over conditionals

Mixing Service Objects with Value Objects

Mixing of Concerns

New Bike!

Wayne Allen — Mon, 17 Mar 2008 20:47:00 GMT

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.