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
In my last post on Software Capabilities and Feats I said that feats are better [to model in a software capability] than processes, because processes are merely organized, consistent, managed ways to accomplish the feat.
A process is one way to accomplish a feat. The feat is the result you want.
Process is constrained by capabilities. So when I am modeling new capabilities, I should not be constrained by existing capabilities. When I introduce the new capability into the wild, the process will need to “re-form” around the new capability.
A process has steps. If we build software capabilities to support a process, we treat the steps of the process like “feats”. I can model a capability to make that step faster or more effective. That assumes that the step is necessary. In order to decide whether a process step is “necessary” I need to understand how it contributes to the valuable result. I need to understand why I do the step.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
It is always better to spend the least amount of (time, effort, money) to get what you want, right? If I can get a tasty meal for $10 why
would I pay $30 or $200 – for the experience of eating – that isn’t about taste. That is a different thing, isn’t it. We have different priorities for eating – being full, healthy, tasty, being served, fast service, being able to relax, a pleasant experience, being able to brag about my meal/experience. Each of these is a different reason for selecting a dining experience. Each of them is valuable to some people some times, but not all people all the time. The way we choose to spend our money to eat is not that different than the way we choose to spend our money on software capabilities; there are different reasons why we prefer one capability or a means of delivering a capability over others.
These are the principles that I use to guide my story elaboration – and thus my ability to challenge those who would ask me to do more than the minimum…Continue Reading
Do you remember the last time you moved? Do you remember packing some boxes so full, that they were too heavy to lift after you were done? It happens. Especially books and vinyl records. When you are packing “regularly shaped” high density items, the volume of the box may be too large to contain the weight of the items. Or it may be that the lifters (I mean you) may not have enough momentary work capacity (strength) to carry the box.Continue Reading
While I will not claim to be an expert at writing user stories, I am experienced. It is not always enough to simply follow the pattern. Like any analysis pattern, there are some things that one can do to improve their stories. Continue Reading
I have been “doing” user stories for a while, years now. I have been doing them mechanically without thinking about what makes them “good”. Not that I haven’t been working to make them better with each release on every project. My user stories have consistently grown better following the INVEST pattern. What I haven’t been thinking about is “why” user stories and the process through which we create them is good.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
In my former post about progressive elaboration, I promised some “examples” from different domains of software development. This is the first of these. As I said before, progressive elaboration is about acknowledging that we can’t know everything we need to get to done before we start.
One of the difficulties of requirements elicitation is to maintain a consistent level of detail, both in documentation and in our conversation with practitioners, subject matter experts, and individual contributors. Another typical difficulty is understanding whether requirements are sufficient to begin some subsequent activity like design or coding.
While some methodologies have made recommendations, most merely call out the need. This leaves it up to the requirements analyst to build their own practice. In fact, most analysts do not subscribe to any specific methodology that they practice. I have often used these interview questions for analysts that I expect to elicit and organize requirements for software applications.Continue Reading