Visualization principles in software development
As software architects, we sometimes find ourselves needing to use technologies, systems, and approaches that have not been previously tested or have limited industry experience. Additionally, time constraints pose another challenge. Agile is not an environment without time constraints; rather, it is a flexible approach within strict deadlines.
However, despite the high level of uncertainty, we still need to produce results that bring value to the business and meet the specified deadlines.
To eliminate uncertainty and achieve our goals, we can employ visualization techniques commonly used in psychology. I don't know any fancy jargon to describe this technique, but I have found it to be extremely useful when done correctly. It enables me to provide reliable estimates, especially in the software development realm. Additionally, when applied to a team, it enhances overall situational awareness. You may find similarities between these principles and Scrum, or another agile process. I have found that correctly focusing one's mindset is more important than forcing them to simply follow a process, as processes alone do not provide the desired value. The key is to truly understand their purposes, as that is what makes a difference.
I have identified three key principles and practices that could be applied.
1. Visualization of value.
This requires a clear understanding of the importance and benefits of what we want to do, as well as how it will contribute to producing business value. It is crucial to avoid any uncertainty or vague statements, such as using "maybe" or "possibly will work". Every task should have a clear reason for being pursued. If there is no clear reason or the reason is not well-defined, there is a high likelihood of wasting time for everyone involved. This principle is especially applicable to high-quality work. As the task submitter, you should be prepared to answer questions challenging the reasoning behind your objectives.
2. Visualization of the process.
Even before starting work, we try to break down a large task into smaller ones. It's not about solving the task at hand, but rather understanding all the main outcomes that are supposed to happen. For example, we may not know yet how exactly a certain report will be written or what data it will use, but we may already understand that to obtain it, we need to check the availability of data, ensure the feasibility of the report's delivery method, and gather samples, among other things. Each task may have a different set of expected outcomes. During this visualization process, we are not solving all of them, but rather identifying them, asking questions, and envisioning how the final product, feature, or completed work should look like. We may also set some milestones to track progress at certain stages.
3. Visualization of progress.
To see own results is important for an individual. But if the result is delayed in time, because the task is big, then the only way is to observe the progress is by looking at where we were and where we are now on a smaller scale. This makes the feeling of the movement. Without glorifying the process over the outcome, we track the progress of each task during regular meetings. Each team member is asked to assess individually how much effort has already been spent and how much is still required to complete the current work. With this exercise every one in the team gets the feeling of the progress and understanding where we are as the team.
How do you deal with uncertainty in your projects?
