Working on a Problem
While a problem is the relation between human and reality, depending on the working area and human perception might be also defined as an issue or a task or a thing to-do.
Generally speaking, working on a problem will differ for each person defined by their character, daily habits and current conditions.
You might recognize yourself in the following situation when you are working on a problem:
- Walk into the workplace with a memorized problem
- Starting as soon as possible to the problem in mind to deliver a result
- Later in the day realizing that the intention to solve the problem is still not unfolded
- And even later realizing that you are even not started to solve the problem
There is probably quite a lot distractions around us and we likewise admittedly allow those. Take an example from the programmers world. It is a known fact that the programmers want to avoid those annoying distractions and prefer to work at night.
At this point comes your own specific approach in play.
What should be the best approach?
The answer is: You should develop a strategy.
Many of us learn ourselves different strategies by experiencing. Practising the same type of work again and again to become a person with capability whom contains a mixture of concious and unconscious proceedings. Practising by experience gives us a certain capabilities and it might take a long time to reach the required results efficiently. For a real life example just think of an athlete. It takes a lot of training with determination before getting a professional athlete with results at high level.
Not having an own strategy at all will switch the leading role in the work process to others and the workflow will be left to two types of incidental occurrences.
The problem solver should prevent himself from these two cases.
- The next step in the work process is always true
Because there is not a strategy, the problem solver will tend to solve any problem which he encounters on the quest for the next step. Solving each encountered problem on the way might satisfy a human ego, but it might not contribute anything at all to the desired result. Time consuming activity for nothing. - The questioner (mostly managers) determines the process
A manager, with the role being as a manager, expects always the end result. If the delivering results threatens to be late, then in most cases he chops the results in smaller pieces and expects every time an outcome of those smaller pieces. A manager does not think in abstractions as the problem solver should do.
Developing a strategy by the problem solver will put the expected results by managers at the right place. It will be then not a surprise to the problem solver if there are five to six steps needed before those requirements can be realized as the manager suggested before.
Developing no strategy on the other hand will force to follow a reversed workflow from the result to the concept or to the abstraction if you will. In fact, in this reversed workflow - before the concept step is reached - there will be already a result as it was required by the manager. The problem solver might end up in a messed up and non scalable structures.
Here is an approach in steps, the parts of a thought strategy
- Know the Story
- The Trigger Momentum
- The Quest
- The Surprise (Divergence & Convergence)
- The Critical Choice
- Action for Apply
- Reversal
- Completion
Everybody has own story and they all differ. Even so peoples, in reality, live in different time-frames.
For instance the users of a software discover the functionalities of that software not at the same time. As a result each user experiences the same software differently. To overcome this problem there might be a communication manager, a mediator, between the programmers and users.
A mediator will protect the programmers, in this case the problem the solvers, from overwhelming by different user stories. While a mediator between the users and programmers seems to help everybody, the real user stories are now at a great risk of changing.
Therefore asking the right question in this understanding and knowing the story stage is crucial.
Here is a tip: When the parts of a requirement in detail discussed, at least one user story should pop-up in that part. At that moment not the requirement as it presented, but the user story is the most important part.
Stick on user stories and ask for more possible use cases.
Describe the problem and let it describe. Whenever starting on a issue, describing is the most powerful tool to develop a sophisticated strategy.
The Trigger Momentum
Just before starting the work in progress make a little discovery. Look around in administration or if you have in issue tracking tool for similar problems which might be occurred before and falls in the same scope. Once you are aware of them, start the Work in Progress.
The Quest
Triggering in a quest results in finding and identifying the disruptions. This is not not yet the problem solving stage. The quest is all about the investigation. Determining and understanding the current status by researching, examining and eventually testing them.
The Surprise (Divergence & Convergence)
The surprise phase is the "what are the surprises to me?" step. In this phase the problem solver looks for contradictions, discrepancies and accordance to stay on the right track.
The problem solver should ask himself at least two questions:
- Do I see convergences but is my interpretation different?
- While I am sure about the right track, are there still divergences and what else is hidden to me?
A pitfall in the surprise phase might be a too predictable result. Obvious results are frequently an indication of the functions are being used from different angles and different starting points. In this case re-tracing and understanding the purposes of those invokes are important to prevent from a broken system.
The Critical Choice
The critical choice is the crucial decision of problem solving. The problem solver decides what to do and should answer the following questions:
Action for Apply
Once decided, the problem solver takes action and go ultimately for the apex for applying his solution.
Applying solution stage is a marathon stage and requires highest effort of the all steps.
Therefore preparations for the right conditions and high concentration are highly recommended.
Here are some preparation tips before applying solution:
Reversal
The consequence of the critical choice and the applied solution should be examined in a retrospective.
The outcome should result in a change that meets the desired requirements. The reversal stage reveals also the correctness of the solution against the previous situation. Every change made should be logically reasoned.
Completion
Registering understandable comments for any time reading is very important. Work in progress can be in this stage set to status Resolved, but not yet to status Closed. Assuming a solved problem not yet closed will leave room for own review and it is in many cases a wise decision. The real user story or test results as feedback might come back very late. Backing-up all the work done is also highly recommended.
- Split the work in parts or not?
- Apply a quick-win or go for an solid solution?
- Delay the solution for more research and discuss the problem again?
Action for Apply
Once decided, the problem solver takes action and go ultimately for the apex for applying his solution.
Applying solution stage is a marathon stage and requires highest effort of the all steps.
Therefore preparations for the right conditions and high concentration are highly recommended.
Here are some preparation tips before applying solution:
- Take a nap with maximum twenty minutes, or
- Listen some motivational music, or
- Go outside and take a brisk walk
Reversal
The consequence of the critical choice and the applied solution should be examined in a retrospective.
The outcome should result in a change that meets the desired requirements. The reversal stage reveals also the correctness of the solution against the previous situation. Every change made should be logically reasoned.
Completion
Registering understandable comments for any time reading is very important. Work in progress can be in this stage set to status Resolved, but not yet to status Closed. Assuming a solved problem not yet closed will leave room for own review and it is in many cases a wise decision. The real user story or test results as feedback might come back very late. Backing-up all the work done is also highly recommended.
