In the prior post, Units Of Value, I said that defining the units of value is key to understanding and delivering what your customer needs. In order to create a delivery plan, you need to construct a repeatable process for converting units of value to units of work. This is difficult when a software development…
Uncategorized
Units of Value
Planning a software development project is difficult. There are the typical issues: the changing face of technology, abstractions and generalizations, process maturity and resource competency. But none of this gets to the heart of why planning a software development project is difficult: because all of these things assume that the customer actually knows what they…
Emergent Requirements
Glen Alleman in his Herding Cats blog, asks some really good questions about emergent requirements. Since Glen is always and forever explaining that domain has everything do do with process, this appears to be another example, where the domain that he is in does not have the same sources of requirements emergence, that the business…
Leading by Naming
There is power in a name. Primitive cultures often believed that to know the name of something or someone is to have power over it. Much superstition, and "magic" or spell casting has been based in this principle. It fact, even in more modern religions, exorcism can require the name of the possessing power, and…
Leading by Asking
Sometimes we need to learn to lead by asking. As a leader, we need to correctly frame the question, so that those we are leading will get the answer themselves. By asking questions, we are helping those we are leading to draw their own conclusions. In fact, we are providing direction, by asking them to…
Design Assumptions
Pragmatism – design assumptions are about pragmatism. Pragmatism is the easiest path to good enough. If I already have tools available that will allow me to do the job "good enough", why would I go buy and learn new tools? If I already have a team that supports 5 applications written in Java, why would…
Scope or Generality
In a discussion with a colleague this week, I was trying to articulate how writing business capability requirements can help guide both development and software acquisition processes. My explanation apparently was not very good, because he definitely got the impression that I was talking about some super strategic high level requirement that was not really…
When Scope Is Variable
I have been working on an "Agile" product with our IT Project Standards and Governance group at work. When analyzing the values and principles that are espoused in our "gated" product, I realize that the difference between agile and traditional (waterfall) project methodologies is singular. There is all kinds of hyperbole around why agile solves…
Software Capability Requirements
As stated in Business Capability Requirements, software capability requirements are correlated with a business capability requirement that answers the key questions why and how much. Systems designers, architects, and developers are better equipped to propose solutions, when they are aware of the benefits or value that a requester is expecting for their investment. They are…
Metaphor Exploration
When evaluating a software product, one of the most important things to understand is the core metaphors around which the software is built. Why do I use the term metaphor, rather than entity or concept? Because a metaphor is a substitute, a proxy, and in software, the core concepts are proxies for real concepts in…