![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jducoeurI'm continuing to think about ways I could contribute to the local tech-entrepreneur scene (which led to yesterday's question about basic programming principles). It occurs to me that it might be quite useful to give a talk on "The CEO and the Successful Software Project": what the CEO (especially for a startup) needs to know about managing an Agile software project, what they need to provide to the team, and what they can and can't reasonably expect from it. A large fraction of the entrepreneurs I'm meeting don't have any formal tech background, and probably mostly don't know this stuff.
(Note that this is specifically Agile from the upper-management viewpoint, so it's all about the "API" of Agile. I love pair-programming and automated testing and all that, but they're mostly irrelevant; OTOH, the rationale for the story stack, sprints, and the customer representative are vitally important.)
So I started thinking about what I might say, and this was one of the first things that came to mind:
That quickly led to:
Do folks have other suggestions along these lines? I'm curious how far we can carry this metaphor before it breaks, while helping to illuminate the realities of software projects from the management level. And more generally, what would *you* like the CEO of a small software-focused company to understand?
(Note that this is specifically Agile from the upper-management viewpoint, so it's all about the "API" of Agile. I love pair-programming and automated testing and all that, but they're mostly irrelevant; OTOH, the rationale for the story stack, sprints, and the customer representative are vitally important.)
So I started thinking about what I might say, and this was one of the first things that came to mind:
The Uncertainty Principle: you can fully understand your feature set or your schedule, but never both. The more precisely you try to understand one, the less confidence you can have in the other.I believe that's a straightforward lesson from the history of software development.
That quickly led to:
The First Law of Project Motion: the more precisely you attempt to understand the full scope of the project, the more inertia you add to it, and the more slowly it will move.I'm liking this general approach -- it makes for good, pithy slides that I can then dig into and explain *why* these are generally true.
Do folks have other suggestions along these lines? I'm curious how far we can carry this metaphor before it breaks, while helping to illuminate the realities of software projects from the management level. And more generally, what would *you* like the CEO of a small software-focused company to understand?