Blurring the Boundaries
We have been running our own small business for more than 7 years now, and from most accounts, everything is running quite smoothly. While the pipeline has thinned a little as training budgets are slashed, there are indications that even this is turning around. Receivables have been very good, something that I would attribute to personally knowing who cuts the cheque in most places (the biggest challenges have come from the biggest vendors, where I am an anonymous ‘little guy’ with no apparent clout, but I have my ways to get things done there as well…). There remains one area that I struggle with – the traditional boundaries of the workplace. Read more
Agile Hype: VanDev Podcast
There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity. – Fred Brooks, from his No Silver Bullet essay
It has been almost 8 years since seventeen men got together in Utah to craft the Agile Manifesto. Since then, depending on who you listen to, agile practices have either totally turned the software industry around, or we are witnessing the latest attempt at defining that silver bullet. Read more
Podcast: Play in new window | Download
Fables and Legends
One of my favourite diversions from what can otherwise be a ‘death-by-PowerPoint’ event when I facilitate a survey of requirements techniques is the telling of a fable. I take one person aside and read out a one page East Indian fable. That person is to recite the fable to someone else, and so on until everyone in the class has heard it. The last person gets the dubious honour of telling what’s left of the story to the class, and it usually only takes a sentence or two before the group is in stitches. It is the old campfire game (or telephone tag, depending on your childhood experiences), with a moral that applies to how we collaborate. Read more
Art and Science
The March 2009 Edition of Harvard Business Review has an excellent article entitled ‘When Should a Process be Art, Not Science?’ Many great insights, but as with most things that we try to categorize, there is primarily a sense in the article that we need to choose, that the answer be one or the other: art or science. Relegated to a sidebar is the notion that science can be a platform for art, which I see as the primary insight in the article. This is something that anyone that works in that ‘process’ niche should think deeply about, even if you are like me and prefer to not utter that ‘p-word’ too loudly. Read more
Driven to Distraction
From what I have seen, many ‘process improvement’ initiatives have failed to live up to expectations, and some have definitely done more harm than good. Perhaps this is because even the term ‘process improvement’ implies a distraction from the real point of the exercise. Read more
Rabid Dogma
Proposed approaches to building products, software or otherwise, will come and go. One thing that seems to be constant through all this change is that the voice of the latest and greatest is convinced that they have solved the problem once and for all. Read more
Fatigue
In many shops, big or small, software or otherwise, agile or traditional (as if that were a true dichotomy) we see fabulous energy in projects where people are committed to delivery. Unfortunately, in too many shops, we also see the down side of fatigue. Sometimes after the project completed (if you’re lucky), but often while the project is trying to progress to completion, the many symptoms of fatigue can have tremendous costs. Read more
Pair Everything, To a Point
Pair programming is one of the agile practices that has most polarized people on both sides of the fence: sitting two people down at the same screen and keyboard to develop a piece of code. Having experienced this practice over 25 years ago and finding it to be extremely productive, I’m in favor of it being applied more than it is now. In fact, I would advocate pairing up (or more) for almost any practice we apply in the process of building our products. Read more
Agile Too Early
Almost everyone is familiar with Dr. Bruce Tuckman’s team model of Forming, Storming, Norming and Performing. This describes a sequence of stages that teams will naturally go through, whether this is consciously managed or not. Some teams never quite make it past Storming, and some seem to get through it relatively unscathed, only to lapse back later. As with many models, teams often exhibit traits of more than one of these stages at the same time, so its linear presentation may be a bit misleading. That stated, though, the model is a succinct and extremely applicable way of describing overall team growth. If we tie this model to a couple of others, though, we get a few more very interesting insights. Read more
Two Analysis Schools
Over the years, I have seen two distinct analysis schools of thought. There is the ‘let’s get this over with so we can start doing the real work’ school and the ‘let’s work through the tough problems now so that our implementation is straightforward’ school. There appears to be a gradual migration from the first to the second in the industry, but the first continues to be fueled by a lack of appreciation for the value of effective analysis in the educational system. Read more
Clarrus Proudly Sponsors VanQ
