 |
| Photo by Startup Stock Photos on Stocksnap.io |
The environment was tense and nerve-wracking. Freshly dry-cleaned suit, neatly creased pants and lightly gelled hair, everything I could prepare for a new job was engineered for perfection. I even had a brand new ball pen with a brand of the technology I was here to consult about. The funny thing about the pen last evening: I travelled one and a half hours on the sweaty London Tube, battling my fear of bed bugs. As I said, I had everything engineered to perfection.
I was eager to impress my clients with my skills, but also aware that I could quickly end up in the doghouse. I approached the challenge with the same confidence level as a penguin in a tuxedo - not exactly built for success, but willing to waddle forward anyway.
I was the 21st team member; the last twenty filled multiple positions across the development spectrum. The project template was nothing new; Someone sold the idea of twenty people at different levels to the client. They bought it. There was just one problem - no solid requirements or plan. A vague idea that all the lines of business had to go live together.
This situation is not new.
We have often landed in a position like this, where the client has a sliver of an idea; they have paid Salesforce billing but need to figure out where to begin. A Solution Architect is only as good of a help as the requirement provided for the project. There is only a solution if there are requirements.
It is a no-win situation- a Kobayashi Maru.
The Kobayashi Maru is a Star Trek training exercise designed to test Star-fleet Academy cadets' character in a no-win scenario. The test is famously unbeatable and is designed to evaluate how cadets handle a situation without a clear solution.
Captain Kirk famously beat Kobayashi Maru by reprogramming the simulation and winning the no-win situation.
And there is a lesson here. When there are no requirements but a vague idea of a project, there is a need to bring the concept of a minimum viable product.
A minimum viable product is a basic version of a product with enough features to satisfy early customers and gather feedback for future development. This vital process allows clients to validate their vague ideas, reduce development costs, and make informed decisions on what features to prioritise. With an MVP, we can test the waters before investing heavily in development.
More importantly, we can get a team of twenty-one moving in a direction. Planning an MVP is a small portion in the grand scheme of things, but it's a start. The stakeholders get something solid in their hands; they have a system to feel and explore, bringing out the picture even more clearly. The ever-daunting task becomes bearable, manageable and achievable.
Suddenly, we see the end goal in sight.
So, have you ever found yourself in a Kobayashi Maru situation before? How did you handle it? Let me know in the comments below!
TL;DR
- When I was starting a new job as a Tech Architect, the project had no solid requirements or plan, just a vague idea.
- We created a minimum viable product scope to validate vague ideas, reduce development costs, and make informed decisions on what features to prioritise.
- Planning an MVP is a small portion in the grand scheme of things, but it's a start.
- The stakeholders get something solid in their hands, making the ever-daunting task bearable, manageable, and achievable.