De privacy-muur om waardigheid

Privacy is de muur om de persoon ter bescherming van zijn waardigheid. Of en door wie deze muur doorbroken mag worden is een kwestie van afweging van belangen tussen persoon en maatschappij of tussen de economische belangen van de persoon en andere personen. Hoe die balans precies gelegd wordt is onderdeel van de persoonlijkheid, overtuigingen.

Of een belang dat de maatschappij heeft bij het binnendringen van iemands domein is in beginsel gebaseerd op overtuigingen. Bijvoorbeeld, in hoeverre is het gerechtvaardigd iedereen af te mogen luisteren om een mogelijke aanslag te voorkomen. Of dit acceptabel geacht wordt hang deels af van overtuigingen maar wellicht meer nog van vertrouwen dat inzicht in de persoonlijke omgeving niet misbruikt wordt. Dit is een complex en continu proces dat aandacht nodig blijft hebben.

Economische belangen maken dat er een belangenafweging gemaakt wordt: wegen de voordelen voor beide partijen op tegen de nadelen? Interessant is dat het huidige beeld kennelijk is dat meer inzicht altijd beter is, ongeacht de beleving van het individu. Waar dit op gebaseerd is, is echter de vraag.

Design Thinking

Onder dit thema leveren we services gericht op het ontsluiten van creativiteit en effectieve innovatie van producten en processen. Door de focus op kortcyclisch DOEN en LEREN in combinatie met aandacht voor VERBINDING met alle stakeholders, sluit design thinking erg goed aan bij AGILE ontwikkeling van de organisatie.

Het concept Design Thinking

Design thinking heeft een sterke link met “wijsheid van de menigte” en het gedachtegoed “Jobs-to-be-done” van prof. Clayton Christensen. Het gedachtengoed is gericht op toegevoegde waarde maximaliseren. In de eerste plaats door de focus op verbinding met de stakeholders op zowel rationele maar vooral emotionele gronden. In de tweede plaats door snel LEREN en innoveren op basis van feiten door middel van DOEN!

De aanpak richt zich op de volgende punten:

  • Empathie: waardering en respect voor elkaars kennis, expertise, opinies en meningen.
  • Probleemdefinitie: een door iedereen gedragen beeld van het probleem waarvoor een oplossing gezocht wordt.
  • Creativiteit: ruimte creëren om ideeën te genereren, af te wegen en te toetsen
  • Kiezen: als groep gedragen keuzes maken van wat opgepakt wordt.
  • Leren: prototypes maken, testen en daarvan leren.

Training design thinking

In een doorlooptijd van drie dagen worden leiders en coaches getraind in het implementeren van design thinking in hun organisatie.

Workshop design thinking

Gericht op een specifiek project ondersteunen van project team in het komen tot een goed uitgangspunt.

Coaching

Ondersteuning van teams in het implementeren en toepassen van design thinking.

Valuation of ideas in an agile context (eng)

Most organisations struggle with the way to choose and prioritise ideas for software development. Effective communication, sharing of convictions and a strong focus on learning will help to be innovative without loosing control. Most software development organisations have an agile process in place. To improve effectiveness they should invest in design thinking.

Questions asked frequently to me and my colleagues are: how do I determine a feature has value? How do you determine something has value to the business? How do you measure it? The reason for asking most of the time is a personal wish to improve something.

In many agile handbooks they say the product owner should decide. To support the decision making a lot of rule sets and formulas are available which try to objectify business value. But I think the answer isn’t that trivial.

What I notice is that the more effort one puts in grabbing the value the harder it gets to grab it.

I think the main reason for this is the role of uncertainty. Checklists, rules and formulas typically don’t take into account that not all is clear, that you don’t know all the parameters or not everyone agrees on the parameter values. It is easy to say “if this then that”, but if you don’t know if ‘this’ applies you still don’t know what to do or decide. The only way out is to act on estimates, convictions or believes.

For a startup this is easy.  You have a great idea and are you are convinced people are waiting for this. You are prepared to work night-and-day to prove you are right. You have a vision and are totally committed to realizing it. Finally you either come to the conclusion it doesn’t work, you run out of money or you end up as CEO of a highly valued company:-)

The problem with large organizations is that in order to be effective not only a lot of persons have to share the convictions and believes but they also have to commit themselves to proving them as well. Complicating factor is they have a responsibility to a large number of shareholders regarding the going concern as well.

This brings me back to the questions asked.

In virtual all cases the real problem is they don’t know, understand or share the convictions or believes. They perceive the organization as indecisive or even fickle. This obviously has impact on the commitment of the ones involved as well. Who wants to work night-and-day for realising ideas they don’t really believe in?

So what to do?

The essence is: you have to invest in understanding your clients as well as each other, generate ideas and select and commit to ideas. These ideas are based on assumptions that represent risks for the company. Managing these risks requires an approach concentrated on validation of assumptions in economically the best order.

The solution is twofold. Use the design thinking concept for creating shared believes in order to focus and create commitment. Then, use your agile development proces as it is meant: fail fast, learn fast. For me the conclusion is that there are good practices to determine the value of ideas but from a development perspective the nr. 1 criterium should be: what is now the most important thing to learn.

I like to elaborate on this aspects in future blogs. Please feel free to react with opinions and ideas to support this process.

Begrip van agile

Ik heb inmiddels een behoorlijk aantal verandertrajecten om een agile informatievoorziening te realiseren gezien en ondersteund. Tijd om de op de ervaringen gebaseerde visie te delen dat agile worden hard werken is voor. …management.

Geheel in agile stijl is het volgens my belangrijk te beginnen met wat agile werken op zou moeten leveren. In het algemeen zijn de doelen van de agile transformatie:

  • meer creativiteit: effectiever gebruik maken van de beschikbare denkkracht, intelligentie en ideeën;
  • meer flexibiliteit: in staat zijn snel in te spelen op externe omstandigheden en veelbelovende nieuwe ideeën;
  • meer controle: in staat zijn te voorspellen, beter begrip van onzekerheden etc.

Het is van belang je hierbij te realiseren dat dit geen zero-sum game is. De vraag is dus niet hoeveel creativiteit offeren we op voor meer controle. De vraag is hoe verbeteren we en de controle en de creativiteit en de beheersbaarheid!

Gebaseerd op de hierboven genoemde doelen en het bewustzijn dat het geen zero-sum game kan zijn bij implementatie van frameworks als scrum, devops of het scaled agile framework zie ik een aantal steeds terugkerende thema’s. Veel voorkomende vraagstukken zijn: hoe houden we zicht op de lange termijn doelen? Hoe decomponeren we producten en houden zicht op de waarde die elk onderdeel creëert? Wanneer zijn specificaties voldoende om mee te starten? Hoe schatten en plannen we?

Voor de meeste vragen bestaan goede instrumenten en processen die ook daadwerkelijk gebruikt worden. Concepten als ‘Definitions of ready’ en ‘done’ (DoR, DoD), backlog management of het sprint-proces zijn goed ingeburgerd. De instrumenten zijn eenvoudig toe te passen. De uitdaging is echter hoe van gebruik van deze instrumenten te komen tot realisatie van de gestelde doelen. Dat kan alleen door de instrumenten te gebruiken en ervan te leren. Leren hoe in de specifieke situatie, met de marktdynamiek en de eigen propositie de instrumenten het best gebruikt kunnen worden.  In feite betekent de implementatie van een agile framework de introductie van een aantal gebieden waarop de organisatie begint te leren.

Complicerende factoren zijn echter dat de leergebieden met elkaar verbonden zijn en dat per leergebied meerdere disciplines te leren hebben. Bijvoorbeeld, leren schatten is lastig als er geen DoD of DoR is en zal met het team, IT management en business opgepakt dienen te worden. Een retrospective als er geen goede DoD is leidt al snel tot generieke opmerkingen die in de praktijk niet opgepakt worden. Als er geen door alle disciplines gedeeld beeld is van waarde beperkt dit de effectiviteit van backlog management.

Dus, een effectieve implementatie van agile vereist vooral aandacht voor hoe de organisatie leert op meerdere gebieden tegelijkertijd. En op een manier dat èn de creativiteit, èn de flexibiliteit èn de controle toeneemt! In een specifiek operating model dat de organisatie heeft of wil hebben.

Dit is al met al een lastig vraagstuk dat niet zomaar te vangen is in wat algemene hints, een model of framework. Dit maakt een transformatie naar agile werken een maatwerk traject waarbij de genoemde instrumenten zeker helpen om kader te geven. Het blijft echter in hoge mate maatwerk waarbij succes afhangt van een gedragen visie en hoe het leren gefaciliteerd wordt door de governance structuur, het leiderschapsmodel, het gedrag en attitude van alle betrokkenen, de aanwezige competenties en de beschikbare technologie. En aangezien wijsheid geen standaardsituatie is zal op deze vlakken ook genoeg te leren vallen: double loops learning volgens Argyris. Kortom betekent het veel werk en creativiteit van het management om een vruchtbare bodem te creëren voor de transformatie.