I was watching a YouTube on Why Scaling Agile Doesn't Work and How to Fix It when I had my Aha! moment about some in the Agile community that makes statements that don't make sense in my domain.
I work where we have a pretty good understanding of what Capabilities are needed for the success of the project.
- Build a spacecraft to fly 4 astronauts to the Space Station, dock, stay for six months, return to earth and live to tell about it.
- Fly to the Hubble Space Telescope, change tie Wide Field Camera, attach the De-Orbit Module, and do no harm to the Telescope.
- Develop and deploy a provider enrollment system to move the cost of enrollment from $11.00 to $7.00.
- Install an updated Guidance and Navigation system for the HellFire Missle deployed on the OH-58.
- Develop and deploy an automated landing system for the F-18, to have it catch the Number-3 wire hands off.
In our domain, we have well-formed Capabilities Statements in a well-defined Capabilities Based Planning process.
Here's the Aha!
Many in the agile community have no clue what Capabilities are needed for their products since their customers don't know that until they see the working software. This doesn't mean those capabilities could not be discovered - that's the role of product market research. But it may be cheaper just to start building software, get the feedback and build new software - may be on a daily basis.
What's not addressed by these just build it advocates is what the Value at Risk for building the wrong thing. But that's another topic.
When you hear someone suggest something that doesn't make sense in your domain, you're probably right - it doesn't make sense in your domain.
Ask in what domain are you making that suggestion?
And, why do you think what works in your domain will work in my domain?
