Sunday, February 3, 2019

tänk EFTER FÖRE !



det gäller att tänka EFTER FÖRE !
att förstå trafikflöden i verkligheten och simulera hur det blir efter en förändring..

Sverige är världssämst på att förstå konsekvenser och våga analysera saker och att "inte hålla med"

någon i organisationen borde ställt sig upp och argumenterat men vi är för fega för att ha egna åsikter och så förbannat lättkränkta så att även vanliga projekt blir svårhanterade eftersom folk "tar åt sig" om man inte "håller med"

tyvärr så gäller det inte enbart trafiklösningar :-(

Friday, February 1, 2019

"Take it easy!"….yeah, right!


Have you ever made a "promise" to take it easy, with the really good intention to do just that, AND to end up in admitting that you did not?

The hindsight-effect is interesting. If we know BEFORE what the result will be, then we would most often act differently. 




But that is not the whole truth!

It is not only a simple decision on YES/NO on activities it is actually more complex than that!

The interpretation ("the semantic value") is always directly dependent on the context.
And it is also a subjective idea of adjusting the target values of a set of quaity requirements as well as accepting a set of constraints!


Let me give you an example. 

A monoskier has just recently operated both hips and is now refering to himself as "the Titanium man".
When going to a Monoski-meeting for a first contact with snow for almost 2 years, he promises his wife to "take it easy".

The "easy" is of course in relation to the baseline he affectuated before the operations, right! (?)
It means that a parameter like "speed" should be LOWER than the aforementioned baseline value
(e.g. 40km/h instead of 80 km/h on average).

But here he should have stoped and asked himself: 

"are there any OTHER parameters than speed that could or should be included  in the take-it-easy manipulation of values?

Are there relations between objects in the context that do not go well with "take it easy" ?

Can you "take it easy" in a black pist with a lot of moguls or in deep powder?
What happens if we reduce the speed in a steep slope and how does the effectuation of the "reduce the speed"-action effect the very thing that he wants to protect i.e. the hips?

The paradox that he SHOULD HAVE KNOWN by heart, is that If you are not riding on the edges on a monoski, you are NOT following the natural curve and speed of the ski. This means that it will cause MORE vibrations and hard work on the joints and muscles than if you "follow the ski"
… so the reduction of speed to enhance "take it easy" actually makes it worse than riding faster in a more natural speed !

Think about it…whit did he do wrong?


THINK!



The "take it easy" should not only change the speed parameter but also WHERE he should ski …if he stayed in less steep environments he could follow the natural flow of the ski without having to brake and reduce the speed at all!

So which lesson did I learn from this? (yes, it was me I was talking about all along)

When agreeing to a concept, be sure to analyze what that specific concept REALLY means!
Both the definition, all parameters involved (the quality attributes) as well as some of the constraints (e.g. "you can NOT ride in moguls if you have agreed to take it easy!")

The effect on my body was that the hips felt great, but the knees got sore and I had to end my skitrip after just 2 days



 …AND also suffer the comment from my wife: 


"why did you not listen to me! Why did you not take it easy!"

Thursday, December 20, 2018

it is all about viewpoints!


Regarding viewpoints, it is a matter of definition of "completeness". In a world without any constraints we should aim for 110% completeness and have representation and surrogacy for all possible views... BUT we have to choose because we do have to deal with a rather large set of constraints, both project constraints (time, money and resources...) as well as legal stuff and "demanded requirements" etc ...

So we need a "scientific" way to prioritize and limit the viewpoints ... it is NOT easy!

This stakeholder managment skills (often uphold, explored and developed by a Business Analyst) involves soo much more than just a list of names and a communication strategy!

An "agile list of names" is NOT good enough...

Exploring, provoking, trawl and strategically "manipulating" to bring forward "that which can not be easily said or answered in a meeting" is a real skill that is not only about iterations. Iterations are only as strong as their inherent tranformational function!

We never see what is out there, we only see a representation of what we know, and that is a bottleneck for creativity and real change ...

Wednesday, November 21, 2018

Draw the f..g map!

Draw the f..g map! 
...that is my personal mantra for basically everything and anything...

If it is complex, it is complex! 

If you have more than 3 entities, grab a pen a draw it on the wall ..and you will definitely experience that TALK is not enough!! If you aspire to be "truly agile", you have to visualize it ALL!... to be smart you have to navigate ...to navigate you need a map ... don't be stupid!

"only talk" is just rubbish! ...instead, TALK about the map! 

Real understanding comes from visual knowledge representation and involvement and talking about the created maps (or diagrams forming the model)...

Wednesday, November 14, 2018

Visual thinking & understanding in BA / RE / ARCH practices used in industry product development

Tacit knowledge calibration

The concept of visual management and visual feedback is one of the pillars in Lean Product development for communication of status, progress, prognosis, and planning, e.g. tracking of work identified, ongoing and done in the development teams via kanban-like boards as well as the progress according to existing plan, expectations and what is actually delivered. 

The leaders of the development teams are more interested in the use of resources and the amount of work to be done, so future work can be planned accordingly. 
The downstream stakeholders like sales, manufacturing, marketing etc.. also need to SEE how the projects are doing so they can plan and be ready at the right time.

The knowledge needed and the representations used, are pragmatic and efficient for management and planning, and the focus is NOT on the visual thinking and understanding of what shall be done. 
Only the management and control aspects of the development are considered.

In the BA/RE practice you often get advice to use X or Y or Z but no direction on WHICH representation to use and no focus on reasoning regarding the effect on this choice for downstream development.
The often individual decisions are suspiciously sub-optimal with no supporting knowledge of consequence of the specific Knowledge Representational choice as it will most likely affect the way we see things, think and are able to invent …but most importantly the ignorance of what we do NOT see and what has been lost in the knowledge transformation along the way ---"the Software Engineering Chinese whispers game"(" Telephone-, Gossip game", "viskleken") aka "the agile guessing game"…
"Chinese whispers game"

The essence of the game is that "Whispered messages" are passed around the room and the version which comes back to the starting point bare no relation to the original message. This phenomenon of "whispering" can also be extended to "not really understanding" in a more general sense to describe every day "mis-telling" of stories and misunderstanding of knowledge in any setting or form, when only using talk and sloppy writing are used as for knowledge communication. In fact, the sheer existence of this "whispering effect" is one of the reasons why LEAN and AGILE will never really work in Software Engineering without a sincere and focused knowledge representation for thinking and understanding!

We are lacking a focus on HOW we make the decision between different Visual Knowledge representations and the effect of our choices both at the same level regarding knowledge, understanding, innovation, and creativity, but also the downstream understanding of WHAT is communicated and what is NOT represented at all. 

Most models are not explicitly showing the Visual Knowledge Representation, but can easily be enhanced by a VKR component. For example the VKR decision point in the MSDDRE model
The MSDDRE model developed by Krzysztof Wnuk 
Blekinge Tekniska Högskola (modified by the author)


And by the way, this is my research domain. Do you want a draft title?
OK here we go:


“Formal & informal Visual Knowledge Representation used for knowledge transfer 
in Requirements Engineering, Business Analysis and Software Architecture
- evaluation of real usage in industry, choice of representation and diagram narratives to identify difficulties and errors in thinking and how to find the Best Possible, Good-enough and Visual Knowledge Representation with focus on the properties required for formal modeling in practice"

Friday, August 17, 2018

Another example on the benefits of real RE and BA thinking!


read the short article : https://mobile.reuters.com/article/amp/idUSKBN1L11NN

The key to making this happen is of course the real understanding of the PARTS and components and the variability and possibilities combined with a "razor-sharp understanding" of the stakeholders and the real needs ...

"With the car retailing for 12,000 euros, pre-existing components keeps costs down. The engine, for example, is a modified version of a fork-lift powerplant, and the door handles come from the Fiat 500"

... "the instrumentation is bare bones. We have stripped a lot of the needless instruments out, said Oliver. "In modern cars you have so many buttons I honestly don't know what many of them are for."


It is very simple...if you do not know which knowledge you need to have and do not represent it in a way that "communicates", you are just guessing in the dark ...

Start with some good thinking and then some spicy "passion" and it becomes a great product! ...

RE = Requirements Engineering, BA = Business Analysis


Wednesday, June 27, 2018

”nudging” adjektiv i texter

Jag gillar INTE när journalister strör ”nudging-adjektiv" i sina texter OAVSETT vad det handlar om 

jämför :

”Hans hårda retorik är ett exempel på hur Lega, som tillsammans med Femstjärnerörelsen nu styr Italien”

med 

”Hans hårda retorik är ett exempel på hur främlingsfientliga Lega, som tillsammans med populistiska Femstjärnerörelsen nu styr Italien”

eller

”Hans hårda retorik är ett exempel på hur främlingsfientliga Lega, som tillsammans med populistiska Femstjärnerörelsen nu styr Italien”

... den senare med författarens val av adjektiv väl synliga i rött.

Detta sätt att skriva är extremt vanligt i svensk press .

Adjektiven är direkt kopplade till journalistens personliga värderingar om respektive objekt och är till för att styra läsarens semantiska process för tolkning av texten.

Jag läser hellre ”rena texter” och faktabaserade kommentarer istället för journalistens ”adjektiv-strösslade nudge-nudge”

Det betyder inte att jag inte tror at Lega är "främlingsfientligt", men vill hellre se en faktaruta om Lega och en statistik kring de som röstar på Lega. Detsamma gäller med adjektiv kring alla vår riksdagspartier. Att knyta ihop partinamnet med ett adjektiv är ett sätt att ljuga. Att slippa resonera kring hur man kom fram till epitetet och att visa med fakta att det faktiskt stämmer eller ej.

Inom kravingenjörskap (Requirements Engineering) så är alla attribut kopplade till någon typ av skala med en enhet och är således mätbara. Faktum är att VARJE parti kan vara "populistiskt" inom ett specifiikt område till en mer eller mindre stor grad på en given skala baserat på fakta och relevanta undersökningar. Att använda ett adjektiv i informativa texter precis som om det var ett faktum utan gradering eller att använda adjektivet som om det vore en del av själva "varumärket", är i min värld detsamma som att generalisera utan att känna till (eller vilja kännas vid) de underliggande strukturerna ...dvs helt enkelt STUPID .. se bilden nedan!