Of course this title has everyone asking “What in heck is an inch pebble?”, right? Well I was first introduced to this term by Johanna Rothman in an article she wrote about a hundred years ago. While I read it, and intuitively understood it, it didn’t at first occur to me that it was a comparative analogy. Until today…Continue Reading
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
At the core of every software product road map are two concepts. These are essential to all software product development. We may think of different things, and we may use different terms or even look at them from different angles but at the end, I am convinced that it boils down to only two things:
in my experience, every other thing we do when we build software is a component, or is connected to one of these concepts. I think often that what gets us screwed up, is that that we focus on the “every other thing” from some methodology, or some playbook, or some consultant, and lose the plot on the essentials.Continue Reading
I am in the middle of my umpteenth system replacement project. There are some universal assumptions that are endemic to the user community in every system replacement project. They are born of hope and frustration. They are almost universal.
1) The new system will do everything the old one does, only better.
2) The new system will support all of my existing processes and procedures without significant change.
3) The new system will be faster that the old system.
4) The new system will have better data quality than the old system.
5) The new system will address ALL of the shortcomings of the old system.
If you have ever done one of these projects, you know. They are assumptions that you must actively work against. They require a constant stream of communication to dispel. I offer you my rationale for why they are never, ever, true.Continue Reading
Leadership must recognize that momentum is lost when decisions are anti-climactic. As a leader, it is tempting to focus on the decisions as your primary responsibility – but that is only half of the problem. When decisions are not incisive, are not positive, result in no obvious actions or next steps – our responsibility is to keep the team from getting demotivated, confused, or de-focused. Continue Reading
Spinning. Wheels are spinning. We go around in circles. Progress is illusory. Just when we think we are “getting somewhere”, we realize we are right back where we started. Its frustrating. I bet you’ve been there. I bet you’ve experienced this feeling in many different ways.
I have heard it called many things: “Paralysis by analysis”, “Chasing our tail”, “Go fetch”, “The circular imperative” to name a few.
The symptom is that no matter how we try, we can’t convince “them” to sign up and move forward. The team won’t adopt the recommended pattern. The boss won’t sponsor the proposal. The customer won’t sign the contract.Continue Reading
Read this great line from Johanna Rothman’s Hiring Technical People blog:
When you are unemployed, your job is to get a job. If you do other work, you better have a great reason.
It so correlates with the book I just finished on Friday “The War of Art” by Steven Pressfield which completely expands the topic to how we tend to find ways to not do what we are really called to do.Continue Reading
2013 was the year that I finally decided to replace my ancient two channel sound system with a 5.1 channel home 
theater capable system. My old setup was very simple. A pair of ADS speakers that I had bought when I was in college (1981) and a Nakamichi receiver that I had bought shortly after I was married (1989 or so). I had other components, but most had been replaced with a cheap Blu-ray player that I “won” at a silent auction a few years back that played most of my CD’s. I still have a B&O turntable that is serviceable, but I rarely play my vinyl these days.Continue Reading
Every programmer struggles with providing estimates. It is a universal truth of software development. Most of the time we go way too deep, try to be more precise than we have any reason to be. Many times we have fear driving our estimates – what if they are too big (will they cancel the project? or will they assign the work to someone else?) or worse, what if they are too small (will they fire me because I appear incompetent?).
Here are my top six tips for solving estimation challenges in software development projects:Continue Reading
Glen Alleman in his post How Long Should Tasks Be gets to the heart of an important issue. When planning, how long can you wait before you know that you are late.
In principle, it works like this – you don’t know you are late until you fail to complete a task on schedule. How late you are depends on the remaining work in the late task. How long can you wait to determine that a task is behind schedule? That depends on where you are on the project timeline and how much “margin” is remaining in the plan.
In practice there are other dependencies. Measurement frequency is important. The more frequently you measure progress against the plan, the smaller tasks increments you will naturally prefer. You want to see progress at every measurement cycle.Continue Reading