August 2008 - Posts

Corey Ladas explains Scrum-ban

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.

Posted by Wayne Allen | with no comments
Filed under:

Another New Bike

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.)

Posted by Wayne Allen | with no comments
Filed under:

The “Why To” Manual

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?

Posted by Wayne Allen | with no comments
Filed under:

Miško Hevery on Writing Testable Code

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:



  1. Mixing object graph construction with application logic

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

  4. Global State

  5. Singletons (global state in sheep's clothing)

  6. Static methods: (or living in a procedural world)

  7. Favor composition over inheritance

  8. Favor polymorphism over conditionals

  9. Mixing Service Objects with Value Objects

  10. Mixing of Concerns

Posted by Wayne Allen | with no comments
Filed under:
More Posts