Show, Ask, Adjust #

I have yet to work on task, let a lone a project, that I could make it to be ready for production from requirements alone because no matter how many wireframes you draw or diagrams you make, nothing beats using the product hands-on while you get immersed in the experience from start to end.

The software development world is a much more creative world than many recognize or attempt to make into factory production, build from blueprint kind of work. There are so many new possibilities that open up when you spend a big chunk of time working and thinking about the problems at hand that couldn’t be thought of before hand. This is the curse of the software developer who knows the most about a domain right before completing the project.

Initial ideas and proposal are too abstract and lack the level of details required to make specific requirements that can be executed and carry out to perfection without any kind of intervention along the way. We all would be better off by defining the outcomes we expect to have happen when a task or project is completed instead of exactly how it should be executed.

For this reason, we have to communicate often with other stakeholders and show them our current work and progress, the new problems that might arise if we decide on taking one path or another and which are the new possibilities uncovered and decide if they are worth pursuing.

When I work on my personal projects, I often either wear the assignee hat or the reporter hat but never both at the same time because without direction from the reporter me I am not able to avoid diving deep into rabbit holes and without information about new possibilities on what is possible I can’t think of new ways to improve the app as a whole.

To avoid being annoying to my colleagues, I start by slicing the work into functional increments that build on each other and as soon as reach one of the checkpoint I show it the stakeholders that requested the work and ask for feedback. One thing I avoid doing at all cost is to show anything in between checkpoints when ideas are half baked and the wiring is entangled because first impressions last and if the first impression is of poor quality, it stays that way for the lifetime of the task. I am not saying that you shouldn’t ask for help, showing your work and asking for help are two different things and have two different audiences.

At the beginning of the project I often ask, at each checkpoint, “Is this going into the direction you expect?” while I do the demo or guide it heavily; and the more I’m near completion I ask “Is this what you requested?” while letting the stakeholders interact with the work in progress. After receiving feedback on the current progress, I continue by explaining what new things I uncovered, be it limitations or new possibilities that might or might not change the scope.

By going through all these feedback loops I aim at reducing the amount of final work required to push the task or project over the finish line and to make sure it only requires adjustments and not a refactoring. Adjusting the guardrails to be narrower and narrower on each feedback iteration is what gives me the highest chance of delivering a project as close as possible to the expected outcomes by the stakeholders.

Another huge benefit of this the ability to keep tasks and projects on time by being able to make decisions from very early on and to cut down on scope or manage expectations as the launch date arrives.