waarheen?

beter beslissen...waarom niet?

Tag: Wabi Sabi

Stop innovating, try renovating

03/12/2017 / / Geen reacties

“Buddhism with wooden shoes…if you really have to”, the Dalai Lama answered. The interview was about 40 years ago in the Netherlands. It still contains value.

The setting? After the flower-power hype more and more Dutch people where getting into Eastern religious ideas and practices. The Dalai Lama was rather curious whether this was not too easy, whether their own religion was really not suitable for their needs and lives.

The question? If Western people could not find peace in their own religion, what would be his advice.

The value? What you have might be better than you thought, saw and felt before. Perhaps look at it with a different perspective, renovate your shoes, your house, your work attitude. New Year’s resolutions are big hairy audacious goals (BHAGs)… we too often fail within only a couple of weeks. Whether in our personal life or in business: a new tool, a new diet, a new task will not make us happy.

Try adjusting and improving what has brought you so far, there is more to you than meets the blinking eye.

Imperfect IT is ok and the best you want: 3 tips

03/12/2017 / / Geen reacties

I had worked so hard to create the perfect situation that in the end nobody could enjoy the results. Yes, I have ruined quite a lot of things, relationships and processes. Of course with the best intentions. At work, I see bright and intelligent people trapped in similar battles. Scared to make a decision or in doubt on a solution? Point at the imperfect nature of a someone else’s solution: “this is not a total solution, so go back to the drawing board”.

The Nirvana fallacy: the lie of the perfect solution

Some years ago I called this the Nirvana fallacy. It is simple and widespread in IT way of working: you compare a solution with an ideal and not with an alternative solution. This is great for killing any initiative and keep the status quo. How inconvenient that situation may be: the solution is not perfect so we have to reject it.

A fine variant is “we have to wait for the outcome” of another project, of another meeting. Leaders should be alert and ask for an alternative way of working or an alternative solution. Yet, we run the risk that no one in the meeting is alert. This is quite convenient for the Nirvana player. He/she shows the “real” solution. He/she is quite a colleague because he/she knows what is best for the organization.

Why this fallacy works in any imperfect situation

The moment an application or hardware comes out of the box the imperfection starts. It needs to be combined with other applications, hardware and requirements. There is no manual for that combination. Since our organization is unique -that’s what most members think of their own organization- the combination is unique. And since we want the best for our organization….

Wabi-sabi: beauty within constraints

A fruitful perspective is wabi-sabi. This Japanese and buddhist concept concentrates on the beauty of everything not perfect. Individuality, authenticity and imperfection are important values in this form of art. Hey, those values sound familiar for every unique organization. Yes but, that is art, we cannot compare it to complex IT applications and processes.

Option B: a way out?

In her book Option B Sheryl Sandberg quotes a friend, promising her to deal with deep adversities: “Option A is not available”. He then promised to help her make the most of Option B. We all live some form of Option B.

Yes, but, -always this “yes but”- that is on personal life. We IT geeks work with binary stuff, good and bad, black and white, functioning and not functioning. Well, let us be fair: how many times have we said of our own work “in principle it is ready” or “normally it works”. We are quite forgiving on our own products, processes. Why not give others the same amount of credits? And improve transparently in small steps?

Metrics

A few years ago I had to take over a project and assess the results of the developers. I was fed up with all the “in principle”, “nearly ready”, “90% ready” so I started asking whether the results could be set in production tomorrow. Additionally I requested the following answers: pregnant or not pregnant. All the green lights turned into red lights and program management freaked out. One of my present customers prefers absolute transparancy since it clarifies what needs to be done. His courage lies in transparancy, regardless of the outcomes. His power lies in clearly defined goals. I like to go further. Clearly defined goals are important but measuring the results as well. That’s what I like in Scrum:

  • large scale epics are cut into smaller user stories
  • only some of those smaller stories are realised in upcoming work
  • previously, we had agreed upon the definition of done to assess the results

So imperfect, real curves and corners are ok, the best we want and they give way for improvement:

  1. ask for alternatives when confronted with the Nirvana fallacy
  2. accept the imperfection of your organization, yourself … and your colleagues
  3. create a roadmap with small, clear and measurable results

… Just do it

Some tasks paralyze us. They are big, hairy and audacious. From present innovation culture we can learn the acceptance of failure, learning from failures and failing forward. In my work I present fast to provide others with the opportunity to improve and take ownership of solutions. Just start the discussion forward with the risk of rejection and the opportunity of cooperation.

Happy hunting.

Just because it fits, doesn’t mean it’ll work.

03/12/2017 / / Geen reacties

Do you love fun… in IT design? Well I do.

Ogilvy South Africa has created a few provoking images. These images express the awkward situation of IT design that concentrates merely on technology:

  • Just because it worked before, doesn’t mean it will work now
  • Just because it’s supposed to work, doesn’t mean it will
  • Just because it works, doesn’t mean it’s fixed; and finally
  • Just because it fits, doesn’t mean it’ll work

The bliss of IT architecture is combining technological options with non-technical requirements: is it sustainably manageable, operationable, to whom does it bring -long term- value? The fun of IT architecture is detecting fallacies in thinking -if all conditions work as supposed, it will work- and steering towards rediscovering the goals, outside IT.

And, to put it in Thomas Edison’s words: Just because something doesn’t do what you planned it to do doesn’t mean it’s useless.

Give me an 80% solution, now!

30/11/2015 / / Geen reacties

70870461_8eac42488a_o

Is it wrong to come up with results that are not perfect?

In my field of work, the IT architects seem to be the guys in an ivory tower preoccupied with the perfect solutions, never implemented. Do they take other people and reality seriously?

Old school versus executable architecture

The main difference between old school IT architecture and executable IT architecture is whether architects let themselves be influenced by the business: old school architecture is not influenced by the business. Let me explain that with a story.

Lovely carrot pastries

An organization has its own bakery to service the employees during lunch-break. The bakery sells carrot cake and carrot bread and carrot cookies. Is it a problem when these lovely products remain unsold? There is no problem for the baker: as a expert he appreciates the most wonderful, nutritious, CO2 neutral pastries he has created. It is a shame that nobody wants to buy these products, but the baker is happy about his products and will not be fired by his management: he is not depending on sales numbers. The management runs business, sees the need for healthy food and lacks the expertise and urge to decide on these food matters. It is annoying for the baker that he is requested by the other employees to advise on their lunch components: what would be healthy, nutritious, crispy, sweet or sour?
What would you do if you were the baker? Would you

  1. carry on with carrot products or
  2. will you complain about lacking management support or
  3. could you develop new products that are fun to make and fun to eat based on the wishes of your potential customers?

Carrying on with carrot products results eventually in a existence-issue: do we really need an own bakery selling products no one really wants to buy? That is not a viable option. And the second option? Well, I have been in an organization where management ordered everyone to buy the carrot products. Luckily our carrot products were of high quality. The customers were not delighted and were eager to find an escape route. But if you lack this support, how would you try to get that support of both management and employees? Do you need that support?

Void perfection

For most Enterprise Architects this is all a no-brainer: their work and products are important and of high quality. Sometimes they deliver not in time but that it because they have to do too many things for which they by principle should not be responsible, like advise or second-opinion or third level support on issues normal administration is uncertain about. Their role is like the Muppets Show’s character Sam the American Eagle: of highly moral standards completely out of order with their context. “The quality of my products is second to none” and everybody continues with business as usual.

First steps on a journey

For someone who wants to do executable architecture this context is the start of a journey, accompanied by questions like:

  • Can I understand what my customers want and understand as healthy?
  • Can I translate that in viable and usable products?
  • Can I understand what my potential customers do not like about buying and consuming my products or services?
  • Can I motivate my customers to change their minds on food habits?
  • What would be the hookup to correlate with them?
  • What are my and their constraints? In communication, producing and consuming?

These questions are related to the third option: not carrying on with “this is how we always have done it” nor requesting management support, but turning towards customers and have fun in creating products that will be sold. Still, too many architects are convinced they ask those questions already and have answered them consistently, by themselves. They have answered the questions without really listening to management and customers. Could it be that architects are highly intelligent and cooperative people that are themselves the roadblocks for progress? The conflict with their context becomes even greater when employees are absent because their unhealthy food habits and business -the object of management- is thus endangered: what is the point of an own bakery when it does not improve the average health? What went wrong, how can we improve this situation? Why can’t we have the baker put extra sugar in his products, perhaps that is not 100% healthy but always better than the present unhealthy food our employees consume?

You cannot answer the question whether or not architecturing is necessary and how to judge, use and evaluate archtecture by just creating another architecture as if that is a self-explanatory concept, clear to your readers and audience. The present history has shows that architecture is so untangible that continuing to do-your-thing is missing the point of the questions we, managers and customers are confronted with.

Executable architecture

Executable architecture aims at goals just like old school architecture but does so by solving present customers’ problems with solutions that aim at further rather general goals. The problems come first and out of the solutions we create directions, directives and goals are abstracted and defined. We should solve issues in such a way that we can leverage the solution in other cases as well. That is completely different from pondering in peace and come up with a principle  a long time after the solution was needed.

In general it all depends on the acceptance of the imperfect, in work and private, and the improvement in small steps.

These thoughts are influenced by

Image origins (unchanged usage):

Onvolmaaktheid is gaaf, ook in de ICT

30/10/2014 / / Geen reacties

b192608905

Ben je gewoon bang of twijfelachtig? Hoe zorg je ervoor, dat je niets hoeft te doen, niets te beslissen? Je brandt een oplossing af door te wijzen op het imperfecte karakter van de oplossing: “het is geen totaaloplossing dus is de oplossing niet goed”. Daarmee stuur je de voorsteller weer op pad: kom maar met een beter voorstel. Je houdt je wel bezig met mijn eigen dingen.

De Nirvana drogreden of de leugen van de perfecte oplossing

Dit is zo’n heerlijke drogreden, die je binnen de ICT vaak tegenkomt. Lees verder

© 2024 waarheen?

Thema gemaakt door Anders Noren — Boven ↑