When we read the Scrum Theory we note that one pillar is transparency and that “significant aspects of the process must be visible to those responsible for the outcome”.
A noble statement, but one that often competes with “first impressions” last. While we strive to gather candid feedback for an iterative approach to innovation, we often realise that the user’s first impression is imprinted on a solution for its entire lifetime.
Should we be transparent while we are prototyping our solution? In this case we are showing a test of synchronising and firing 3 solid state rockets at the same time. It could equally be a rough Windows Form or Console application, “quickly” crafted to validate some core logic during a spike.
My 2’cents … we should be transparent from the start, but ensure that we have a common language and understanding of the definition of done (DoD). In other words, if a solution is in its infancy, the user interface is rough, or you are demonstrating something that does not meet the DoD, make sure you emphasise it up-front to influence when the user performs an immutable “first impression” snapshot.
PS: In case you are wondering. We finished the 180cm, three-stage hobby rocket, with 3-engines and 2 parachutes in the first stage, 3-engines and 2-parachutes in the second stage, and 1 engine, 1 parachute and a very expensive tracking device the third and main stage. We eventually clicked the “launch” button. There was lots of smoke, the outer engine of stage 1 misfired, the rocket took an unexpected trajectory, my colleague who was filming dropped the camera and ran. We leave the rest of the ensuing mayhem to your vivid imagination.
No-one was hurt, it was fun and my “first impressions” of a 3-stage hobby rocket are imprinted for life