Think outside the box

Have you learned about thinking of solutions instead of problems? Does it feel right? Nope? I thought so. How can you think of solutions if you cannot think about the underlying problem. Solutions are sometimes hard to find, even when the problem is clear.

Einstein once said: "Solutions should be as simple as possible, but not simpler". 

Almost all solutions are simple if you can understand the problem. But finding the right solution is a discipline itself. There are all kinds of laws, norms and standards that trouble our vision. We even learned at school to stick to the subject; problems should be solved within boundaries. Let's call that the framework of our thinking. The framework is build on what we learn; what we experience though learning and observation. Anything influencing us from outside the framework can cause stress. We are not used to dealing with that pattern. Except we are; we just don't want to acknowledge that.

This is were we should change and start thinking outside our framework. Understand the stress factors that are around us and use them. This can only be achieved via learning and perhaps a little acceptance. If we learn we change our framework, make it wider, narrower, bigger or smaller. It's a constant process we are barely aware of, but it happens all the time.

Learning new things every day, week, month or year keeps the mind young and makes it easier to find solutions to everyday problems. In software development time flies like the wind, progression is made in a very high pace. Therefore developers should try and keep up with new information. In my opinion a developer who only understands one programming language can be very good at his job, but never as good as he (or she) can get. Learning more programming languages will give insight into how certain programming problems are solved in other ways. This will break open the framework of thinking and create new possibilities for solutions on problems.

From yes-but.org: 
Wherever we work and live, people experience problems. Things don’t go as expected. What’s our response? We say “Yes, but…”. Yes, but I can’t. Yes, but that’s not allowed. Yes, but how much will that cost?
And what happens then? Irritation, stagnation, decline. People who approach life in a yes-but way, think in terms of threats, difficulties and limitations. The glass is always half empty.
There is also another way of thinking: the ”Yes-and” posture. People who approach life in a yes-and way, think in terms of chances and opportunities. They not only see a glass of water, but also ask the question: “Where is the faucet?” This yes-and thinking we call “flipthinking”.

Thinking outside the box can be empowered by flipthinking. A yes-and approach on things. Look at solutions, try to look at problems from multiple directions. Is the before mentioned glass half empty, half full, is the glass just too big or perhaps it is full; with water and air. There are lots of ways looking into problems, try to find them, try to find a hypotheses why any of the problems might be right.

So in short: start learning, start looking around, think of other ways to solve a problem, do it with everything around you; not only work, start flipthinking and most of all have fun doing it!

More:  yes-but.org

It's all in the use case

Let's talk about how developers would like to work. Developers love their job, they want challenge not per se competition, but a challenge to themselves. They are very qualified in thinking in how things should work and how it should be made.

There is one trade off. They almost never know what a customer wants. Most frustration in projects is in this part. Developers build what they think a customer wants, a customer thinks the developer speaks his language and doesn't need many words. Both wrong. When you find a developer who does know or a customer who can speak nerd language, call me! There must be telepathy or magic working there.

So, we can say that both the customer and the developer live in their own world, they speak there own language, have their own fun. And all in all, the don't understand each other, but say they do. The trick here is that both should stay in their own dimension and talk a language both can understand. One way I like very much is the way of the use case. It's not a perfect way, not a holy grail, but then again, nothing ever really is. It comes close though, both people can stay in their comfort zones and talk their own language but understand each other, because they understand use cases.

Goal
In a use case a customer defines what he wants, not how he wants it. The developer can make how he wants it. What now exactly should be in a use case then? Well one of the most important thing is a goal. This should be a short, SMART, sentence what the customer wants to achieve when the change requested is implemented by the developer. Erhm, a what? Glad you asked. SMART is a abbreviation of the following: Specific, Measurable, Achievable, Relevant and Time-bound. Which means a goal should be very clear and because it's measurable, there should be no debate whether or not the implementation of the change is correct or not. A goal should never be ambiguous. One of the features of a SMART goal is about achievable; can it be done; do we need extensive resources to pull this off, or is the goal realistic? Is the change relevant at all? Is it relevant to the project? And last but not least make it time-bound. There should be a timed element in a goal.

Actors
When we defined a goal we start in defining the actors which are needed to achieve the goal. We don't talk about the developer or certain persons, we talk more generic in the way of "a customer", "a sales employee", "a marketeer" and so on. All persons needed to achieve the goal are summed up. To be honest, in most cases there are one or two actors.

Scope
One of the items I like most. Scope sounds simple, but it can be so hard to define. Everything you don't mention in the scope is up for debate. So besides defining what is inside the scope, it's important as well to define what is outside of the scope. This defines the narrow barrier of what a customer thinks he will get to what he actually gets. Scope is mandatory to define, this is the point where are discussions are spawn from. When talking about software change there should be a definition here about what the change should imply on the system and what is should not do. 


Preconditions

Preconditions or requisites are the elements or changes that should be in place before this change can commence. Think about version numbers, hardware capacity or even any other change that should be implemented before this change can be made.


Description
What should go in the description of a use case? Well start with the main success story (MSS). Define the happy flow through the application when this change is made. Did you finish the happy flow? Nice, work on a couple of failure scenario's now. When will the change fail? What message should the user get? A tester will use these scenario's to define if the change is successful and if all fail cases are hit.

To make sure a customer gets what he wants and to ascertain it is of a certain quality, do describe precisely how the application should work when the change is implemented.

This is about the smallest form of use case I use, or allow to be used. If a customer cannot define a use case in this form I will try to help him, interview him and educate him. If the customer understands the how's and why's of a use case he will never want to make incomplete stories anymore. He will find a quality change when he delivers a good use case. But bare in mind that he needs some help!

Template
Although I hate templates because people use them as they are, instead of pragmatically convert them for their own use, I believe in this case that it can help a bit.

• Number: each use case has a unique number, so it can always be referred to.
• Name: a use case has a name which uniquely identifies the use case.
• Goal: every use case should have a SMART goal
• Actors: define at least one actor. A system can also be an actor.
• Prerequisites: any law, rule, system that should be respected or interacted with.
• Description: the main success story and preferably a fail scenario.
• Exceptions: any exceptions on this use case
• Result: what is the remaining product when the use case is finished. Use this to measure if the use case is achieved.
• Trigger: describe the trigger, if any, that fires the use case.

More

http://alistair.cockburn.us/Use+case+fundamentals