When you look at software development or corporate change projects, you often see some creative fiction. There is fiction in the plans, fiction in the designs and fiction in the requirements. This fiction is created by the notion that “Before we can start, we have to know everything required to get to done.”
Intuitively, we all know that this is not really true. We all know that information will “emerge” from our activities that will change how we get to done. We learn from our mistakes. We try things that don’t produce as good a result as we want. We clarify our understanding of the problem as we demonstrate portions of the solution.Continue Reading
I have been away from this blog for a while. In fact, I don’t remember when I last posted (I looked it up it was May.) In my hiatus, I have worked on some other writing projects and spent some time with Zed A. Shaw’s excellent “Learn Python the Hard Way”. As a matter of fact I. will post my impressions of that book soon. Preview: It is an interesting take from an interesting guy at solving the coding bootstrap problem.’
Today I want to talk about something else that has been bothering me for a while. The notion of an elastic software delivery staff. This is not a new problem, in fact, it is as old as software. Fred Brooks wrote “The Mythical Man Month” almost 40 years ago, based on experience almost 50 years ago. I was introduced to that book in 1984 while I was studying computer graphics with Sam Uselton at the University of Tulsa.
When you haven’t tried to “run” a software delivery team or project, the tremendous wisdom in that book pretty much goes in one ear and out the other. You don’t have the experiential context to comprehend the problem space. When I read Scott Adams brilliant Dilbert comic strip today, I see much of the same problem space. There are types of work that don’t scale well. Our traditional strategies for elastic staffing that developed during the industrial age don’t really work effectively for this kind of work.Continue Reading